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 для некоторых категорий ограничивается провайдером/банками по внутренним политикам и местному праву.
Ожидайте сниженные лимиты, доп. KYC/финмониторинг, возможные 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/ссылка), удобно для B2B/сервисов.

• Эндпоинты: `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 управления и лимитами.