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 (рідко для мерчантів; більше для Р2Р/донатів) - сума вводиться користувачем вручну.

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'+ редиректи/Арр2Арр, екран вибору банку.
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-мандат; прозоро керуйте лімітами та повідомленнями.