Apple Pay: ტოკენიზაცია და შეზღუდვები

1) რა არის Apple Pay ინტერნეტით

• DPAN (Device PAN / Device Account Number) вместо PAN;
• ერთჯერადი EMV კრიპტოგრამები თითოეული გარიგებისთვის;
• დადასტურება Secure Enclave (SCA).

2) არხები და სცენარები

2. 1 Web (Safari, iOS/iPadOS/macOS)

Apple Pay JS / Payment Request API + domain verification.
Mac Touch ID- ის გარეშე გამოიყენება handoff: დადასტურება iPhone/Watch- ზე.
საუკეთესო UX მობილური Safari- სთვის (ერთი ცალი Sheet- დან).

2. 2 In-App (iOS/iPadOS)

PKPayment (native Sheet).
App Clip/Deeplink შესაძლებელია „სწრაფი“ გადახდისთვის სრული ინსტალაციის გარეშე.

2. 3 POS

NFC (CP გარიგებები). სტატიაში არის ფოკუსი - CNP/Web/In-App, მაგრამ ჩარჟბეკების/ლიმიტების წესები ოფლაინში განსხვავებულია.

3) ტოკენიზაცია და უსაფრთხოება (როგორ მუშაობს)

DPAN აწარმოებს ბარათების ქსელს ტოკენის სერვისის საშუალებით; PAN არ ტოვებს მოწყობილობას.
EMV კრიპტოგრამი და დინამიური გასაღები იქმნება მოწყობილობაზე და ტოვებს „ტოკენის პაკეტს“.
SCA: Face/Touch ID ან Secure Enclave- ში შემოწმებული კოდი.
პაკეტის ტოკენის გაშიფვრა ხორციელდება PSP/Exwayer- ში (ან Studios- ში სერთიფიკატის თანდასწრებით - იშვიათად).

4) 3DS/SCA და რისკი

PSD2 რეგიონებისთვის, Apple Pay ჩვეულებრივ ითვლება SCA (ბიომეტრიული), რაც ზრდის approval რატს.
3DS „სუფთა ფორმით“ შეიძლება არ დაიწყოს - SCA დახურულია საფულის დონეზე (ბანკი/სქემა/PSP გადაწყვეტს).
„მგრძნობიარე“ კატეგორიებისთვის, ბანკმა შეიძლება მოითხოვოს დამატებითი შემოწმება/უარი, მიუხედავად Apple Pay- ისა.

5) MIT/რეკურენტი და COF: ძირითადი შეზღუდვა

Payment token Apple Pay არის ერთჯერადი: თქვენ უბრალოდ არ შეგიძლიათ გამოიყენოთ DPAN კრიპტოგრამი მომავალი ჩამოწერისთვის.
განმეორებითი/MIT (subsequent debits) მოითხოვს ქსელის ნიშანს COF (Visa Token Service/MDES) ან sert. COF у PSP.
სწორი სქემა: პირველი გადახდა Apple Pay- ის საშუალებით - MIT- ის ნებართვა - ბარათის ტოქსიკაცია COF (ქსელის ტოკენი) - მომავალი MIT რეფერაციით.
COF- ისა და აშკარა consent 'a MIT- ის გარეშე, იგი შეიძლება უარყოს ბანკმა (high decline/chargeback risk).

6) ავტორიზაციის/კაპიტალის გამიჯვნა

მხარდაჭერილია 'authorize-capture' (ყოფნის შემოწმება).
სავარაუდო კაპიტალი და რევერსული - სქემების/შეძენის წესების მიხედვით (მითითებულია PSP ხელშეკრულებაში).

7) ამაღლება და დებატები

Refund გადის ბარათის რელსებზე (DPAN/წყაროზე). ნაწილობრივი ზარალი - დაახლ.
Chargeback - როგორც ბარათები (INR/NAD და ა.შ.). Apple Pay არ ცვლის ვადებს/პროცედურებს.
შეინახეთ მომსახურების დადასტურების/გაცემის ლოგოები: SCA დრო, მოწყობილობა, IP, სესია.

8) ლიმიტები, წვდომა და უარის თქმის ხშირი მიზეზები

ლიმიტები ადგენს ემიტენტს (per-txn/ყოველდღიური/კატეგორიული); Apple გლობალურად არ ჩამოკიდებს შეზღუდვებს.

• MSS/ვერტიკალური (iGaming/კვაზი ქეში შეიძლება დაბლოკოს ბანკმა/PSP),
• mismatch geo (რუკა/IP/curved),
• COF არარსებობა MIT- ისთვის,
• ციმციმების არასწორი კონფიგურაცია (ციმციმი, მერჩანტის კაპიტალები, დამხმარე ქსელები).
• Apple Pay- ის ხელმისაწვდომობა დამოკიდებულია ემიტენტის ბანკის, მოწყობილობის, ბრაუზერის ქვეყნებზე (ყველაზე ხშირად Safari).

9) ბრენდის მოთხოვნები/შესაბამისობა

დომენის მხარდაჭერა (ვებ - გვერდი).
Apple- ის ოფიციალური ღილაკების/ხატების გამოყენება, ტექსტები „Buy with Apple Pay“.
თქვენ არ შეგიძლიათ „შენიღბოთ“ მეთოდი (აშკარა უნდა იყოს, რომ ეს არის Apple Pay).
დაიცავით StoreKit/Guidelines In-App- ის კონტექსტში (განაცხადში შინაარსისთვის წესები განსხვავებულია).

10) ინტეგრაცია PSP- ით: არქიტექტურა

10. 1 ნაკადი (ვებ/In-App)

1. სალარო ითხოვს შეთავაზებას Apple- დან (PSP- ის საშუალებით).
2. ნაჩვენებია Apple Pay Sheet და მომხმარებელი ადასტურებს (SCA).
3. მიიღეთ პაკეტის ტოკენი (შიფრაცია) და გაგზავნეთ PSP- ში.
4. PSP არის გაშიფრული, ატარებს ავტორიზაციას ქსელში/ემიტენტში.
5. მიიღეთ სტატუსი ('authorized/succeeded/failed') + ვებჰუკი.
6. გააკეთეთ 'capture '/' refund' საჭიროებისამებრ.
7. ყოველდღიური PSP რესტავრაციის ჩანაწერი არის თქვენი ლეჯერი.

10. 2 ზურგჩანთა მინიმალური

API: `createPayment`, `authorize/capture`, `refund`, `webhook`, `reconcile`.
Idempotence (გასაღები 'orderId'), ექსპონენციალური retrais, შემომავალი ვებ-ჰუკების დედაპლატი.
უსაფრთხოება: signature Apple session, HMAC ვებ-ჰუკები PSP, მკაცრი redirect-/return-URL.
Observability: approve rate (ბანკების/ქსელების მიხედვით), 'pending-success/failed', ლატენტობა, Apple Pay- ის წილი მიქსში.

11) UX ნიმუშები, რომლებიც ზრდის კონვერტაციას

დინამიური Sheet: გადასცეს კუპონი/ფასდაკლება/მიწოდება Apple Pay Sheet- ში, რათა მომხმარებელმა დაინახოს საბოლოო ტოტალი.
One-tap mobile; დესკტოპზე აჩვენეთ დიდი ღილაკი + მინიშნება iPhone- ის შესახებ.
ფოლბეკი: თუ Apple Pay არ არის ხელმისაწვდომი (ბრაუზერი/მოწყობილობა), აჩვენეთ ბარათები/A2A.
ჩანაწერები: გასაგები შეცდომები - „ბანკმა უარყო/დომენის ლიმიტი/გადამოწმება“, უსაფრთხო გამეორება; განმეორებითი მარცხით, ალტერნატიული მეთოდი.

12) iGaming: მახასიათებლები და შეზღუდვები

IGaming- ისთვის Apple Pay- ის ხელმისაწვდომობა დამოკიდებულია PSP/Exwayer/ემიტენტზე და იურისდიქციაზე.
შესაძლებელია შემცირებული ლიმიტები/სელექციური გადასახადები, კვაზი ქეშის აკრძალვა (ანაბრები ვაუჩერებში/კრიპტოში).
რეკურენტი/ბონუსის ავტომატური მიწოდება - მხოლოდ MIT COF- ით და მოთამაშის აშკარა თანხმობით; ამის გარეშე არის წარუმატებლობის/ჩარჟბეკების მაღალი რისკი.
შეინარჩუნეთ ალტერნატივები: A2A (ღია ბანკინგი), ადგილობრივი საფულეები, eCash - და რისკის/გეო/ბანკის ჭკვიანი როუტინგი.

13) შერჩევა და მოხსენება (ჩანაწერები)

• 'payhoud Id/transacition Id', 'orderid', ქსელი (Visa/MC/...), ბანკი (BIN), თანხა/ვალუტა, სტატუსის/უარის თქმის კოდები, არხი (Web/In-App), timestamps, amps, amps/URRn/Un/Ut/Ut/Ut. PSs.
• ყოველდღიურად: auto-recon (ჩარიცხვა/გადახდა/კორექტირება) + პერიოდული full-recon.
• ალერტა: „წარმატება რეესტრის გარეშე“, „ორმაგი შეკითხვა“, „შეჩერებული აუტი გარეშე“.

14) KPI და მეთოდის მართვა

Approval rate Apple Pay vs ბარათები (ბანკებისთვის/მოწყობილობებისთვის/ბრაუზერებისთვის).
Apple Pay Share მობილური კონვერტში.
Decline matrix (reason codes), retry win-rate.
Chargeback rate და საშუალო დრო გადაწყვეტილების მიღებამდე.
Settlement lag და subrats (ნაწილობრივი/სრული).
დეგრადაციის დროს მეთოდის „დეგრადაციის“ გამომწვევები (მაგალითად, კონკრეტული ბანკის <X%).

15) Check Life Prode

1. დაუკავშირდით Apple Pay- ს PSP- ზე; domain verification, список supportedNetworks/merchantCapabilities.
2. გააცნობიერეთ Sheet (Web/In-App), 'authorize/capture/refund', ვებ ჰუკები (ხელმოწერა/NMAS), impotence.
3. COF/ქსელის ტოქსიკაციის პარამეტრები MIT/რეკურენტისთვის + შენახვა.
4. ჩართეთ smart-routing: Apple Pay პრიორიტეტულია iOS/Safari, ფოლკლორული ბარათები/A2A.
5. დაარწმუნეთ ბრენდის ჰაიდი (ღილაკები/ხატები/ტექსტები).
6. ააშენეთ ჩანაწერები და ალერტები რასინქრონების მიხედვით, 'auth aging', ორმაგი capture.
7. E2E ტესტები: mobile/desctop, partial capture/refund, decline retries, Apple Pay- ის დროებითი მიუწვდომლობა.

სახელმძღვანელო ბარათი

სარკინიგზო: ბარათი (Visa/MC/და სხვა); chargeback - ბარათების წესების შესაბამისად.
SCA: ბიომეტრია Secure Enclave- ში; 3DS ჩვეულებრივ ცალკე არ არის საჭირო.
ტოკენიზაცია: DPAN + ერთჯერადი EMV კრიპტოგრამი; რეკურენტისთვის - ქსელის COF ნიშანი.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Settlement: PSP რესტავრაციისთვის (ხშირად T + 1/T + 2).
შეზღუდვები: მოწყობილობების/ბრაუზერების/გეოს ხელმისაწვდომობა; iGaming - PSP/ემიტენტების პოლიტიკის შესახებ.

რეზიუმე

Apple Pay არის სწრაფი და უსაფრთხო ფენა ბარათებზე მაღალი მობილური კონვერტით და SCA ყუთიდან. შექმენით ინტეგრაცია PSP- ის საშუალებით დომენის თანმიმდევრობით, ვებ - ჰუკებით, იდემპოტენტურობით და ჩანაწერებით, გამოიყენეთ Apple Pay, როგორც პრიორიტეტული მობილური მეთოდი ჭკვიანი ფოლბეკით. ხელმოწერებისა და iGaming- ისთვის კრიტიკულია COF/ქსელის ნიშნების კონფიგურაცია და შეინახოს consent - წინააღმდეგ შემთხვევაში, განმეორებითი ჩამოწერები არასტაბილური იქნება, ხოლო წარუმატებლობისა და ჩარჟბეკების რისკი გაიზრდება.