Giropay Німеччина: онлайн-банкінг

1) Контекст і позиціонування giropay

giropay - німецька A2A-схема «pay-by-bank», де покупець підтверджує платіж у своєму інтернет-банку/мобільному додатку банку-емітента. Мерчант отримує онлайн-статус, а гроші приходять банківським кредитом (як правило T + 0/T + 1 робочих днів, залежить від банку/PSP і використовуваної розрахункової рейки). Вартість прийому нижче типового картового MDR, SCA виконується у емітента відповідно до PSD2.

• Issuer-redirect/App2App: редирект на банк або відкриття його додатка.
• SCA и device binding: підтвердження у банку, мінімізація фроду.
• Багаті метадані для звірки: merchant reference/orderId, transactionId.
• Refund через кредитовий переказ: чарджбека як в картах немає.

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

Схема giropay - правила, роутинг до банків.
Issuer (банк платника) - аутентифікація клієнта, підтвердження, ліміти/антифрод.
PSP/Acquirer (CPSP) - підключення мерчанта, API/SDK, webhooks, звіти та розрахунки.
Merchant - ініціація платежу, обробка статусів/повернень, звірка.

3) Потоки оплати

3. 1 Classic issuer-redirect (web)

1. Checkout мерчанта → вибір giropay.
2. Список банків → редирект в онлайн-банк → SCA/підтвердження.
3. Повернення на сайт мерчанта зі статусом (success/pending/failed/canceled/expired).
4. Очікування webhook/реєстру про фактичний кредит (settlement).

3. 2 App2App (mobile)

На телефоні мерчант відкриває банківський додаток по deeplink/intent → підтвердження → повернення.
Конверсія зазвичай вище; обов'язковий fallback на веб-редирект.

3. 3 QR/Pay-by-Link

PSP може дати динамічний QR/посилання з сумою і reference (зручно для інвойсів/офлайну).
Користувач сканує код і підтверджує в банку за схемою вище.

3. 4 «Перший платіж → мандат»

Для рекурентних білінгів giropay часто використовують як перший платіж з SCA, а потім - SEPA Direct Debit/open-banking мандат для наступних списань.

4) Статуси та розрахунки (authorization vs settlement)

Online-статуси: `success`, `pending`, `failed`, `canceled`, `expired`.
«pending» означає, що банк/провайдер ще підтверджує проведення або очікується кредит.
Settlement: фактичне зарахування за звітами PSP/банку (зазвичай T + 0/T + 1; в окремих випадках довше).
Для ризик-чутливих послуг використовуйте модель «умовне виконання» до підтвердженого зарахування.

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

Чарджбеків немає. Повернення - це нова кредитова операція від мерчанта платнику (можливі часткові повернення).
Терміни повернення - банківські (T + 0/T + 1/T + 2, залежить від каналу).
Диспути/скарги - через ODR-процедури PSP та банк платника; готуйте логи замовлення, proof-of-delivery/послуги.

6) Ліміти та ризик-політики

• Per-transaction, per-day/week у issuer’а.
• Нові одержувачі/мерчанти - знижені пороги і/або витримка.
• Канальні/velocity-правила, гео/девайс-сигнали, винятки по SCA (TRA/RA) - на розсуд банку.

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

7) Комісії та економіка

Для giropay зазвичай застосовується фікс/низький відсоток на адресу PSP; нижче картового MDR.
Врахуйте витрати на підтримку pending/expiries, ODR і recon, а також плату за hosted/embedded-віджети і звітність.

8) Звірка і звітність

Зберігайте: 'paymentId/transactionId'провайдера,'orderId', банк-issuer, час, канал (Redirect/App2App/QR), підсумковий статус, банківську референцію/UTR з фін-звітів.
Увімкніть webhooks про зміну статусу, daily auto-recon і періодичний full-recon (зарахування/повернення/корекції).
Налаштуйте алерти по розсинхронах і дешборди SLA.

9) UX-патерни

Directory of banks: автопідказка/пошук, запам'ятовування останнього банку.
Mobile-first: пропонуйте App2App; fallback - веб-редирект.
Помилки та повтори: чіткі причини (ліміт, відмова SCA, таймаут), safe-retry з ідемпотентністю.
Квитанція: сума, дата/час,'transactionId', банк, канал, посилання на саппорт.

10) Рекурентні списання

Використовуйте схему: перший платіж giropay → e-mandate (SEPA DD/Open Banking).
У мандаті фіксуйте ліміт per debit, періодичність, повідомлення та управління (pause/cancel).

11) Комплаєнс і безпека

PSD2/SCA виконується в банку; device binding і антифрод на стороні issuer'a.
GDPR/PII-мінімізація: зберігайте тільки необхідні атрибути, шифруйте PII, обмежуйте доступ.
Webhooks: HMAC/nonce, захист від replay, allowlist IP, журнал аудиту.

12) Чутливі вертикалі (включаючи iGaming)

Доступність giropay і ліміти залежать від політики PSP/банків і локального права.
Очікуйте знижені пороги, розширений KYC і можливі hold'и.
Плануйте альтернативні рейки (карти, SEPA, інші open-banking PIS), smart-routing за профілем клієнта.

13) Інтеграція мерчанта: варіанти

1. Hosted/Embedded від PSP - швидкий запуск, готовий список банків, статуси, помилки.
2. Server-to-Server + Redirect/App2App - власна сторінка вибору банку, глибока обробка помилок, власні QR/Deep Link.
3. Інвойси/Рау-by-Link/QR - зручно для В2В/офлайну.

• API: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Ідемпотентність (orderId + ключ), ретраї по експоненті, дедуп подій.
• Каталоги: банки/ліміти/коди помилок; SLA-метрики по issuer'ам.

14) Архітектура «giropay Gateway»

API-шар (REST/GraphQL) для каси.
Черги подій: статус-івенти → білінг/CRM/аналітика.
Observability: конверсія по банках/каналах, «pending→success/expired», латентність до settlement.
Security: vault для секретів, IP-allowlist PSP, сувора валідація redirect-URI, анти-replay токени.

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

1. Виберіть PSP/канал giropay (Hosted/Embedded/App2App/QR), узгодьте тарифи і SLA.
2. Реалізуйте'createPayment'+ вибір банку + редирект/Арр2Арр з fallback.
3. Підключіть webhooks, таймаути і повтори отримання статусів.
4. Налаштуйте recon (daily + full), зберігання UTR/фін-референцій.
5. Увімкніть partial/full refunds і регламент ODR в саппорті.
6. Підготуйте UX-сценарії відмов/лімітів та альтернативні методи.
7. Покрийте тестами мобільні банки (iOS/Android) і основні issuer'и.

Картка орієнтирів

Статуси: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: частіше T + 0/T + 1; враховуйте умовне виконання до кредиту.
Ліміти: per-txn/day/week у issuer’а; для нових одержувачів - знижені пороги.
Рекурент: через e-mandate/SEPA DD/Open Banking після першого A2A-платежу.

Резюме

Робіть ставку на App2App/Embedded для конверсії і на динамічний QR/Pay-by-Link для інвойсів/офлайну.
Поділяйте онлайн-підтвердження та фактичний кредит у бізнес-логіці.
Не жорстко кодуйте суми: тримайте конфіги лімітів по банках/каналах і регулярно оновлюйте.
Будуйте процес навколо webhooks + recon, часткових повернень і чіткої обробки'pending/expired'.