כרטיסים לקהל הבית.

מועדוני הפיילוט הראשונים הם Dade County FC ו־EasyChamp FC. נכנסים לסביבת Commerce של המועדון כדי לבדוק גישה. מועדונים אחרים יכולים לדבר עם EasyChamp על הצטרפות לפיילוט; יצירת מועדון לא מפעילה מכירת כרטיסים אוטומטית.

בעלי העסק שהוקצו למועדון פותחים את “תשלומים” ובוחרים “חיבור Stripe”. משתמשים בחשבון ה־Stripe שאמור לקבל את הכסף של המועדון. ‏Stripe מארח את שלבי אימות העסק וחשבון הבנק. צוות המועדון יכול לבדוק את הסטטוס, אבל רק הבעלים שהוקצו יכולים לחבר את חשבון הקבלה. לא שולחים פרטי בנק לתמיכה של EasyChamp.

ב־“תשלומים” בודקים את שם הבעלים, את העסק המקבל ב־Stripe ואת סיומת החשבון. אחר כך חוזרים ל־Commerce ומרעננים את רשימת “מוכנים ליום המשחק?”. היא צריכה לאשר מוכנות למצב המוצג: “תשלומים והעברות Stripe מוכנים” עבור “תשלומים חיים”, או “תשלום הבדיקה של Stripe מוכן” עבור “מצב בדיקה · ללא תשלומים אמיתיים”. חשבון חי מחובר לבדו לא מאשר מוכנות לתשלום בדיקה. מטפלים בכל הגדרה חסרה או הודעת שחזור, מאשרים את הגישה לפיילוט ומפרסמים הצעה במפורש. הזמנת בדיקה אף פעם לא מייצגת תשלום אמיתי או העברה בנקאית.

לא. ‏$5 בדולר ארה״ב הוא מחיר ברירת המחדל ההתחלתי לכרטיס משחק בית. מנהל בוחר אירוע מתוזמן של המועדון, מסמן אותו כמשחק בית, קובע קיבולת ומפרסם במפורש את הצעת הכרטיסים. אפשר לשנות את ברירת המחדל של המועדון להצעות עתידיות או לקבוע מחיר שונה לאירוע מסוים לפני שיש הזמנות. שם המשחק לא משמש לניחוש אם המשחק הוא בבית.

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

מנהל יוצר ב־Commerce קוד הנחה באחוזים, מ־1% עד 100%, עם תאריך תפוגה עתידי ומספר מימושים מרבי, שניהם אופציונליים. קודים מורכבים מ־4–32 אותיות, ספרות או מקפים ונשמרים באותיות גדולות. הם חלים על מוצר כרטיסי האירועים של המועדון בחשבון ה־Stripe המקבל שלו. האוהדים מזינים את הקוד לפני פתיחת דף התשלום; קוד של מועדון אחר, או קוד שפג תוקפו או שנוצל עד תום, לא יכול להוזיל את ההזמנה. קודי הפיילוט האלה לא משנים דמי הרשמה או לוחות תשלומים קיימים של הרשמה.

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

כן. אוהדים יכולים לקנות כאורחים מדף הכרטיסים המפורסם של המועדון ולחזור מ־Stripe לקבלה פרטית של ההזמנה. הדף מציג סטטוס תשלום מאומת ואת הכרטיסים אחרי שהתשלום או ההזמנה ללא תשלום אושרו. משתמשים ב־“העתקת קישור הקבלה הפרטי” כדי לשמור גישה במכשיר אחר, או חוזרים בדפדפן שבו הוזמן. כל מי שמחזיק בקישור הפרטי יכול לראות את ההזמנה ואת קודי הכניסה שלה, אז שומרים אותו לעצמכם. קבלות המייל של Stripe עצמו פועלות לפי הגדרות ה־Stripe של המועדון.

מנהל המועדון פותח את “Commerce ← כניסה” ובוחר “סריקה במצלמה”. מאשרים גישה למצלמה ומכוונים את המצלמה האחורית של הטלפון לקוד ה־QR בכרטיס של האוהד. קוד קריא נבדק ומאושר לכניסה פעם אחת, ואז המצלמה נסגרת. אם המצלמה לא זמינה או שהגישה נדחתה, סוגרים אותה ומדביקים את קוד הכרטיס, או משתמשים בסורק שמקליד טקסט. בוחרים “בדיקה ואישור כניסה”. מחכים לתוצאה המתועדת: סריקה חוזרת מראה שהכניסה כבר אושרה, וכרטיסים מבוטלים או של מועדון אחר לא מכניסים אף אחד.

ב־“תשלומים חיים”, התשלום שייך לחשבון ה־Stripe המחובר של בעלי המועדון, שמוצג ב־“תשלומים”. העמלות של Stripe, דרישות החשבון ולוח ההעברות קובעים את ההעברה לבנק. מצב בדיקה לא יוצר תשלום או העברה בנקאית אמיתיים. ‏EasyChamp לא מחליף אותו בחשבון של איש צוות או של נאמן זמני. בודקים את העסק המקבל ואת מצב התשלום לפני שמפרסמים או משתפים הצעת כרטיסים.

מנהלים יכולים להחזיר הזמנה מלאה דרך Commerce בחשבון הקבלה המקורי. הזמנה שהוחזרה שומרת על הקבלה וההיסטוריה שלה, והכרטיסים שלה מבוטלים. הזמנה ללא תשלום מבוטלת בלי החזר כספי. גם החזר חלקי ש־Stripe רשם מבטל את הכניסה עד שהמועדון מטפל בו; הוא לא משאיר את כל הכרטיסים שמישים.

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

כן, אחרי שהמועדון השלים את הגדרת Stripe ופרסם הצעת כרטיסים. משתפים את הקישור הציבורי של ההצעה, או מדפיסים קוד QR שמוביל אליה. האוהדים פותחים את הדף בטלפון שלהם ומשלימים את התשלום ב־Stripe Checkout המתארח. אחר כך הצוות סורק את הכרטיס שהונפק ב־“Commerce ← כניסה”. קוד ה־QR לרכישה פותח את התשלום; קוד ה־QR הפרטי של הכרטיס מאשר כניסה. סריקת כרטיס לא מחייבת כרטיס אשראי.

‏Stripe תומך ב־Tap to Pay במכשירי iPhone וטלפוני Android תואמים, אבל Tap to Pay מובנה עדיין לא זמין בתוך EasyChamp Club. הפניה מהדפדפן לא יכולה להפוך את הטלפון לקורא כרטיסים ללא מגע. סוחרים זכאים יכולים להשתמש באפליקציית Stripe Dashboard הנפרדת לנייד לתשלומים ללא מגע פנים אל פנים. חיובים עצמאיים כאלה לא יוצרים כרטיסי EasyChamp ולא שומרים מקום מקיבולת האירוע; מנהלים את רישומי השער שלהם בנפרד. ‏Tap to Pay משולב דורש גרסת אפליקציה נוספת ואימות מכשירים.

כן. מקשרים את כפתורי הכרטיסים באתר לדף הכרטיסים הציבורי של המועדון ב־EasyChamp, או להצעה מפורסמת מסוימת. כך האוהדים, הצוות והאפליקציה משתמשים באותם מחירים, קיבולת, קודי הטבה והיסטוריית הזמנות. קודם מפרסמים ומנהלים את ההצעה ב־Commerce. ‏Payment Link עצמאי של Stripe או תשלום ב־Square לא יוצרים אוטומטית כרטיס כניסה של EasyChamp. תשלומי הרשמה או חנות קיימים יכולים להמשיך עם דף תשלום משלהם, בזמן שמכירת הכרטיסים משתמשת בהצעה המשותפת.

הפיילוט לא מוסיף מינוי חדש ל־EasyChamp או עמלת פלטפורמה; עמלות העיבוד של Stripe עדיין חלות. תוסף Commerce חודשי מתוכנן בהמשך, והמחיר ומועד ההשקה שלו עוד יפורסמו. תוכניות Club App קיימות הן נפרדות. מתחילים את הפיילוט בסביבת העבודה בווב. זמינות הורדת האפליקציה וקיצורי Commerce בתוכה נפרדים מתהליך הדפדפן הזה.