Sofort/Klarna: pay-by-bank

1) Ce este Sofort/Klarna Pay-by-Bank

Sofort (acum Klarna Pay Now/Pay-by-Bank) este un instrument A2A care permite unui cumpărător să plătească pentru o comandă direct din contul lor bancar printr-o bancă online/aplicație mobilă. Fluxul este de obicei construit pe un issuer-redirect/App2App de confirmare SCA (PSD2), iar comerciantul primește autorizație online (succes) și apoi un împrumut bancar bazat pe rapoartele/calculele furnizorului.

• Cost redus în raport cu MDR-urile cardurilor.
• Statutul online (succes/eșec) aproape imediat, în timp ce creditarea fondurilor nu este întotdeauna instant (de obicei T + 1/T + 2).
• Geografia largă în UE/SEE (Germania/Austria este deosebit de puternică), sprijin pentru zeci de bănci emitente.
• Detalii minime de plată de la cumpărător - selecție bancară și confirmare.

2) Roluri și participanți

Klarna/Sofort (schemă/furnizor): rutare către bănci, statute, rapoarte, decontări, returnări.
Emitent (banca plătitorului): SCA, confirmare anulare, limite/antifraudă.
Comerciant PSP/Acquirer: conexiune comerciant, API/SDK, webhook-uri și recunoaștere.

Comerciant - Inițiați plata, procesați starea/returnările, reconciliați

3) Fluxuri de plată: Redirecționare și App2App

3. 1 Redirecționare clasică

1. Checkout comerciant → selectați „Plătiți prin bancă (Sofort/Klarna)”.
2. Lista băncilor → redirecționa către banca online (sau către pagina găzduită de furnizor) → SCA.
3. Banca confirmă plata → returnarea la comerciant cu statutul (succes/eșec/anulat/în așteptare).
4. Comerciantul înregistrează comanda ca „plătit/în așteptare”, așteaptă raportul de webhook/înscriere.

3. 2 App2App/Mobil

Pe dispozitivele mobile, comerciantul deschide aplicația bancară prin deeplink/intenție → confirmare → returnare conform schemei de mai sus.
Conversia este mai mare, frecarea este mai mică; păstrați rezerva pe web redirecționa.

3. 3 Opţiuni Solicitare la plată/Încorporare

O serie de bănci au cerere de plată/PiS disponibile prin interfețele furnizorului (cumpărătorul primește o cerere de la banca de aplicații).
Widget-urile încorporate din PSP simplifică lista de bănci, erori și stări.

4) Limitele și comportamentul băncilor

• Per-tranzacție, pe zi/săptămână la banca plătitorului.
• Noi destinatari/comercianți - praguri reduse, viteza de obturare este posibilă.
• Canal (mobil/web), reguli de viteză, semnale geo/dispozitiv.
• În țările/băncile individuale, sunt posibile excepții de prag SCA (RA, TRA) - în funcție de bancă.

5) Autorizare vs decontare

Status online: 'succes', 'în așteptare', 'eșuat', 'anulat', 'expirat'.
În așteptare este posibilă atunci când are loc o întârziere de confirmare sau o verificare asincronă.
Decontare: împrumutul real provine din rapoartele furnizorului (de obicei T + 1/T + 2 zile bancare; depinde de țară/bancă/schema de compensare).
Pentru serviciile critice, utilizați modelul de autorizare ⇒ execuție condiționată până la confirmarea înscrierii.

6) Returnări, returnări parțiale și dispute

Chargeback (ca în cărți) lipsește. O returnare este o nouă tranzacție de credit prin intermediul unui furnizor către plătitor.
Sunt suportate restituiri parțiale.
Termeni de returnare a creditului - bancă (T + 1/T + 2).
Litigiile/reclamațiile trec prin procedura prestatorului + SOL prin banca plătitorului; pregătiți jurnalele comenzii, dovada livrării/serviciilor.

7) Comisioane și economie

De obicei procentaj fix/scăzut cu tranzacție + plată pentru funcțiile platformei (checkout găzduit, rapoarte, SOL).
Luați în considerare costul sprijinului (în așteptare/cheltuieli), incidentele de risc și costurile de tranzacție de recunoaștere.

8) Reconciliere și raportare

Salvați 'paymentId/transactionId' al furnizorului,' orderId', emitent bank, timestamps, statuses.
Activați cărțile web despre modificările de stare și auto-recunoașterea zilnică.
Combină evenimentele online (succes/în așteptare) cu rapoartele financiare (credite/returnări/corecții).
Stocați referința UTR/bancară din raport pentru fiecare tranzacție.

9) Practici UX

Directorul de bănci: pre-umple ultima alegere, sortați după popularitate/banca de dispozitive.
Mobile-first: ofertă App2App, rezervă - redirecționare web.
Erori și încercați din nou: oferiți motive clare (limită, eșec SCA, timeout), încercați din nou butonul și alternativele.
Idempotence: 'orderId' + cheie de idempotence pentru repetări sigure.
Primire: suma, data/ora, 'tranzactionId', banca, canal (App2App/Redirect).

10) Reduceri și mandate recurente

Classic Sofort - one-off. Pentru modelele recurente se utilizează o grămadă: prima plată este A2A → e-mandate/SEPA DD/Open Banking PiS pentru viitor.
Gestionați mandatele (limită, frecvență, notificări), stocați jurnalele de acceptare.

11) Conformitate, securitate, date

PSD2/SCA: confirmarea în bancă, legarea dispozitivului, banca antifraudă.
Minimizarea PII: stocați numai atributele necesare; criptează PII; Semnăturile HMAC ale cârligelor web.
GDPR/Jurnale: consimțământ, dreptul de a șterge, modificări de audit.

12) Verticale cu risc ridicat (inclusiv iGaming)

Disponibilitatea Pay-by-Bank pentru anumite categorii este limitată de către furnizor/bănci în conformitate cu politicile interne și legislația locală.
Așteptați limite reduse, monitorizare suplimentară CUS/financiară, posibile dețineri.
Păstrați șine alternative (carduri, SEPA, A2A open banking, vouchere) și segmentarea traficului.

13) Integrarea comerciantului: Opțiuni

1. Găzduit/încorporat от PSP/Klarna

Start rapid: widget de selecție bancară, stări, bug-uri, cârlige web din cutie.

2. Server-to-Server + redirect/App2App

Mai mult control: pagina proprie a băncilor, procesarea erorilor fine, propriul QR/Deep Link.

3. Cerere-la-plată

Trimiterea unei cereri de plată (e-mail/SMS/link), convenabilă pentru B2B/services.

• Эндпоинты: 'createPayment', 'queryStatus', 'rambursare', 'webhook', 'reconciliere'.
• Idempotența și masa dedupe prin "orderId'.
• Retrai exponenţial pentru statusuri, litere moarte pentru răspunsuri instabile.
• Cataloage: bănci/țări, limite/coduri de eroare, valori SLA de către emitenți.

14) Arhitectura Sofort/Klarna Gateway

Strat API (REST/GraphQL) pentru casa de marcat.
Cozi de evenimente: evenimente de stare → facturare/CRM/analytics.
Observabilitate: conversie bancă/canal, 'pending→success/expired', latență, eșec SCA.
Securitate: seif pentru secrete, furnizor IP-allowlist, jetoane anti-reluare, validare strictă redirect-URI.

15) Lista de verificare de ieșire

1. Selectați canalul PSP/Klarna/Sofort cu geografia bancară dorită.
2. Implementați 'createPayment' + selecție bancară + redirect/App2App cu rezervă.
3. Conectați cârlige web, idempotență, timeout-uri și repetarea stării.
4. Configurați recunoașterea (zilnică + completă), stocarea referințelor UTR/fin.
5. Activați rambursările parțiale/complete și SOL în suport.
6. Pregătiți scenarii de eșec/limită UX și metode alternative.
7. Testați băncile mobile (iOS/Android) și emitenții majori din țările țintă.
8. Mențineți un ghid de limită și pagina de stare a incidentului.

Carte de reper

Статусы: „succes”, „în așteptare”, „eșuat”, „anulat”, „expirat”.
Decontare: mai des T + 1/T + 2; planul „executie conditionata” inainte de credit.
Limite: per-txn/zi/săptămână la emitent 'a; pentru noii destinatari - mai jos.
Recurență: prin e-mandat/SEPA DD/Open Banking.

Rezumat

Pentru conversie - App2App/Embedded, pentru stabilitate - clear webhooks + recon.
Confirmarea online separată și creditul real (T + 1/T + 2) în logica de afaceri.
Nu fixați sume grele: configurații limită după bancă/țară + actualizare regulată.
Pentru abonamente, utilizați primul mandat de → de plată A2A, cu gestionare clară a UX și limite.