Stripe est souvent intégré pour encaisser. Mais dès que la finance demande un rapprochement propre, il faut relier paiement, refund, frais, facture et versement bancaire.
La documentation Stripe rappelle que le PaymentIntent suit le processus de collecte et qu’il est recommandé d’en créer un par commande ou session. Les refunds et balance transactions complètent ensuite la lecture finance.
Une intégration Stripe API doit donc expliquer le cash, pas seulement confirmer un paiement.
Le cadrage doit aussi séparer ce qui relève du checkout, du back-office, de la comptabilité et du support. Un paiement réussi peut encore cacher un refund partiel, un litige, un frais non ventilé ou un versement bancaire impossible à rapprocher.
Le critère finance
Si une équipe ne peut pas passer d’une facture au PaymentIntent, au refund et au net encaissé, le rapprochement reste incomplet.
Passer du paiement au rapprochement
Un statut “succeeded” ne suffit pas à la clôture. Il faut comprendre frais, net, refund, litige et date de disponibilité.
Le flux doit lier ces éléments à la commande et à la facture. Sans cette chaîne, l’équipe finance travaille à partir d’exports au lieu de preuves transactionnelles.
Utiliser PaymentIntent comme point d’ancrage
Le PaymentIntent donne l’historique des tentatives et la cohérence du paiement. Il doit être relié à la référence métier.
Une clé externe évite les paiements orphelins.
Lire capture et statuts
Selon le parcours, la capture peut être automatique ou différée. Le back-office doit distinguer autorisé, capturable, capturé, échoué ou annulé.
Ces statuts changent les actions support.
Rapprocher refunds et avoirs
Un refund Stripe peut être partiel et lié à un PaymentIntent ou une charge. Il doit rester lié à l’avoir et à la ligne de commande.
Le flux doit empêcher de rembourser plus que le solde disponible.
La finance doit aussi savoir si le refund correspond à un geste commercial, un retour produit, une annulation ou un litige.
Expliquer frais et net
Les frais expliquent la différence entre montant payé et cash net. Ils doivent alimenter le reporting finance.
Un export brut sans frais retarde le rapprochement.
Exploiter balance transactions
Les balance transactions aident à comprendre les mouvements qui composent le solde Stripe : charges, refunds, transfers et frais.
Elles doivent être rapprochées avec les écritures internes. Le modèle doit conserver la référence de mouvement, la devise, la date de disponibilité et le lien avec le paiement d’origine.
Relier factures et commandes
La facture doit porter la référence commande et la référence paiement. Sans cela, le paiement est encaissé mais mal expliqué.
Cette clé est aussi essentielle pour les avoirs.
Ne pas oublier disputes et risques
Les litiges et échecs doivent remonter dans le support et la finance. Ils ne doivent pas rester dans le dashboard PSP.
Le flux doit porter état, montant, preuve et action suivante. Cette couche évite de découvrir un impact cash uniquement au moment du versement ou de la clôture mensuelle.
Piloter les écarts finance
Le run suit paiements non rapprochés, refunds orphelins, frais non ventilés, factures sans paiement et litiges ouverts.
Ce pilotage doit être priorisé par impact cash, pas par ordre d’arrivée technique. Les écarts qui bloquent une facture, un avoir ou un reporting de marge passent avant les écarts purement informatifs.
Un bon tableau de bord Stripe ne se contente donc pas d’afficher des erreurs API. Il explique la prochaine décision : relancer un webhook, corriger une facture, attendre un versement, ouvrir un ticket support ou documenter un écart accepté.
- Relier PaymentIntent et commande.
- Tracer refunds partiels.
- Récupérer frais et net.
- Rapprocher versements.
- Prioriser écarts à impact cash.
Préparer clôture, support et audit
Une intégration Stripe vraiment exploitable doit préparer trois usages différents : la clôture finance, la réponse support et l’audit des mouvements. Ces usages partent des mêmes objets, mais ils ne regardent pas les mêmes preuves.
La finance veut expliquer le net et les frais. Le support veut comprendre pourquoi un client a été débité, remboursé ou contesté. L’audit veut retrouver la chaîne sans dépendre d’un export fragile. Quand ces trois lectures ne sont pas prévues, chaque incident devient une reconstitution.
Le signal faible à surveiller est l’écart accepté oralement. Si une équipe finit par dire “on sait que Stripe ne tombe jamais exactement juste dans l’export”, la dette est déjà là. Elle ne se voit pas dans la conversion, mais elle ralentit clôture, marge et décision.
- Conserver la référence Stripe, la référence commande et la référence facture dans le même écran.
- Ventiler frais, refunds et litiges au bon niveau : commande, ligne ou mouvement financier.
- Identifier les écarts acceptés, corrigés et encore ouverts.
- Prévoir une reprise contrôlée avant chaque clôture mensuelle.
Le bon arbitrage consiste parfois à refuser une automatisation de refund trop rapide tant que la preuve comptable n’est pas prête. La vitesse de remboursement ne doit pas créer un écart que la finance découvrira trois semaines plus tard.
Conclusion : Stripe doit expliquer le cash
Stripe API devient stratégique quand elle explique le cash réel : brut, frais, net, refunds, litiges et factures. C’est ce qui transforme un paiement en preuve finance.
Pour les marketplaces, lisez Stripe Connect : paiements marketplace et reversements.
