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 (one-tap з 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-криптограма і динамічний ключ формуються на пристрої → їдуть в «payment token».
SCA: Face/Touch ID або код, перевірені в Secure Enclave (device binding).
Дешифрування payment token'a виконується у PSP/еквайєра (або у мерчанта при наявності сертифікації - рідко).

4) 3DS/SCA і ризик

Для PSD2-регіонів Apple Pay зазвичай зараховується як SCA (biometric), що підвищує approval rate.
3DS «в чистому вигляді» може не запускатися - SCA закрита на рівні гаманця (вирішує банк/схема/PSP).
Для «чутливих» категорій банк може вимагати доп.перевірку/відмовити, незважаючи на Apple Pay.

5) MIT/рекуррент і COF: ключове обмеження

Payment token Apple Pay одноразовий: не можна просто «перевикориставати» DPAN-криптограму для майбутніх списань.
Для повторних/MIT (subsequent debits) потрібно мережевий токен COF (Visa Token Service/MDES) або серт. COF у PSP.
Коректна схема: перший платіж через Apple Pay → дозвіл на MIT → токенізація карти в COF (network token) → майбутні MIT з reference.
Без COF і явного consent'a MIT може відкидатися банком (high decline/chargeback risk).

6) Поділ авторизації/капчура

Підтримується'authorize → capture'( ship-later/перевірка наявності).
Інкрементальні капчури і reversal - за правилами схем/еквайєра (уточнюються в договорі PSP).

7) Повернення і диспути

Refund йде по картових рейках (на DPAN/джерело). Часткові повернення - бл.
Chargeback - як у карт (INR/NAD і т.п.). Apple Pay не змінює терміни/процедури.
Зберігайте логи підтвердження/видачі послуги: час SCA, device, IP, сесія.

8) Ліміти, доступність і часті причини відмов

Ліміти задає емітент (per-txn/добові/категорійні); Apple глобально ліміти не навішує.

• МСС/вертикаллю (iGaming/квазі-кеш може блокуватися банком/PSP),
• mismatch гео (карта/IP/мерчант),
• відсутністю COF для MIT,
• неправильною конфігурацією мерчанта (domain verification, merchant capabilities, supportedNetworks).
• Доступність Apple Pay залежить від країни банку-емітента, пристрою, браузера (найчастіше Safari).

9) Вимоги бренду/комплаєнс

Domain verification (файл-пруф на сайті).
Використання офіційних кнопок/іконок Apple, тексти «Buy with Apple Pay».
Не можна «маскувати» метод (повинно бути очевидно, що це Apple Pay).
Дотримуйтесь StoreKit/Guidelines в In-App контексті (для контенту всередині додатків правила відрізняються).

10) Інтеграція через PSP: архітектура

10. 1 Потік (Web/In-App)

1. Каса запитує payment session у Apple (через PSP).
2. Показується Apple Pay Sheet → користувач підтверджує (SCA).
3. Отримуєте payment token (шифротекст) → відправляєте в PSP.
4. PSP дешифрує, проводить авторизацію у мережі/емітента.
5. Отримуєте статус ('authorized/succeeded/failed') + вебхук.
6. Робите'capture '/' refund'за потребою.
7. Щоденний recon за реєстрами PSP ↔ ваш леджер.

10. 2 Бекенд-мінімум

API: `createPayment`, `authorize/capture`, `refund`, `webhook`, `reconcile`.
Ідемпотентність (ключ на'orderId'), експоненціальні ретраї, дедуп вхідних веб-хуків.
Security: валідація signature Apple session, HMAC веб-хуків PSP, строгі redirect-/return-URL.
Observability: approve rate (по банках/мережах),'pending→success/failed', латентність, частка Apple Pay в міксі.

11) UX-патерни, що підвищують конверсію

Динамічний Sheet: передавайте купон/знижку/доставку в Apple Pay Sheet, щоб користувач бачив final total.
One-tap на мобайлі; на десктопі показуйте велику кнопку + підказку про iPhone підтвердження.
Фоллбек: якщо Apple Pay недоступний (браузер/пристрій), показуйте карти/А2А.
Recovery: зрозумілі помилки - «банк відхилив/ліміт/верифікація домену», безпечний повтор; при багаторазовій відмові → альтернативний метод.

12) iGaming: особливості та обмеження

Доступність Apple Pay для iGaming залежить від PSP/еквайєра/емітента та юрисдикції.
Можливі знижені ліміти/selective declines, заборона на квазі-кеш (депозити в ваучери/крипто).
Рекурент/бонусні автосписання - тільки MIT з COF і явною згодою гравця; без цього високий ризик відмов/чарджбеків.
Тримайте альтернативи: A2A (open banking), локальні гаманці, eCash - і smart-routing по ризику/гео/банку.

13) Звірка і звітність (recon)

• 'paymentId/transactionId','orderId', network (Visa/MC/...), банк (BIN), сума/валюта, статус/коди відмови, канал (Web/In-App), timestamps, ARN/UTR/фін-посилання з реєстрів PSP.
• Щодня: auto-recon (зарахування/повернення/корекції) + періодичний full-recon.
• Алерти: «успіх без реєстру», «подвійний capture», «підвислий auth без capture».

14) KPI і управління методом

Approval rate Apple Pay vs карти (по банках/пристроях/браузерах).
Share of Apple Pay в мобільній конверсії.
Decline matrix (reason codes), retry win-rate.
Chargeback rate і середній час до рішення.
Settlement lag і повернення (partial/full).
Тригери «дерейтингу» методу при деградації (наприклад, approve <X% у конкретного банку/гео).

15) Чек-лист виведення в прод

1. Підключіть Apple Pay у PSP; domain verification, список supportedNetworks/merchantCapabilities.
2. Реалізуйте Sheet (Web/In-App),'authorize/capture/refund', веб-хуки (підпис/НМАС), ідемпотентність.
3. Налаштуйте COF/network tokenization для MIT/рекурента + зберігання consent.
4. Увімкніть smart-routing: Apple Pay пріоритетно на iOS/Safari, фолбек на карти/А2А.
5. Завірте бренд-гайд (кнопки/іконки/тексти).
6. Побудуйте recon і алерти за розсинхронами,'auth aging', подвійним capture.
7. E2E-тести: мобайл/десктоп, 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 з domain verification, веб-хуками, ідемпотентністю і recon, використовуйте Apple Pay як пріоритетний мобільний метод з розумним фоллбеком. Для підписок і iGaming критично налаштувати COF/мережеві токени і зберігати consent - інакше рекурентні списання будуть нестабільні, а ризик відмов і чарджбеків зросте.