Vérité clientCommande
- Montant initial184,50 €
- Retour accepté34,50 €
- Solde acheté150,00 €
La commande explique ce que le client conserve ; elle ne remplace pas le statut financier.
API
Intégrateur API paiement : faire concorder transaction, commande et finance
Dawap relie votre PSP aux commandes, remboursements, écritures et outils de support. L’intégration ne déclare jamais un paiement réussi sur une simple réponse HTTP : elle corrèle la tentative, l’événement PSP, l’effet métier et le rapprochement attendu, puis donne une sortie claire aux écarts.
- Statuts PSP corrélés
- Refunds rapprochés
- Reprise sans double débit
APIs, données et infrastructures que nos projets savent connecter
Du besoin métier au run mesurable
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
actionnable
Réponse courte
Une intégration API paiement fiable prouve le même état dans le PSP, la commande et la finance.
Dawap construit le middleware qui corrèle autorisation, capture, événements, refunds, litiges et règlements avec les identifiants métier. Chaque transition garde sa preuve, son effet autorisé et sa stratégie de reprise ; les pages fournisseurs restent propriétaires de leurs objets spécifiques.
- Nommer une identité stable pour la tentative, l’opération PSP, la commande et chaque correction financière.
- Distinguer reçu, autorisé, capturé, remboursé, contesté et réglé avant de déclencher un effet irréversible.
- Prouver les six cas difficiles sur un flux témoin avant d’ajouter des pays, méthodes, canaux ou PSP.
Payment truth ledger · scénario illustratif
Un paiement n’est terminé que lorsque ses quatre vérités concordent.
Les références, montants et statuts ci-dessous sont fictifs. Le dossier montre la preuve attendue entre intention client, opération PSP, commande et rapprochement financier.
- 00 · intention 184,50 € demandés cart_4821 · EUR Reçue
- 01 · autorisation PSP-AUTH-7742 clé pay:cmd-4821:v1 Autorisée
- 02 · capture 184,50 € capturés event evt_cap_903 Relue
- 03 · refund partiel 34,50 € remboursés refund RF-118 · ligne 03 Propagé
- 04 · règlement 145,28 € attendus net 150,00 € · frais 4,72 € À rapprocher
Vérité opératoirePSP
- Capture relue184,50 €
- Refund confirmé34,50 €
- Net transaction150,00 €
La référence PSP et l’événement reçu ferment chaque transition sans déduire l’état d’une simple réponse.
Vérité de clôtureFinance
- Net transaction150,00 €
- Frais illustratifs− 4,72 €
- Règlement attendu145,28 €
L’écriture reste proposée tant que le règlement ou le rapport fournisseur ne justifie pas le solde.
Banc de contre-tests
Six incidents doivent conserver le même dossier et empêcher un second effet.
- 01Timeout après demanderechercher avant de recréer
- 02Double soumissionmême clé, même intention
- 03Webhook dupliquéun événement, un effet
- 04Ordre inversérelire l’objet courant
- 05Refund partielmontants et lignes liés
- 06Finance indisponibleretenir puis rejouer
Premier lot recommandé
Un parcours, un PSP, un mode de capture et une balance de preuve.
Le lot ne s’étend qu’après une capture, un refund, les six incidents et une reprise réellement jouée avec le produit, le support et la finance.
Quand le checkout dit “payé”
Le risque commence dans l’écart entre une réponse PSP et un état financier prouvé.
Une autorisation, un HTTP 200 ou un webhook reçu ne suffisent pas à fermer la transaction. L’intégration doit relier références, montants, événements et effets métier, puis garder un verdict ouvert tant qu’une vérité manque.
01
Temps mort
La requête expire alors que le PSP a peut-être accepté l’opération
Relancer aveuglément peut produire un second effet. La clé métier, la recherche et la relecture doivent décider avant toute nouvelle tentative.
02
Événement
Le webhook arrive deux fois, trop tôt ou après un état plus récent
L’événement brut reste une entrée. Le handler vérifie son identité, relit l’objet utile et ne rejoue que la transition encore autorisée.
03
Solde
Capture, refund, frais et règlement ne ferment pas au même moment
La finance doit voir le montant exposé, la pièce manquante et l’owner de l’écart sans reconstruire l’histoire depuis plusieurs exports.
Contrats de vérité paiement
Six contrats séparent un connecteur exploitable d’un simple bouton PSP.
Le paiement change plusieurs systèmes à des moments différents. Chaque transition doit donc dire quelle identité elle reconnaît, quel effet elle autorise et quelle preuve la ferme.
Une clé métier relie la tentative aux références PSP
Commande, opération, événement, refund et règlement conservent leur corrélation ; aucune identité n’est reconstruite depuis un montant seul.
Chaque statut possède un sens et un effet autorisé
Créé, autorisé, capturé, remboursé, contesté et réglé ne sont jamais rabattus sur un booléen payé ou échoué.
Le webhook est une entrée vérifiée, pas la décision finale
Signature, payload brut, identifiant, version et date sont conservés avant traitement asynchrone, relecture et déduplication.
Chaque correction explique ce qui reste à payer ou à rapprocher
Capture partielle, refund, frais, commission, devise et règlement gardent leur montant, leur référence et leur lien avec l’opération source.
Le système qui peut engager, rembourser ou comptabiliser est nommé
PSP, commande, marketplace, billing et finance gardent des responsabilités distinctes ; le middleware orchestre sans devenir une seconde vérité.
Un écart ouvre une action bornée au lieu d’un resync global
Contexte, montant exposé, ancienneté, owner, replay et compensation autorisée rendent l’incident exploitable par les équipes.
Méthode de preuve
Faire signer le verdict de la transaction avant d’optimiser son volume.
Dawap part d’un paiement que le produit, le support et la finance savent reconnaître. Nous nommons l’intention, les identités, le mode de capture, les transitions, les effets autorisés et la pièce qui ferme chaque étape. Le transport et l’interface viennent ensuite. Le périmètre ne s’étend qu’après les contre-tests et une reprise réellement jouée.
Reconnaître la tentative
Retrouver l’opération PSP et son effet possible même après une réponse perdue.
Décider une seule fois
Résister aux doubles soumissions et aux événements reçus plusieurs fois.
Expliquer le montant
Relier capture, refund, frais et règlement à la même transaction métier.
Reprendre sans redébiter
Rejouer seulement l’étape en défaut avec historique et autorisation explicite.
Premier lot paiement
Fermer une transaction difficile avant d’étendre le checkout.
On choisit un paiement avec capture ou refund et on le suit jusqu’à l’effet commande et au solde attendu. Le lot est accepté quand une relance ne redébite pas, qu’un webhook dupliqué ne rejoue pas l’effet et qu’un écart reste attribuable.
1 parcours
1 PSP
1 mode de capture
6 contre-tests
1 balance de preuve
Sorties attendues
Carte intention–PSP–commande–remboursement–finance avec owner et système faisant foi à chaque étape.
Contrat versionné des montants, devises, statuts, références, droits et événements utiles.
Journal reliant clé métier, requête masquée, réponse, webhook, opération PSP, effet commande et verdict.
Six contre-tests : timeout, double soumission, événement désordonné, refund partiel, devise incohérente et système aval indisponible.
Quarantaine avec motif, âge, montant exposé, owner, action autorisée et reprise ciblée.
Recette commune produit–support–finance, alertes, runbook et retour à un état sûr.
Recette du connecteur paiement
Trois scénarios qui doivent produire une preuve financière vérifiable.
Ces scénarios sont des modèles de recette à rejouer avec votre PSP, votre contrat, vos pays et vos règles. Ils ne sont pas présentés comme des capacités identiques chez tous les fournisseurs.
Le PSP a peut-être accepté, mais la réponse n’est jamais revenue.
- Scénario terrain
- Le client peut rafraîchir et la commande semble encore impayée. Une seconde création aveugle transformerait une coupure réseau en double risque financier.
- Architecture
- Clé métier stable, journal de tentative, recherche PSP, état intermédiaire et verrou avant nouvel appel.
- Livrable
- Fixture de paiement, coupure simulée, table de corrélation, opération relue et règle de nouvelle tentative.
- Décision
- Rechercher puis rapprocher l’opération existante ; isoler si son résultat ne peut pas être prouvé.
- Résultat vérifiable
- Une seule intention financière et un statut explicable côté commande.
Un ancien événement arrive après une transition plus récente.
- Scénario terrain
- Une notification répétée ou retardée ne doit ni réexpédier la commande, ni rouvrir un accès, ni écraser un refund déjà confirmé.
- Architecture
- Signature, persistance brute, identifiant d’événement, inbox, version d’objet et machine d’états métier.
- Livrable
- Séquence inversée, doublon volontaire, journal d’arbitrage, lecture de contrôle et preuve de l’effet unique.
- Décision
- Ignorer l’événement déjà consommé ou relire l’objet avant toute transition encore autorisée.
- Résultat vérifiable
- Un seul effet métier malgré plusieurs notifications.
Le remboursement est demandé, mais le règlement finance reste à fermer.
- Scénario terrain
- Le support voit une demande, le client attend le résultat et la finance doit distinguer brut, correction, frais et versement réel.
- Architecture
- Référence de refund, lignes de commande, statut asynchrone, avoir, balance d’écart et rapprochement du règlement.
- Livrable
- Jeu de montants, résultat PSP, notification client, écriture proposée et écart ouvert avec son owner.
- Décision
- Ne fermer le refund qu’après résultat confirmé ; garder le règlement séparé jusqu’à sa pièce de rapprochement.
- Résultat vérifiable
- Un remboursement traçable et une clôture qui n’efface pas l’écart.
Paiement, checkout, marketplace ou billing ?
Le bon périmètre dépend de la décision qui déclenche le projet.
Ce hub porte la transaction PSP transverse et sa preuve de run. Le parcours commerce, la responsabilité de plateforme, la clôture et l’abonnement conservent leurs pages propres.
Le besoin part d’une opération PSP à corréler au SI
Cette offre possède statuts, événements, idempotence, refunds, rapprochement et reprise entre PSP, commande, support et finance.
Le besoin principal est le panier, le checkout ou l’après-achat
La landing e-commerce possède l’expérience et la commande ; le connecteur paiement devient une brique de ce produit.
Le projet part de vendeurs tiers ou d’un revenu récurrent
Paiement marketplace garde onboarding, responsabilité et split ; Chargebee garde contrat, entitlement et cycle de billing.
PSP et solutions
Choisir l’intégration paiement à cadrer
Chaque PSP a ses objets, webhooks, limites, règles de sécurité et modèles de règlement. Ces portes d’entrée permettent de traiter le bon cas sans mélanger checkout, finance et marketplace.
Frontières de responsabilité
Orienter le projet vers la page qui possède sa décision principale.
Le mot paiement traverse plusieurs offres. Ces quatre sorties évitent de faire porter au connecteur PSP un produit e-commerce, une plateforme, une clôture ou un cycle d’abonnement complet.
Avis & exigence projet
Des intégrations paiement jugées sur la fiabilité des statuts financiers.
5/5★★★★★Avis clients Dawap
“
Paiements, refunds, impayés, abonnements et écritures sont modélisés sans ambiguïté.
“
Idempotence, signatures, retries et rapprochements évitent les doublons et pertes de signal.
“
Les équipes peuvent suivre les écarts, rejouer les flux et comprendre les incidents.
Création d’un site e-commerce Symfony 7 pour le Domaine de Corps de Loup : boutique de vins, panier, commandes, paiement Monetico, back-office, contenus multilingues, galerie photo, formulaires contact et séminaire, réservations de visites, tests, CI/CD et environnements Docker pour tenir l’exploitation après la mise en ligne.
Dawap a sécurisé chaque transition du cycle de commande 1UP Distribution : panier métier, relecture, adresses, réservation temporaire, découpage par zones, import Odoo idempotent, progression, reprise, annulation, expédition, facture et avoir. Un workflow qui distingue clairement demande reçue, stock protégé et engagement confirmé.
Le paiement via API ne se résume pas à encaisser. Il faut cadrer PaymentIntents, captures, refunds, webhooks, idempotence, wallets, KYC et réconciliation sans transformer le support en table de reprise manuelle. Ce cadrage protège marge, trésorerie et taux d’acceptation avec une preuve de reprise exploitable.
Une intégration API peut sembler fonctionner correctement pendant des semaines, puis générer soudainement des doublons de commandes, de paiements ou d’écritures comptables. Ce type d’incident coûte rarement seulement du temps technique. Il mobilise aussi le support, la finance et le commerce dans le run métier.
Stripe doit expliquer le cash, pas seulement encaisser. PaymentIntent, refunds, frais, balance transactions, factures, litiges et payouts doivent être rapprochés avec les commandes et la compta. L'article montre comment éviter les écarts finance et les réponses support impossibles à prouver vite en B2B.
Stripe Connect, Mangopay et Lemonway ne se choisissent pas au logo. L'article aide à arbitrer selon wallets, KYC/KYB, payouts, commissions, refunds, litiges, finance, support, preuve comptable et capacité de run marketplace. Il donne une grille claire pour choisir le PSP opérable avant de figer l'architecture.
Questions d’achat
Questions fréquentes sur l’intégration API paiement
Les réponses utiles avant d’autoriser une transaction PSP à changer commande, accès client, remboursement ou écriture financière.
01Qu’est-ce qu’un intégrateur API paiement ?
Il conçoit le contrat et le middleware entre le PSP et les systèmes qui dépendent de la transaction : commande, support, ERP ou finance. Il corrèle identités, statuts, événements, refunds, preuves et reprises.
02Pourquoi passer par une agence API paiement plutôt qu’un module PSP ?
Un module peut suffire pour un checkout standard. L’intégration sur mesure devient utile quand l’état doit rester cohérent entre PSP, commande, remboursements, support et finance, avec des règles et une reprise propres à votre SI.
03Comment gérez-vous les webhooks de paiement ?
Le contrat dépend du fournisseur. En général, nous vérifions l’authenticité selon sa méthode officielle, conservons le payload utile, dédupliquons l’événement, traitons l’effet en asynchrone et relisons l’objet lorsque l’ordre compte.
04Comment éviter un double débit après un timeout ?
Le connecteur conserve une clé stable, journalise la tentative et recherche ou relit l’opération avant tout nouvel appel. Une réponse absente reste un état inconnu à rapprocher, jamais une preuve que le PSP n’a rien fait.
05Comment rapprocher un refund partiel ?
La demande, le résultat PSP, les lignes concernées, l’avoir éventuel et le règlement restent séparés mais corrélés. Le dossier ne se ferme que lorsque le montant remboursé et son effet financier sont prouvés.
06Comment reprendre une intégration paiement existante sans risquer la production ?
Dawap commence en lecture et cartographie statuts, identités, événements, secrets, erreurs et reprises. Une transaction témoin, un environnement de test, des contre-tests et une bascule progressive précèdent toute extension.
Intégration paiement · preuve financière
Votre connecteur peut-il prouver ce que le PSP, la commande et la finance ont réellement accepté ?
Dawap cadre une transaction, ses identités, ses statuts, ses six contre-tests, sa balance de preuve et sa reprise avant d’ouvrir le reste des parcours.
Cadrer mon flux paiement