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’а.
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. Инвойсы/Pay-by-Link/QR — удобно для B2B/офлайна.

• 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` + выбор банка + редирект/App2App с 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`.