Apple Pay: Tokenization and restrictions

1) What is Apple Pay online

• DPAN (Device PAN / Device Account Number) вместо PAN;
• one-time EMV cryptogram per transaction;
• acknowledgements in Secure Enclave (SCA).

2) Channels and scenarios

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

Apple Pay JS / Payment Request API + domain verification.
Mac without Touch ID uses handoff: confirmation on iPhone/Watch.
Best UX for mobile Safari (one-tap from Sheet).

2. 2 In-App (iOS/iPadOS)

PKPayment (native Sheet).
App Clip/Deeplink are possible for "fast" payments without full installation.

2. 3 POS

NFC (CP transactions). The article focuses on CNP/Web/In-App, but the rules for offline chargers/limits are different.

3) Tokenization and security (how it works)

DPAN issues a network of cards through a token service; The PAN does not leave the device.

The EMV cryptogram and dynamic key are generated on the device → go to the "payment token."

SCA: Face/Touch ID or code verified in Secure Enclave (device binding).
Payment token decryption is performed at the PSP/acquirer (or at the merchant, if certified, rarely).

4) 3DS/SCA and risk

For PSD2 regions, Apple Pay is usually counted as SCA (biometric), which increases the approval rate.
3DS "in its purest form" may not start - SCA is closed at the wallet level (bank/scheme/PSP decides).
For "sensitive" categories, the bank may require additional verification/refusal, despite Apple Pay.

5) MIT/Recurrency and COF: Key Constraint

Payment token Apple Pay is one-time: you can't just "reuse" the DPAN cryptogram for future write-offs.
Repeated/MIT (subsequent debits) requires a network COF (Visa Token Service/MDES) token or sert. COF у PSP.
Correct scheme: the first payment through Apple Pay → permission for MIT → tokenization of the card in COF (network token) → future MIT with reference.
Without COF and explicit consent, MIT can be rejected by the bank (high decline/chargeback risk).

6) Separation of authorization/kapchur

'Authorize → capture '(ship-later) is supported.
Incremental caps and reversal - according to the rules of schemes/acquirer (specified in the PSP agreement).

7) Returns and disputes

Refund is on kart rails (to DPAN/source). Partial returns - approx.
Chargeback - like cards (INR/NAD, etc.). Apple Pay does not change timing/procedures.
Store the service confirmation/issuance logs: SCA time, device, IP, session.

8) Limits, availability and frequent failure causes

Limits are set by the issuer (per-txn/daily/categorical); Apple does not impose global limits.

• MCC/vertical (iGaming/quasi-cache can be blocked by bank/PSP),
• mismatch geo (map/IP/merchant),
• absence of COF for MIT,
• incorrect configuration of the merchant (domain verification, merchant capabilities, supportedNetworks).
• The availability of Apple Pay depends on the country of the issuing bank, device, browser (most often Safari).

9) Brand requirements/compliance

Domain verification (file-proof on the site).
Use of official Apple buttons/icons, "Buy with Apple Pay" texts.
You cannot "mask" the method (it should be obvious that this is Apple Pay).
Follow StoreKit/Guidelines in an In-App context (rules are different for content within applications).

10) Integration via PSP: Architecture

10. 1 Stream (Web/In-App)

1. The cashier requests a payment session from Apple (via PSP).
2. Apple Pay Sheet is displayed → the user confirms (SCA).
3. You receive a payment token (ciphertext) → send it to the PSP.
4. The PSP decrypts, authorizes from the network/issuer.
5. Get status ('authorized/succeeded/failed') + webhook.
6. Do 'capture '/' refund' as needed.
7. Daily recon on PSP registries ↔ your ledger.

10. 2 Backend minimum

API: `createPayment`, `authorize/capture`, `refund`, `webhook`, `reconcile`.
Idempotence (key on 'orderId'), exponential retrays, dedup of incoming web hooks.
Security: validation signature Apple session, HMAC web hooks PSP, strict redirect-/return-URL.
Observability: approve rate (by banks/networks), 'pending→success/failed', latency, Apple Pay share in the mix.

11) UX patterns that boost conversion

Dynamic Sheet: Transfer coupon/discount/delivery to Apple Pay Sheet for the user to see final total.
One-tap on mobile; on the desktop, show a large button + a hint about the iPhone confirmation.
Follbeck: If Apple Pay is not available (browser/device), show cards/A2A.
Recovery: understandable errors - "bank rejected/limit/domain verification," safe retry; in case of multiple failure, → an alternative method.

12) iGaming: Features and Limitations

Apple Pay's availability for iGaming varies by PSP/acquirer/issuer and jurisdiction.
Possible reduced limits/selective declines, prohibition on quasi-cache (deposits in vouchers/crypto).
Recurrence/bonus auto-records - only MIT with COF and explicit player consent; without this, the risk of failures/chargebacks is high.
Keep alternatives: A2A (open banking), local wallets, eCash - and smart-routing by risk/geo/bank.

13) Reconciliation and reporting (recon)

• 'PaymentId/transactionId ',' orderId ', network (Visa/MC/...), bank (BIN), amount/currency, status/refusal codes, channel (Web/In-App), timestamps, ARN/UTR/fin link from PSP registries.
• Daily: auto-recon (credits/returns/corrections) + periodic full-recon.
• Alerts: "success without registry," "double capture," "hung auth without capture."

14) KPI and method management

Approval rate Apple Pay vs cards (by banks/devices/browsers).
Share of Apple Pay in mobile conversion.
Decline matrix (reason codes), retry win-rate.
Chargeback rate and average time to decision.
Settlement lag and returns (partial/full).
Method "dereiting" triggers during degradation (for example, approve <X% for a specific bank/geo).

15) Output checklist

1. Connect Apple Pay at the PSP; domain verification, список supportedNetworks/merchantCapabilities.
2. Implement Sheet (Web/In-App), 'authorize/capture/refund', web hooks (signature/NMAS), idempotency.
3. Configure COF/network tokenization for MIT/recurrent + consent storage.
4. Enable smart-routing: Apple Pay priority on iOS/Safari, card follback/A2A.
5. Assure the brand guide (buttons/icons/texts).
6. Build recon and alerts by desynchronization, 'auth aging', double capture.
7. E2E tests: mobile/desktop, partial capture/refund, decline-retries, temporary unavailability of Apple Pay.

Landmark card

Rail: card (Visa/MC/etc.); chargeback - according to the rules of cards.
SCA: biometrics in Secure Enclave; 3DS is usually not required separately.
Tokenization: DPAN + one-time EMV cryptogram; for recurrent - network COF token.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Settlement: by PSP registers (often T + 1/T + 2).
Limitations: availability by device/browser/geo; iGaming - by PSP/issuer policy.

Summary

Apple Pay is a fast and secure layer over high mobile conversion cards and SCA out of the box. Build integration via PSP with domain verification, web hooks, idempotency and recon, use Apple Pay as a priority mobile method with smart follback. For subscriptions and iGaming, it is critical to configure COF/network tokens and store consent - otherwise recurrent write-offs will be unstable, and the risk of failures and chargebacks will increase.