כרטיס שאי אפשר לאבד: איך ארנק דיגיטלי משנה את הכניסה לאירוע

כשאתם שולחים לאורח כרטיס כתמונה בוואטסאפ, קורה משהו שאתם לא רואים: הכרטיס נכנס לגלריית התמונות שלו, איפשהו בין צילומי מסך מקבוצת ההורים לתמונות מהחתונה של השבוע שעבר. הוא לא "אבד" במובן הטכני — הוא עדיין שם, איפשהו. אבל בלילה של האירוע, כשהתור בכניסה זז והאורח גולל באלפי תמונות כדי למצוא אחת ספציפית, ההבדל בין "קיים" ל"נמצא" הוא כל מה שחשוב.

הבעיה הזאת לא נמצאת בקוד ה-QR עצמו. סורק בדלת קורא בדיוק את אותו קוד בין אם הוא מוצג מתוך צילום מסך, PDF מודפס, או כרטיס השמור בארנק הדיגיטלי של הטלפון — Apple Wallet או Google Wallet. ההבדל האמיתי קורה הרבה לפני הסריקה: איפה הכרטיס יושב על הטלפון, ומה קורה לו אחרי שהוא כבר שם.

תמונה שנשלחת בוואטסאפ נוחתת בגלריה הכללית של הטלפון, לצד כל תמונה אחרת שהאורח אי פעם צילם. PDF נוחת בתיקיית הורדות או בנספח של מייל שנפתח פעם אחת ולא נפתח שוב. שני המקרים דורשים מהאורח לזכור איפה לחפש — ובערב עמוס כזה, עם עשרות התראות, זה בדיוק סוג הזיכרון שנשבר ראשון.

כרטיס שנוסף לארנק הדיגיטלי יושב במקום אחד קבוע — אפליקציית Wallet באייפון, או Google Wallet באנדרואיד — נגיש מהמסך הנעול או מהאייקון, בלי להתערבב עם שום דבר אחר. זה בדיוק ההבדל: לא איפה הכרטיס "קיים", אלא איפה הוא נמצא ברגע שצריך אותו.

זה ההבדל המכני האמיתי. תמונה או PDF הם קובץ סטטי שנוצר ברגע השליחה ולא משתנה שוב לעולם. באפל, כרטיס בארנק הוא רשומה: ברגע שהאורח שומר אותו, המערכת רושמת את המכשיר שלו מול הכרטיס (הטבלאות wallet_devices ו-wallet_registrations) וממשיכה לדבר איתו — מנגנון שקיים כי פרוטוקול ה-PassKit של אפל בנוי סביב ערוץ push למכשיר. בגוגל וולט אין טבלת מכשירים מקבילה; העדכון שם עובד ישירות מול השרתים של גוגל, כפי שנרחיב בהמשך.

ב-irua.app שני הכרטיסים — Apple Wallet ו-Google Wallet — הם יכולת פעילה במוצר, לא הדגמה: כפתורי ההוספה יושבים על עמוד האישור האישי של האורח (/rs/{token}), ממש ליד קוד ה-QR עצמו, כך שלאורח יש שתי אפשרויות ממשיות על אותו מסך — לצלם מסך, או להוסיף לארנק. הכפתורים גם מוצגים לפי הפלטפורמה: אייפון רואה רק את כפתור Apple Wallet, אנדרואיד רואה רק את כפתור Google Wallet — אף אחד לא נתקל בכפתור שהמכשיר שלו לא יכול להשתמש בו בכלל.

זו הנקודה שקובץ פשוט לא יכול להשיג: אם מקום הישיבה של אורח משתנה יום לפני האירוע, תמונה ששלחתם בוואטסאפ כבר שגויה — והאורח לא ידע על כך.

כרטיס שמור בארנק כן מתעדכן. באייפון, כל פעולה שעשויה לשנות את תוכן הכרטיס נכנסת לתור, ומשימת cron שרצה כל דקה שולחת התראת push שקטה, חתומה עם אותו אישור שהנפיק את הכרטיס מלכתחילה, ומבקשת מהאייפון למשוך גרסה מעודכנת. גם בלי push בכלל — השוואת גרסאות שמורה במערכת מבטיחה שרענון ידני מציג את הנתון האחרון. בגוגל וולט זה ישיר עוד יותר: כשמשהו בכרטיס משתנה, המערכת מעדכנת את אובייקט הכרטיס ישירות מול השרתים של גוגל, וגוגל דוחפת את הגרסה החדשה לטלפון בעצמה.

ביטול כרטיס הוא המקום שבו ההבדל הכי משמעותי בא לידי ביטוי: כרטיס מבוטל לא אמור פשוט להיראות עדיין תקף בטלפון של מישהו שכבר לא אמור להיכנס.

בגוגל וולט זה פשוט — האובייקט מסומן כ-EXPIRED ישירות מול השרתים של גוגל. באפל זה מורכב יותר, כי בפרוטוקול של PassKit אין בכלל מנגנון "מחק כרטיס". הפתרון: הכרטיס נבנה מחדש מתוך תמונת מצב שנשמרה לפני המחיקה, עם דגל voided: true, ואייפון מרנדר את זה ככרטיס אפור עם קו חוצה על הברקוד — זו הדרך היחידה ש-PassKit נותן בכלל להגיד "הכרטיס הזה מת".

בדיוק בגלל זה, מחיקת כרטיס במערכת של irua.app לא מסתפקת בסימון פנימי: היא שולחת עדכון ישיר לצד גוגל וולט כדי שהאובייקט יסומן כ-EXPIRED בפועל אצל גוגל, ולא רק במסד הנתונים של irua.app. ביטול שלא מגיע לצד השני שקול לביטול שלא קרה בכלל — ולכן "ביטול פעיל" הוא לא פרט טכני שולי בכרטיס דיגיטלי, אלא בדיוק העניין.

אחד הדברים המעניינים בכרטיסי ארנק הוא שהפורמט עצמו תומך בהתראות מיקום. גם אפל וגם גוגל מתעדות את זה רשמית. לפי מדריך המפתחים הרשמי של Apple ל-Wallet, כרטיס יכול לכלול שדה locations — עד עשרה מיקומים עם קואורדינטות — ו-relevantText שמופיע על המסך הנעול כשמתקרבים אליו; אפל מתעדת שם רדיוס רלוונטיות של כ-100 מטר ל"רדיוס קטן" וכ-1,000 מטר ל"רדיוס גדול" (ומציינת זאת במפורש כפרט מימוש שעשוי להשתנות), וכרטיסי כניסה לאירוע דורשים גם תאריך וגם מיקום תואמים כדי להיחשב רלוונטיים — ואם אין מיקום מוגדר, הרלוונטיות מתבססת רק על התאריך. גוגל הולכת צעד קדימה עם מנגנון שנקרא Nearby Notifications: התראת push דביקה שנשלחת למשתמשים שאישרו שיתוף מיקום מדויק וקבוע, כשהם מתקרבים למיקום שהוגדר על הכרטיס — כאשר גוגל, לא המפתח, קובעת את סף המרחק המדויק ואת נוסח ההתראה.

חשוב להיות מדויקים כאן: זו יכולת אמיתית ומתועדת של הפורמט, לא הבטחה שיווקית. ב-irua.app היא ממומשת ברמת הקוד: מצב בדיקה ייעודי, שניתן להפעיל בנפרד לכל אירוע ומושבת כברירת מחדל, מדגים את ההתנהגות הזו מול קואורדינטה קבועה בתל אביב.

כדאי לומר את זה בבירור, כי קל להתפתות ולהגזים: הסריקה בדלת עצמה זהה. סורק ה-QR בעמדת הצ'ק-אין קורא בדיוק את אותו קוד — הטוקן האישי של האורח — בלי קשר לזה שהוא מוצג מצילום מסך, מדף מודפס, או מכרטיס בארנק. אין כאן "סריקה מהירה יותר" מבחינה טכנית. מה שכן שונה הוא הכל לפני הסריקה: הסיכוי שהאורח בכלל ימצא את הכרטיס בזמן, והסיכוי שהכרטיס שהוא מציג עדיין נכון בפועל.

זו לא יכולת שרצה אוטומטית על כל אירוע. אפל דורשת שלושה קבצי אישור אמיתיים — אישור Pass Type ID, המפתח הפרטי שלו, ואישור הביניים של אפל (WWDR) — וגוגל דורשת מזהה מנפיק וקובץ מפתח של חשבון שירות. עד שההגדרות האלה קיימות במערכת, הכפתור פשוט לא מוצג לאורח בכלל: אין מצב חצי-עובד או שבור שנחשף כלפי חוץ. זה הופך את הכרטיס הדיגיטלי לכלי שמפעילים במודע, אחרי הכנה אמיתית — לא ברירת מחדל שמופעלת אוטומטית בכל אירוע חדש.

רוצים לבדוק אם כרטיס בארנק דיגיטלי משנה את חוויית הכניסה באירוע הבא שלכם? דברו איתנונפתח בטאב חדש ונבדוק ביחד אם וכיצד זה מתאים לסוג האירוע שלכם.