Apple Pay: Tokenizacja i ograniczenia

1) Co to jest Apple Pay online

• DPAN (Device PAN/Device Account Number) втестА;
• jednorazowy kryptogram EMV na transakcję;
• potwierdzenia w Bezpiecznej Enklawie (SCA).

2) Kanały i scenariusze

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

API + weryfikacja domeny Apple Pay JS/Payment Request.
Mac bez Touch ID używa handoff: potwierdzenie na iPhone/Watch.
Najlepszy UX dla mobilnego Safari (jeden kran z arkusza).

2. 2 In-App (iOS/iPadOS)

PKPayment (natywny arkusz).
Aplikacja Clip/Deeplink są możliwe do „szybkich” płatności bez pełnej instalacji.

2. 3 POS

NFC (transakcje CP). Artykuł skupia się na CNP/Web/In-App, ale zasady dotyczące ładowarek offline/limitów są różne.

3) Tokenizacja i bezpieczeństwo (jak to działa)

DPAN wydaje sieć kart za pośrednictwem usługi tokenowej; PAN nie opuszcza urządzenia.
Kryptogram EMV i klucz dynamiczny są generowane na urządzeniu → przejdź do „tokena płatności”.
SCA: Identyfikator twarzy/dotyku lub kod zweryfikowany w bezpiecznej enklawie (powiązanie urządzenia).
Odszyfrowanie tokenu płatności odbywa się w PSP/nabywcy (lub u handlowca, jeśli jest on certyfikowany, rzadko).

4) 3DS/SCA i ryzyko

Dla PSD2 regionów Apple Pay jest zwykle liczony jako SCA (biometryczny), co zwiększa wskaźnik zatwierdzenia.
3DS „w najczystszej formie” nie może się rozpocząć - SCA jest zamknięty na poziomie portfela (bank/system/PSP decyduje).
W przypadku kategorii „wrażliwych” bank może wymagać dodatkowej weryfikacji/odmowy, pomimo Apple Pay.

5) MIT/Powtarzalność i COF: Kluczowe ograniczenie

Token płatności Apple Pay jest jednorazowy: nie można po prostu „ponownie użyć” kryptogramu DPAN do przyszłych odpisów.
Powtarzające się/MIT (kolejne obciążenia) wymagają tokenu lub sert COF sieci (Visa Token Service/MDES). COF PSP.
Poprawny system: pierwsza płatność za pośrednictwem Apple Pay → pozwolenie na MIT → tokenizacja karty w COF (token sieciowy) → przyszły MIT z odniesieniem.
Bez COF i wyraźnej zgody bank może odrzucić MIT (wysokie ryzyko spadku/obciążenia zwrotnego).

6) Oddzielenie zezwolenia/kapchur

„Autoryzuj → capture” (statek-later) jest obsługiwany.
Przyrostowe pułapy i cofnięcie - zgodnie z zasadami programów/nabywcy (określonymi w umowie PSP).

7) Zwroty i spory

Zwrot jest na szyny kart (do DPAN/źródło). Częściowe zwroty - ok.
Obciążenie zwrotne - podobne do kart (INR/NAD itp.). Apple Pay nie zmienia czasu/procedur.
Przechowywanie dzienników potwierdzenia/wydania usługi: czas SCA, urządzenie, IP, sesja.

8) Ograniczenia, dostępność i częste awarie

Ograniczenia są ustalane przez emitenta (per-txn/daily/categorical); Apple nie nakłada globalnych ograniczeń.

• MCC/pionowe (iGaming/quasi-cache mogą być zablokowane przez bank/PSP),
• niedopasowanie geo (mapa/IP/handlowiec),
• brak COF dla MIT,
• nieprawidłowa konfiguracja handlowca (weryfikacja domeny, możliwości handlowców, sieci ).
• Dostępność Apple Pay zależy od kraju wydającego banku, urządzenia, przeglądarki (najczęściej Safari).

9) Wymagania marki/zgodność

Weryfikacja domeny (plik-proof na stronie).
Używanie oficjalnych przycisków/ikon Apple, teksty „Kup z Apple Pay”.
Nie można „maskować” metody (powinno być oczywiste, że jest to Apple Pay).
Postępuj zgodnie ze StoreKit/Wytyczne w kontekście In-App (zasady są różne dla treści w aplikacjach).

10) Integracja za pośrednictwem PSP: Architektura

10. 1 Stream (Web/In-App)

1. Kasjer żąda sesji płatności od Apple (za pośrednictwem PSP).
2. Apple Pay Arkusz jest wyświetlany → użytkownik potwierdza (SCA).
3. Otrzymujesz token płatności (ciphertext) → wyślij go do PSP.
4. PSP odszyfrowuje, autoryzuje od sieci/emitenta.
5. Uzyskaj status ('authorized/succeeded/failed') + webhook.
6. W razie potrzeby wykonaj „przechwytywanie ”/„ zwrot”.
7. Dzienny zwiad na rejestrach PSP w księdze rejestracyjnej.

10. 2 Minimum oparcia

API: „Z płatnością”, „autoryzować/przechwytywać”, „refundować”, „z hakiem”, „pogodzić”.
Idempotencja (klucz na ' Id'), przekładnie wykładnicze, dedup przychodzących haków internetowych.
Bezpieczeństwo: podpis walidacyjny Sesja Apple, haki internetowe HMAC PSP, ścisłe przekierowanie-/return-URL.
Obserwowalność: zatwierdzenie stopy procentowej (przez banki/sieci), „w oczekiwaniu → sukces/porażka”, opóźnienie, udział Apple Pay w miksie.

11) Wzory UX, które zwiększają konwersję

Arkusz dynamiczny: Transfer kupon/rabat/dostawa do Apple Pay Arkusz dla użytkownika, aby zobaczyć ostateczną sumę.
Jeden kran na telefonie komórkowym; na pulpicie pokaż duży przycisk + podpowiedź o potwierdzeniu iPhone'a.
Follbeck: Jeśli Apple Pay nie jest dostępny (przeglądarka/urządzenie), pokaż cards/A2A.
Odzyskiwanie: zrozumiałe błędy - „bank rejected/limit/domain verification”, safe retry; w przypadku awarii wielokrotnej → alternatywna metoda.

12) iGaming: Funkcje i ograniczenia

Dostępność Apple Pay dla iGaming różni się w zależności od PSP/acquirer/emitenta i jurysdykcji.
Możliwe obniżone limity/selektywne spadki, zakaz quasi-cache (depozyty w voucherach/kryptach).
Recurrence/bonus auto-records - tylko MIT z COF i wyraźną zgodą gracza; bez tego ryzyko awarii/obciążeń zwrotnych jest wysokie.
Zachowaj alternatywy: A2A (otwarta bankowość), portfele lokalne, eCash - i inteligentne routing według ryzyka/geo/bank.

13) Pojednanie i sprawozdawczość (zwiad)

• "Id/ Id'," Id ", sieć (Visa/MC/...), bank (BIN), kwota/waluta, kody statusu/odmowy, kanał (Web/In-App), znaczniki czasowe, link ARN/UTR/fin z rejestrów PSP.
• Dziennie: auto-recon (kredyty/zwroty/korekty) + okresowy full-recon.
• Wpisy: „sukces bez rejestru”, „podwójne przechwytywanie”, „zawieszenie auth bez przechwytywania”.

14) KPI i zarządzanie metodami

Stawka zatwierdzenia Apple Pay vs karty (przez banki/urządzenia/przeglądarki).
Udział Apple Pay w konwersji mobilnej.
Matryca spadkowa (kody przyczyny), szybkość ponownego wygranej.
Stawka obciążenia zwrotnego i średni czas do podjęcia decyzji.
Opóźnienie rozliczenia i zwroty (częściowe/pełne).
Metoda „dereiting” uruchamia podczas degradacji (na przykład zatwierdza <X% dla konkretnego banku/geo).

15) Lista kontrolna wyjściowa

1. Podłącz Apple Pay w PSP; weryfikacja domeny, скисова Sieci/merchantCapabilities.
2. Zaimplementuj arkusz (Web/In-App), 'authorize/capture/refund', web haki (signature/NMAS), idempotence.
3. Skonfiguruj tokenizację COF/sieci dla pamięci MIT/powtarzalnej + magazynu zgody.
4. Włącz smart-routing: Apple Pay priorytet na iOS/Safari, follback/A2A kart.
5. Zapewnij przewodnik po marce (przyciski/ikony/teksty).
6. Zbuduj zwiad i wpisy przez desynchronizację, 'auth aging', podwójne przechwytywanie.
7. testy E2E: mobilny/pulpit, częściowe przechwytywanie/zwrot, ponowne próby spadku, tymczasowa niedostępność Apple Pay.

Karta orientacyjna

Szyna: karta (Visa/MC/itp.) ; obciążenie zwrotne - zgodnie z zasadami karty.
SCA: biometria w bezpiecznej enklawie; 3DS zwykle nie jest wymagany oddzielnie.
Tokenizacja: DPAN + jednorazowy kryptogram EMV; do powtarzania - token COF sieci.
Статса: „autoryzowany/schwytany/zastąpiony/nieudany/refundowany/nieważny”.
Rozrachunek: przez rejestry PSP (często T + 1/T + 2).
Ograniczenia: dostępność według urządzenia/przeglądarki/geo; iGaming - według polityki PSP/emitenta.

Podsumowanie

Apple Pay to szybka i bezpieczna warstwa nad wysokimi mobilnymi kartami konwersji i SCA poza pudełkiem. Budowanie integracji poprzez PSP z weryfikacją domeny, haki internetowe, idempotencja i recon, użyj Apple Pay jako priorytetowej metody mobilnej z inteligentnym pęcherzykiem. W przypadku subskrypcji i iGaming kluczowe jest skonfigurowanie żetonów COF/sieciowych i zapisywanie zgody - w przeciwnym razie okresowe odpisy będą niestabilne, a ryzyko awarii i obciążeń zwrotnych wzrośnie.