Sofort/Klarna: pay-by-bank

1) What is Sofort/Klarna Pay-by-Bank

Sofort (now Klarna Pay Now/Pay-by-Bank) is an A2A tool that allows a buyer to pay for an order directly from their bank account through an online bank/mobile application. The stream is typically built on an SCA confirmation issuer-redirect/App2App (PSD2), and the merchant receives online authorization (success) and then a bank loan based on the provider's reports/calculations.

• Low cost relative to card MDRs.
• Online status (success/failure) almost immediately, while crediting funds is not always instant (usually T + 1/T + 2).
• Wide geography in the EU/EEA (Germany/Austria is especially strong), support for dozens of issuing banks.
• Minimum payment details from the buyer - bank selection and confirmation.

2) Roles and participants

Klarna/Sofort (scheme/provider): routing to banks, statuses, reports, settlements, returns.
Issuer (payer's bank): SCA, write-off confirmation, limits/anti-fraud.
Merchant PSP/Acquirer: merchant connection, API/SDK, webhooks and recon.

Merchant - Initiate payment, process status/returns, reconcile

3) Payment flows: Redirect and App2App

3. 1 Classic redirect

1. Checkout merchant → select "Pay by bank (Sofort/Klarna)."

2. The list of banks → redirect to the online bank (or to the provider's hosted page) → SCA.
3. The bank confirms the payment → return to the merchant with the status (success/failed/canceled/pending).
4. Merchant records order as "paid/pending," waits for webhook/enrollment report.

3. 2 App2App / Mobile

On mobile devices, the merchant opens the banking application by deeplink/intent → confirmation → return according to the scheme above.
Conversion is higher, friction is lower; keep the fallback on the web redirect.

3. 3 Request-to-Pay/Embedded options

A number of banks have request-to-pay/PIS available through the provider's interfaces (the buyer receives a request from the application bank).
Embedded widgets from PSP simplify the list of banks, errors and statuses.

4) Limits and behavior of banks

• Per-transaction, per-day/week at the payer's bank.
• New recipients/merchants - reduced thresholds, shutter speed is possible.
• Channel (mobile/web), velocity rules, geo/device signals.
• In individual countries/banks, threshold SCA exceptions (RA, TRA) are possible - depending on the bank.

5) Authorization vs settlement

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Pending is possible when a confirmation delay or asynchronous check occurs.
Settlement: the actual loan comes from the provider's reports (usually T + 1/T + 2 bank days; depends on country/bank/clearing scheme).
For critical services, use the authorization ⇒ conditional execution model until enrollment is confirmed.

6) Returns, partial returns and disputes

Chargeback (as in cards) is missing. A return is a new credit transaction through a provider to the payer.
Partial refunds are supported.
Return credit terms - bank (T + 1/T + 2).
Disputes/complaints go through the provider + ODR procedure through the payer's bank; prepare order logs, proof-of-delivery/services.

7) Commissions and Economics

Usually fixed/low percentage with transaction + payment for platform functions (hosted checkout, reports, ODR).
Consider the cost of support (pending/expiries), risk incidents, and recon transaction costs.

8) Reconciliation and reporting

Save the'paymentId/transactionId' of the provider, 'orderId', issuing bank, timestamps, statuses.
Enable webhooks about status changes and daily auto-recon.
Combine online events (success/pending) with financial reports (credits/returns/corrections).
Store the UTR/bank reference from the report for each transaction.

9) UX practices

Directory of banks: pre-fill the last choice, sort by popularity/device bank.
Mobile-first: offer App2App, fallback - web redirect.
Errors and retry: give clear reasons (limit, SCA failure, timeout), retry button and alternatives.
Idempotence: 'orderId' + idempotence key for safe repeats.
Receipt: amount, date/time, 'transactionId', bank, channel (App2App/Redirect).

10) Recurrent write-offs and mandates

Classic Sofort - one-off. For recurrent models, a bunch is used: the first payment is A2A → e-mandate/SEPA DD/Open Banking PIS for the future.
Manage mandates (limit, frequency, notifications), store acceptance logs.

11) Compliance, security, data

PSD2/SCA: confirmation in the bank, device binding, anti-fraud bank.
PII minimization: store only the necessary attributes; encrypt the PII; HMAC signatures of web hooks.
GDPR/Logs: consents, right to delete, audit changes.

12) High Risk Verticals (including iGaming)

The availability of Pay-by-Bank for some categories is limited by the provider/banks according to internal policies and local law.
Expect reduced limits, additional CUS/financial monitoring, possible holds.
Keep alternative rails (cards, SEPA, open banking A2A, vouchers) and traffic segmentation.

13) Merchant Integration: Options

1. Hosted/Embedded от PSP/Klarna

Quick start: bank selection widget, statuses, bugs, webhooks out of the box.

2. Server-to-Server + redirect/App2App

More control: banks' own page, fine error processing, own QR/Deep Link.

3. Request-to-Pay

Sending a payment request (email/SMS/link), convenient for B2B/services.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotence and dedupe table by 'orderId'.
• Retrai exponentially for statuses, dead-letter for unstable responses.
• Catalogs: banks/countries, limits/error codes, SLA metrics by issuers.

14) Sofort/Klarna Gateway architecture

API layer (REST/GraphQL) for the cash register.
Event queues: status events → billing/CRM/analytics.
Observability: bank/channel conversion, 'pending→success/expired', latency, SCA failure.
Security: vault for secrets, IP-allowlist provider, anti-replay tokens, strict redirect-URI validation.

15) Output checklist

1. Select the PSP/Klarna/Sofort channel with the desired bank geography.
2. Implement 'createPayment' + bank selection + redirect/App2App with fallback.
3. Connect webhooks, idempotency, timeouts and status repetition.
4. Set up recon (daily + full), UTR/fin references storage.
5. Enable partial/full refunds and ODR in the support.
6. Prepare UX failure/limit scenarios and alternative methods.
7. Test mobile banks (iOS/Android) and major issuers in target countries.
8. Maintain a limit guide and incident status page.

Landmark card

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: more often T + 1/T + 2; plan "conditional execution" before credit.
Limits: per-txn/day/week at issuer'a; for new recipients - below.
Recurrence: via e-mandate/SEPA DD/Open Banking.

Summary

For conversion - App2App/Embedded, for stability - clear webhooks + recon.
Separate online confirmation and actual credit (T + 1/T + 2) in business logic.
Do not fix hard amounts: limit configs by bank/country + regular updating.
For subscriptions, use the first A2A payment → mandate, with clear UX management and limits.