Sofort/Klarna: pay-by-bank

1) Що таке Sofort/Klarna Pay-by-Bank

Sofort (нині Klarna Pay Now/Pay-by-Bank) - A2A-інструмент, який дозволяє покупцеві оплатити замовлення безпосередньо зі свого банківського рахунку через онлайн-банк/мобіл-додаток. Потік типово побудований на issuer-redirect/App2App з підтвердженням по SCA (PSD2), а мерчант отримує онлайн-авторизацію (success) і потім - банківський кредит за звітами/розрахунками провайдера.

• Низька вартість відносно карткових MDR.
• Онлайн-статус (успіх/неуспіх) майже відразу, при цьому зарахування коштів не завжди instant (зазвичай T + 1/T + 2).
• Широка географія в ЄС/ЄЕЗ (особливо сильна Німеччина/Австрія), підтримка десятків банків-емітентів.
• Мінімум платіжних реквізитів у покупця - вибір банку і підтвердження.

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

Klarna/Sofort (схема/провайдер): роутинг до банків, статуси, звіти, розрахунки, повернення.
Issuer (банк платника): SCA, підтвердження списання, ліміти/антифрод.
Merchant PSP/Acquirer: підключення мерчанта, API/SDK, webhooks і recon.
Merchant (продавець): ініціація платежу, обробка статусів/повернень, звірка.

3) Потоки оплати: Redirect и App2App

3. 1 Classic redirect

1. Checkout мерчанта → вибір «Pay by bank (Sofort/Klarna)».
2. Список банків → редирект в онлайн-банк (або на hosted-сторінку провайдера) → SCA.
3. Банк підтверджує платіж → повернення на мерчанта зі статусом (success/failed/canceled/pending).
4. Мерчант фіксує замовлення як «оплачений/очікує», чекає webhook/звіт про зарахування.

3. 2 App2App / Mobile

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

3. 3 Request-to-Pay/Embedded варіанти

У ряду банків доступний request-to-pay/PIS через інтерфейси провайдера (покупцеві приходить запит в банк-додатку).
Embedded-віджети від PSP спрощують список банків, помилки і статуси.

4) Ліміти та поведінка банків

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

5) Статуси та зарахування (authorization vs settlement)

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Pending можливий при затримці підтвердження або асинхронній перевірці.
Settlement: фактичний кредит приходить за звітами провайдера (зазвичай T + 1/T + 2 банківських днів; залежить від країни/банку/схеми клірингу).
Для критичних послуг використовуйте модель «авторизація ⇒ умовне виконання» до підтвердження зарахування.

6) Повернення, часткові повернення і диспути

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

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

Зазвичай фікс/низький відсоток з транзакції + плата за платформні функції (hosted checkout, звіти, ODR).
Врахуйте вартість підтримки (pending/expiries), ризик-інциденти та операційні витрати recon.

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

Зберігайте'paymentId/transactionId'провайдера,'orderId', банк-issuer, тимчасові мітки, статуси.
Увімкніть webhooks про зміну статусу і щоденний auto-recon.
Поєднуйте online-івенти (успіх/pending) з фінансовими звітами (зарахування/повернення/корекції).
Зберігайте UTR/банківську референцію зі звіту для кожної операції.

9) UX-практики

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

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

Класичний Sofort - one-off. Для рекурентних моделей використовують зв'язку: перший платіж A2A → e-mandate/SEPA DD/Open Banking PIS на майбутнє.
Керуйте мандатами (ліміт, періодичність, повідомлення), зберігайте журнали акцепту.

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

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

12) Вертикалі підвищеного ризику (включаючи iGaming)

Доступність Pay-by-Bank для деяких категорій обмежується провайдером/банками з внутрішніх політиків і місцевого права.
Очікуйте знижені ліміти, дод. кус/фінмоніторинг, можливі hold'и.
Тримайте альтернативні рейки (карти, SEPA, open banking A2A, ваучери) і сегментацію трафіку.

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

1. Hosted/Embedded от PSP/Klarna

Швидкий старт: віджет вибору банку, статуси, помилки, webhooks «з коробки».

2. Server-to-Server + redirect/App2App

Більше контролю: власна сторінка банків, тонка обробка помилок, власні QR/Deep Link.

3. Інвойси/Request-to-Pay

Відправка платіжного запиту (email/SMS/посилання), зручно для В2В/сервісів.

• Ендпоінти: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Ідемпотентність і таблиця dedupe по'orderId'.
• Ретраї по експоненті на отримання статусів, dead-letter для нестабільних відповідей.
• Каталоги: банки/країни, ліміти/коди помилок, SLA-метрики по issuer'ам.

14) Архітектура «Sofort/Klarna Gateway»

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

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

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

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

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

Резюме

Для конверсії - App2App/Embedded, для стійкості - чіткі webhooks + recon.
Поділяйте онлайн-підтвердження та фактичний кредит (T + 1/T + 2) у бізнес-логіці.
Не фіксуйте жорсткі суми: конфіги лімітів по банках/країнах + регулярна актуалізація.
Для підписок використовуйте перший платіж A2A → мандат, зі зрозумілим UX управління і лімітами.