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’а выполняется у 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’а 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 глобально лимиты не навешивает.

• MCC/вертикалью (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 недоступен (браузер/устройство), показывайте карты/A2A.
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`, веб-хуки (подпись/HMAC), идемпотентность.
3. Настройте COF/network tokenization для MIT/рекуррента + хранение consent.
4. Включите smart-routing: Apple Pay приоритетно на iOS/Safari, фоллбек на карты/A2A.
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 — иначе рекуррентные списания будут нестабильны, а риск отказов и чарджбеков вырастет.