תשלום אפל: טוקניזציה והגבלות

1) מהו Apple Pay באינטרנט

• DPAN (מספר חשבון התקן PAN/Device Account Number) about DPAN;
• קריפטוגרמה חד פעמית לכל עסקה;
• הכרה במובלעת מאובטחת (SCA).

2) ערוצים ותרחישים

2. 1 Web (ספארי, iOS/iPADOS/macOS)

Apple Pay JS/Prime Request API + domain image.
Mac without Touch ID משתמש בהעברה: אישור באייפון/Watch.
UX הטוב ביותר עבור ספארי נייד (ברז אחד מגיליון).

2. 2 In-App (iOS/iPADOS)

PKPayment (גיליון מקומי).
App Clip/Deeplink אפשריים עבור תשלומים ”מהירים” ללא התקנה מלאה.

2. 3 POS

NFC (עסקאות CP). המאמר מתמקד ב-CNP/Web/In-App, אך החוקים למטענים/גבולות לא מקוונים שונים.

3) טוקניזציה וביטחון (איך זה עובד)

DPAN מנפיקה רשת של כרטיסים באמצעות שירות אסימונים; ה-PAN לא עוזב את המכשיר.
הקריפטוגרמה של EMV והמפתח הדינמי נוצרים על המכשיר.
SCA: Face/Touch ID או קוד המאומת במובלעת מאובטחת (קשירת התקן).
פענוח אסימון התשלום מבוצע על ידי ה-PSP/רוכש (או על ידי הסוחר, אם מוסמך, לעיתים נדירות).

4) 3DS/SCA וסיכון

עבור אזורים PSD2, Apple Pay נחשב בדרך כלל כ-SCA (ביומטרי), מה שמגדיל את שיעור האישור.
3DS ”בצורתו הטהורה ביותר” לא יכול להתחיל - SCA סגור ברמת הארנק (בנק/תכנית/PSP מחליט).
עבור קטגוריות ”רגישות”, הבנק עשוי לדרוש אימות/סירוב נוספים, למרות Apple Pay.

5) MIT/Recurncy ו ־ COF: Key Constraint

תשלום אסימון Apple Pay הוא חד פעמי: אתה לא יכול פשוט ”להשתמש” מחדש בקריפטוגרמה של DPAN למחיקות עתידיות.
Reported/MIT (חיובים לאחר מכן) דורש סימון COF רשת (Visa Token Service/MDES) או sert. COF על PSP.
תוכנית נכונה: התשלום הראשון באמצעות Apple Pay # הרשאה ל MIT * tokenization של הכרטיס ב COF (אסימון רשת) * MIT עתידי עם התייחסות.
ללא COF והסכמה מפורשת, MIT יכול להידחות על ידי הבנק (סיכון גבוה של ירידת מטען).

6) הפרדת אישור/קפצ 'ור

'תאשר לכידה' (ספינה-מאוחר יותר) נתמכת.
פקקים והיפוך - על פי כללי הסכמות/רוכש (שצוינו בהסכם PSP).

7 מחזירה ומחלוקת

החזר הוא על מסילות קארט (ל-DPAN/source). החזרות חלקיות - אישור.
Chargback - כמו קלפים (INR/NAD, וכו '). Apple Pay לא משנה תזמון/הליכים.
לאחסן את יומני אישור השירות/ההנפקה: זמן SCA, התקן, IP, הפעלה.

8) מגבלות, זמינות וגורמי כישלון תכופים

הגבולות נקבעים על ידי האיסור (per-txn/daily/catgorical); אפל לא כופה הגבלות גלובליות.

• MCC/אנכי (iGaming/quasi-cache יכול להיחסם על ידי בנק/PSP),
• Mismatch geo (מפה/IP/סוחר),
• היעדר COF עבור MIT,
• תצורה שגויה של הסוחר (אימות תחום, יכולות סוחר, Networks).
• הזמינות של Apple Pay תלויה במדינה של בנק, מכשיר, דפדפן (לרוב ספארי).

9) דרישות מותג/ציות

אימות דומיין (חסין קבצים באתר).
שימוש בכפתורי Apple/icons רשמיים, ”Buy with Apple Pay” טקסטים.
אתה לא יכול ”להסוות” את השיטה (זה צריך להיות ברור שזה Apple Pay).
Follow Storcels Kit/Levels בהקשר In-App (כללים שונים לתוכן בתוך יישומים).

10) אינטגרציה באמצעות PSP: ארכיטקטורה

10. 1 זרם (Web/In-App)

1. הקופאית מבקשת תשלום מאפל (באמצעות PSP).
2. Apple Pay Geep מוצג על ידי המשתמש (SCA).
3. אתה מקבל אות תשלום (ciphertext) * שלח אותו אל PSP.
4. ה ־ PSP מפענח, מסמיך מהרשת/מפרסם.
5. קבל מצב (”מורשה/הצליח/נכשל”) + webhook.
6. האם ”ללכוד ”/” החזר” לפי הצורך.
7. איסוף מידע יומי על רשומות PSP ↔ ספר החשבונות שלך.

10. מינימום 2 backend

Api: ”תשלום”, ”לאשר/ללכוד”, ”החזר”, ”webhook”, ”ליישב”.
Idempotence (מפתח על " Id'), מגשים אקספוננציאליים, dedup של ווי רשת נכנס.
אבטחה: אימות חתימת Apple Session, HMAC wooks PSP, Reprecrecte-/Return-URL.
תצפיות: שיעור אישור (על ידי בנקים/רשתות), 'הצלחה/כישלון', Latency, Apple Pay שיתוף בתערובת.

11) דפוסי UX המעודדים המרה

גיליון דינמי: העברה של קופון/הנחה/משלוח לגיליון התשלום של אפל כדי שהמשתמש יוכל לראות את הסכום הסופי.
אחד-ברז על נייד; על שולחן העבודה, להראות כפתור גדול + רמז על אישור האייפון.
Polbeck: אם Apple Pay אינו זמין (דפדפן/מכשיר), הצג cards/A2A.
התאוששות: שגיאות מובנות - ”בנק נדחה/הגבלה/אימות תחום”, חזרה בטוחה; במקרה של כשל מרובה, כפול שיטה חלופית.

12) iGaming: מאפיינים ומגבלות

הזמינות של Apple Pay עבור iGaming משתנה על ידי PSP/acquirer/issuer וסמכות שיפוטית.
הגבלות מופחתות אפשריות/ירידות סלקטיביות, איסור על קוואזי-מטמון (הפקדות בשוברים/קריפטו).
חזרה/בונוס אוטומטי רשומות - רק MIT עם COF והסכמת שחקן מפורשת; בלי זה, הסיכון של כשלים/צ 'רג' בקס הוא גבוה.
שמור אלטרנטיבות: A2A (בנקאות פתוחה), ארנקים מקומיים, eCash - וניתוב חכם על ידי סיכון/גיאו/בנק.

13) פיוס ודיווח (איסוף מידע)

• ' ID/transactionId',' Id', רשת (Visa/MC/...), בנק (BIN), כמות/מטבע, קודי סטטוס/סירוב, ערוץ (Web/In-App), טיים סטמפס, ARN/UTR/FIN.
• יום יום: סיור אוטומטי (קרדיטים/החזרות/תיקונים) + סיור מלא מחזורי.
• התראות: ”הצלחה ללא רישום”, ”לכידה כפולה”, ”נתלה אוט ללא לכידה”.

14) KPI וניהול שיטה

שיעור אישור Apple Pay נגד כרטיסים (על ידי בנקים/מכשירים/דפדפנים).
נתח של Apple Pay בהמרה ניידת.
מטריצת דעיכה (codes סיבה), נסיון מחדש win-rate.
קצב גבס וזמן ממוצע להחלטה.
יישוב לאג וחוזר (חלקי/מלא).
Method ”dereiting” מפעיל במהלך הידרדרות (לדוגמה, לאשר <X% עבור בנק/גיאו מסוים).

15) רשימת תפוקה

1. חבר את Apple Pay ב ־ PSP; אימות תחום, רשתות/יכולות מסחר.
2. יישום גיליון (Web/In-App), ”אישור/לכידה/החזר”, הווי אינטרנט (חתימה/NMAS), אידמפוטנטיות.
3. הגדרות COF/network tokenization עבור אחסון MIT/recurrent + conscient.
4. אפשר ניתוב חכם: Apple Pay עדיפות על iOS/ספארי, follback/A2A כרטיס.
5. הבטחה למדריך המותג (כפתורים/סמלים/טקסטים).
6. לבנות איסוף מידע והתראות על ידי כריתת מדבר, ”הזדקנות אוטומטית”, לכידה כפולה.
7. E2E בדיקות: ניידת/שולחן עבודה, לכידה/החזר חלקי, ירידה-reteries, אי זמינות זמנית של Apple Pay.

כרטיס ציון דרך

רייל: כרטיס (ויזה/MC/etc) ; צ 'רקבק - לפי כללי הקלפים.
SCA: ביומטריה במובלעת מאובטחת; בדרך כלל אין צורך ב-3DS בנפרד.
Tokenization: DPAN + חד פעמי של קריפטוגרם EMV; לשיקום - סימון COF רשת.
”מורשה/נתפס/הצליח/נכשל/הוחזר/בוטל”.
הסדר: על ידי רגיסטרי PSP (לרוב T + 1/T + 2).
מגבלות: זמינות על ידי התקן/דפדפן/גיאו; iGaming - על ידי מדיניות PSP/issuer.

תקציר

Apple Pay היא שכבה מהירה ומאובטחת מעל כרטיסי המרה ניידים גבוהים ו-SCA מחוץ לקופסה. לבנות אינטגרציה באמצעות PSP עם אימות דומיין, ווים ברשת, אידמפוטנטיות וסיור, להשתמש ב-Apple Pay כשיטה ניידת בעדיפות עם מעקב חכם. עבור מנויים ו-iGaming, זה קריטי להגדיר אסימונים של COF/network ולהסכים לאחסן - אחרת מחיקה חוזרת תהיה לא יציבה, והסיכון של כשלים ואריזות מטען יגדל.