iDEAL Нидерланды: A2A-платежи

1) Контекст и позиционирование iDEAL

iDEAL — национальная схема безналичных A2A-платежей (account-to-account) в Нидерландах. Покупатель оплачивает покупку напрямую со своего банковского счета через интернет-банк/мобильное приложение банка-эмитента. Поток построен на issuer-redirect (перенаправление к банку) или на открытии банковского приложения по deeplink/App2App. Расчет быстрый, комиссия для мерчанта ниже картовых MDR, финальность — как у банковского кредитового перевода.

• Интероперабельность через банки-эмитенты (ING, Rabobank, ABN AMRO и др.).
• SCA/PSD2-соответствие — подтверждение в банке (PIN/биометрия).
• Мгновенная авторизация (status success в онлайне) и финальный кредит через эквайера/банка-получателя.
• Богатые метаданные для сверки (purchaseId/orderId, описание, reference).

2) Роли участников

iDEAL (схема) — правила, сертификация, маршрутизация к банкам-эмитентам.
Issuer (банк плательщика) — аутентификация клиента, подтверждение платежа, статус.
Acquirer / CPSP (Payment Service Provider) — подключение мерчанта, API/SDK, отчетность и расчеты.
Merchant — инициирует платеж, получает статусы/средства, ведет возвраты и сверку.

3) Варианты потоков оплаты

3.1 Issuer-redirect (classic)

1. Checkout мерчанта → выбор банка из Issuer Directory.
2. Редирект или App2App в банк → SCA → подтверждение.
3. Возврат на мерчанта с `transactionId` и статусом (success/failed/canceled/open/expired).

3.2 App2App / Embedded

На мобильных устройствах мерчант открывает банковское приложение по deeplink/intent (лучше UX, меньше трения).
Embedded/Hosted: провайдер дает готовый виджет списка банков, управление редиректами, обработку ошибок.

3.3 iDEAL QR (офлайн/онлайн)

Динамический QR per-order со встроенной суммой и reference; покупатель сканирует камерой банковского приложения и подтверждает платеж.
Статический QR (редко для мерчантов; больше для P2P/донатов) — сумма вводится пользователем вручную.

3.4 Recurring/mandates

Модель «first payment + e-mandate»: первое списание по iDEAL с явным SCA → создание e-мандата (обычно приводит к SEPA Direct Debit на следующие списания в рамках согласованных лимитов/периодики). Подходит для подписок.

4) Лимиты и политика банков

• Per-transaction (максимум на одну операцию).
• Per-day / 24h и weekly (сумма и/или количество операций).
• Новый бенефициар/новый мерчант — возможны сниженные пороги и/или выдержка.
• Канальные/риск-правила (мобильный vs десктоп, velocity, гео/девайс).

Практика: не хардкодьте числа — держите справочник лимитов по банкам и отображайте пользователю понятную ошибку «превышен лимит банком» с альтернативами (дробление, другой метод, позднее повторить).

5) Комиссии и экономика

• провайдерские сборы (gateway, виджет, hosted checkout),
• стоимость возвратов/операций ODR,
• поддержка и расследования инцидентов.

6) Статусы, отмены, возвраты

Статусы транзакций: `success`, `open` (ожидание), `failed`, `canceled`, `expired`.
Отмена до подтверждения — со стороны клиента (в банке) или по таймауту (expired).
Чарджбэков как в картах — нет. Возврат — это новая кредитовая операция от мерчанта плательщику (refund), возможны частичные возвраты.
Срок возврата зависит от PSP/банка; часто T+0/T+1 по банковскому переводу.

7) Безопасность и соответствие

SCA в банке-эмитенте + device binding и антифрод-политики на стороне банка.
Name/IBAN display у некоторых эмитентов снижает риск misdirection.
PSD2/ГДПР: минимизация PII, защита веб-хуков (HMAC), журнал аудита.

8) Сверка и отчетность

Сохраняйте `transactionId` (iDEAL), `purchaseId`/`orderId`, time, issuer, итоговый статус, UTR/банковскую референцию из отчетов PSP.
Настройте daily auto-recon и периодический full-recon (сверка оборотов, возвратов, корректировок).
В отчетах PSP: исходные параметры заказа, статусы, поздние обновления (например, `open → success/expired`), движения по возвратам.

9) UX-паттерны

Directory → Bank pick: предзаполняйте и сортируйте банки по популярности/последнему выбору.
Mobile-first: автоматически предлагайте App2App, fallback — web-redirect.
Retry / recovery: при неудаче покажите простой повтор и альтернативные методы.
Idempotency: `orderId` + ключ идемпотентности для безопасных повторов.
Чеки: указывайте сумму, дату/время, `transactionId`, reference, канал (QR/App2App/Redirect).

10) Рекуррентные списания через e-мандаты

Сценарий «первый платеж iDEAL → мандат на будущие списания» (обычно через SEPA Direct Debit).
В мандате фиксируются лимит per debit, периодичность, право отмены.
В интерфейсе — экран управления мандатами (pause/cancel/update) и уведомления перед списанием.

11) iDEAL и iGaming/высокорисковые категории

Доступность iDEAL для некоторых вертикалей ограничивается банками/PSP по политике риска и местному праву.
Для iGaming ожидайте: ужесточенные проверки, сниженные лимиты, обязательный локальный комплаенс и прозрачный ODR/Refund-флоу.
Планируйте альтернативные рельсы (карты, SEPA, open-banking A2A) и сегментацию трафика.

12) Интеграция мерчанта: варианты

1. Hosted/Embedded iDEAL Checkout от PSP

Быстрый запуск, авто-обновление списка банков, статусов и ошибок.

2. Server-to-Server + редиректы

Гибкий контроль UX: собственная страница выбора банка, QR-генерация, глубокая интеграция в кассу.

3. iDEAL QR

Для POS/офлайна: динамический QR per-order с суммой/метками, лучше для сверки и антииздержек.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Идемпотентность и таблица dedupe по `orderId`.
• Webhooks с HMAC-подписью, ретраи по экспоненте, пулл-опрашивание при деградации.
• Каталоги: банки/лимиты/коды ошибок; SLA-метрики по эмитентам.

13) Архитектурная схема «iDEAL Gateway»

API слой: REST для кассы + интеграция с PSP/iDEAL API.
Очереди событий: статус-ивенты → биллинг/CRM/аналитика.
Observability: метрики конверсии по банкам/каналам (Redirect/App2App/QR), доля `open→expired`, средняя латентность до success.
Безопасность: секреты в vault, IP-allowlist от PSP, защита редирект-URL, анти-replay токены.
Данные: реестры платежей/возвратов, журнал ODR, карта мандатов.

14) Чек-лист вывода в прод

1. Выберите PSP/эквайера с iDEAL (Hosted/Embedded/App2App/QR).
2. Реализуйте `createPayment` + редиректы/App2App, экран выбора банка.
3. Включите веб-хуки, идемпотентность, таймауты и повторы статусов.
4. Настройте recon (daily + full), выгрузки и алерты по рассинхронам.
5. Поддержите partial/full refunds и регламент ODR в саппорте.
6. Добавьте UX-fallback (альтернативные методы, повтор), чек с `transactionId`.
7. Протестируйте App2App/QR на основных банках (iOS/Android/desktop).
8. Подготовьте справочник лимитов по банкам и страницу статусов инцидентов.

Карточка ориентиров по лимитам

Per-txn / 24h / 7d: хранить в конфиге; проверять до запуска редиректа.
Новые бенефициары/мерчанты: пониженные стартовые лимиты и/или задержки.
Канал: на мобильном App2App лимиты/фрод-политики могут отличаться от веба.
Мандаты: лимиты/периодичность задаются в условиях мандата (для рекуррентных списаний).

Резюме

Делайте ставку на App2App/Embedded для конверсии и на динамический QR для офлайна.
Не вшивайте жесткие суммы: ведите конфиги лимитов и поведенческих правил по банкам.
Процесс строится вокруг webhooks + recon, четких статусов и partial refunds.
Для подписок — первый платеж iDEAL → e-мандат; прозрачно управляйте лимитами и уведомлениями.