Sofort/Klarna: pay-by-bank

1) Qu'est-ce que Sofort/Klarna Pay-by-Bank

Sofort (aujourd'hui Klarna Pay Now/Pay-by-Bank) est un outil A2A qui permet à l'acheteur de payer sa commande directement à partir de son compte bancaire via une banque en ligne/application mobile. Le flux est typiquement construit sur la issuer-redirect/App2App de confirmation SCA (PSD2), et le merchant obtient une autorisation en ligne (success), puis un crédit bancaire sur les rapports/calculs du fournisseur.

• Faible coût par rapport aux MDR de cartes.
• Statut en ligne (succès/échec) presque immédiatement, le crédit n'étant pas toujours instantané (généralement T + 1/T + 2).
• Géographie étendue dans l'UE/EEE (l'Allemagne/Autriche est particulièrement forte), soutien à des dizaines de banques émettrices.
• Le minimum de détails de paiement de l'acheteur est le choix de la banque et la confirmation.

2) Rôles et participants

Klarna/Sofort (schéma/fournisseur) : itinérance vers les banques, statuts, rapports, calculs, retours.
Issuer (banque du payeur) : SCA, confirmation de débit, limites/antifrod.
Merchant PSP/Acquirer : connexion au merchant, API/SDK, webhooks et recon.
Merchant (vendeur) : initiation du paiement, traitement des statuts/retours, rapprochement.

3) Flux de paiement : Redirect et App2App

3. 1 Classic redirect

1. Checkout merchant → la sélection « Pay by bank (Sofort/Klarna) ».
2. La liste des banques → redirect dans la banque en ligne (ou sur la page hébergée du fournisseur) → SCA.
3. La banque confirme le paiement → le retour au merchant avec le statut (success/failed/canceled/pending).
4. Merchant enregistre la commande comme « payé/en attente », attend le webhook/rapport d'inscription.

3. 2 App2App / Mobile

Sur les appareils mobiles, le merchant ouvre l'application bancaire deeplink/intent → la confirmation → le retour selon le schéma ci-dessus.
La conversion est plus élevée, le frottement est plus faible ; gardez fallback sur le web redirect.

3. 3 Request-to-Pay/Options embarquées

Un certain nombre de banques ont accès à request-to-pay/PIS via les interfaces du fournisseur (l'acheteur reçoit une demande à la banque-application).
Les widgets Embedded de PSP simplifient la liste des banques, des erreurs et des statuts.

4) Limites et comportement des banques

• Per-transaction, per-day/semaine à la banque du payeur.
• Les nouveaux destinataires/merchants sont des seuils réduits, un extrait est possible.
• Canaux (mobile/Web), règles de velocity, signaux géo/device.
• Dans certains pays/banques, des exceptions de seuil SCA (RA, TRA) sont possibles - dépendent de la banque.

5) Statuts et inscription (autorisation vs établissement)

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Pending est possible en cas de retard de confirmation ou de vérification asynchrone.
Settlement : le crédit réel provient des rapports du fournisseur (généralement T + 1/T + 2 jours bancaires ; dépend du pays/banque/système de compensation).
Pour les services critiques, utilisez le modèle « autorisation ⇒ exécution conditionnelle » avant de confirmer l'inscription.

6) Retours, retours partiels et disputes

Chargeback (comme dans les cartes) est absent. Le retour est une nouvelle opération de crédit par l'intermédiaire du fournisseur au payeur.
Les fonds partiels sont pris en charge.
Les délais de remboursement sont bancaires (T + 1/T + 2).
Les disputes/plaintes se déroulent selon la procédure ODR du fournisseur + par l'intermédiaire de la banque du payeur ; préparer les logs de commande, proof-of-delivery/services.

7) Commissions et économie

Habituellement, fix/faible pourcentage de la transaction + frais pour les fonctions de plateforme (checkout hébergé, rapports, ODR).
Tenez compte des coûts de support (pending/expiries), des risques d'incidents et des coûts de transaction de recon.

8) Rapprochement et établissement de rapports (reconnaissance)

Enregistrez 'paymentId/transactionId' du fournisseur, 'orderId', banque-issuer, horodatages, statuts.
Activez webhooks sur le changement de statut et auto-recon quotidien.
Combinez les événements en ligne (succès/pending) avec les états financiers (crédits/retours/corrections).
Gardez l'UTR/référence bancaire du rapport pour chaque transaction.

9) Pratiques UX

Annuaire des banques : pré-remplir la dernière sélection, trier par popularité/banque de l'appareil.
Mobile-first : Proposez un App2App, fallback - web redirect.
Erreurs et répétitions : donnons des raisons compréhensibles (limite, échec SCA, délai), bouton de répétition et alternatives.
Idempotence : 'orderId' + clé d'idempotence pour les répétitions sécurisées.
Reçu : montant, date/heure, 'transactionId', banque, canal (App2App/Redirect).

10) Radiations récurrentes et mandats

Le Sofort classique est un-off. Pour les modèles récurrents, on utilise un lien : le premier paiement A2A → e-mandate/SEPA DD/Open Banking PIS pour l'avenir.
Gérer les mandats (limite, fréquence, notifications), conserver les journaux d'acceptation.

11) Conformité, sécurité, données

PSD2/SCA : confirmation à la banque, binding de device, antifrod de la banque.
Minimisation des PII : ne stocker que les attributs nécessaires ; Chiffrer le PII ; Signatures Web HMAC.
GDPR/Logs : consentement, droit de suppression, audit des modifications.

12) Verticales à haut risque (y compris iGaming)

La disponibilité de Pay-by-Bank pour certaines catégories est limitée au fournisseur/aux banques en vertu des politiques internes et du droit local.
Attendez-vous à des limites réduites, add. CUS/finmonitoring, hold's possibles.
Gardez les rails alternatifs (cartes, SEPA, open banking A2A, bons) et la segmentation du trafic.

13) Intégration du merchant : options

1. Hosted/Embedded от PSP/Klarna

Démarrage rapide : widget de sélection de banque, statuts, erreurs, webhooks sortie de la boîte.

2. Server-to-Server + redirect/App2App

Plus de contrôles : propre page des banques, traitement fin des erreurs, propre QR/Deep Link.

3. Factures/Request-to-Pay

Envoyer une demande de paiement (email/SMS/lien), pratique pour B2V/services.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotence et table dedupe par 'orderId'.
• Retrai par exposant pour obtenir les statuts, dead-letter pour les réponses instables.
• Catalogues : banques/pays, limites/codes d'erreur, métriques SLA par issuer'am.

14) Architecture « Sofort/Klarna Gateway »

Couche API (REST/GraphQL) pour la caisse.
Files d'attente d'événements : États-participants → facturation/CRM/analyse.
Observability : conversion par banques/canaux, « pending→success/expired », latence, panne SCA.
Sécurité : vault pour les secrets, fournisseur IP-allowlist, jetons anti-replay, validation stricte redirect-URI.

15) Chèque-liste de sortie dans la prod

1. Sélectionnez le canal PSP/Klarna/Sofort avec la géographie de banque souhaitée.
2. Implémentez 'createPayment' + sélection banque + redirect/App2App avec fallback.
3. Connectez les webhooks, l'idempotence, les délais et la répétition des statuts.
4. Configurez recon (daily + full), stockage UTR/fin-références.
5. Inclure partial/full refunds et le règlement ODR dans le saphport.
6. Préparez des scénarios UX d'échec/limites et d'autres méthodes.
7. Testez les banques mobiles (iOS/Android) et les principaux issuer's dans les pays cibles.
8. Conservez le manuel des limites et la page des états des incidents.

Carte de repères

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement : Plus souvent T + 1/T + 2 ; prévoir une « exécution conditionnelle » avant le prêt.
Limites : per-txn/day/week chez issuer'a ; pour les nouveaux bénéficiaires - ci-dessous.
Recurrent : via e-mandate/SEPA DD/Open Banking.

Résumé

Pour la conversion - App2App/Embedded, pour la durabilité - des webhooks + recon clairs.
Partagez la confirmation en ligne et le crédit réel (T + 1/T + 2) dans la logique d'entreprise.
Ne fixez pas de montants rigides : configurations des limites par banque/pays + actualisation régulière.
Pour les abonnements, utilisez le premier paiement A2A → le mandat, avec gestion UX compréhensible et limites.