Shopify affiche une commande payée, mais la finance doit rapprocher bien plus : capture, refund, frais, litige, devise, versement, facture et éventuel avoir.
Stripe et PayPal ne modélisent pas les paiements de la même façon. Les docs Stripe mettent notamment PaymentIntent, refund et balance transactions au cœur du suivi. PayPal distingue Orders, Payments, captures, refunds et litiges.
Une API paiement bien cadrée devient donc le socle quand le besoin touche le rapprochement et le pilotage financier.
Le sujet devient critique quand l’équipe finance doit expliquer un écart entre commande Shopify, net PSP, frais, remboursement et versement bancaire.
Le vrai sujet
Un statut Shopify “paid” ne suffit pas à expliquer le cash encaissé, les frais, les refunds et les écarts comptables.
Pourquoi le paiement devient un flux finance
Le paiement touche la conversion, le support et la comptabilité. Dès qu’il y a plusieurs PSP, la lecture devient vite fragmentée.
Le flux doit relier événement de paiement, commande Shopify, facture, remboursement et versement bancaire.
Séparer Shopify du PSP
Shopify porte la commande et l’expérience marchande. Le PSP porte la transaction, ses statuts, frais et incidents.
Le rapprochement doit garder les deux visions au lieu de forcer l’une à remplacer l’autre.
Lire PaymentIntents, refunds et frais
Stripe recommande un PaymentIntent par commande ou session de paiement. Le flux doit ensuite récupérer capture, refund et balance transactions pour comprendre le net.
Un refund partiel doit rester relié à la ligne de commande, à l’avoir et au paiement initial.
Lire captures, refunds et litiges PayPal
PayPal combine Orders et Payments pour autoriser, capturer, rembourser et afficher les informations de paiement. Les litiges ont leur propre cycle.
Le flux doit suivre capture, remboursement, dispute et payout sans mélanger les identifiants.
Rattacher commandes et factures
Une facture doit être rattachée à la commande Shopify et à la transaction PSP. Sans cette clé, chaque remboursement devient une recherche manuelle.
L’avoir doit suivre la même traçabilité.
Ce rattachement doit aussi survivre aux corrections. Si une commande change de statut, si un refund est partiel ou si une capture arrive en retard, la facture ne doit pas perdre son lien avec le mouvement financier d’origine.
Suivre frais et versements
Les frais PSP, conversions et délais de versement expliquent l’écart entre chiffre d’affaires et cash reçu. Ils ne doivent pas rester dans un export séparé.
Le rapprochement doit produire un montant net exploitable par la finance.
Traiter litiges et chargebacks
Un litige peut bloquer du cash, déclencher une preuve support et nécessiter une écriture comptable. Il doit remonter comme un événement prioritaire.
Le support doit voir la cause, l’état, la preuve demandée et l’impact financier.
Reprendre les écarts
La reprise doit comparer commande, PSP, facture et versement avant correction. Créer un avoir sans preuve paiement peut aggraver l’écart.
Chaque correction doit être journalisée avec son origine.
La reprise doit distinguer erreur de statut, frais manquants, refund partiel, litige ouvert et versement non encore reçu.
Piloter le cash e-commerce
Le pilotage doit suivre paiements capturés, refunds, frais, litiges, versements attendus et écarts non rapprochés.
La priorité n’est pas seulement de fermer les écarts. Elle est de savoir lesquels empêchent la clôture, lesquels bloquent le support et lesquels peuvent attendre le versement suivant.
- Comparer brut Shopify et net PSP.
- Isoler refunds partiels.
- Classer litiges par cause.
- Rapprocher facture et paiement.
- Mesurer les écarts restants.
Sécuriser clôture et support
Le rapprochement Shopify, Stripe et PayPal doit être pensé pour deux moments très concrets : la clôture comptable et la réponse support. Si ces deux usages ne voient pas la même preuve, les équipes finissent par arbitrer à la main.
Le coût caché apparaît dans les micro-écarts qui reviennent tous les mois : refund partiel non ventilé, frais PSP absents du reporting, avoir émis sans mouvement financier, litige visible dans PayPal mais absent du back-office, versement bancaire regroupé sans détail exploitable.
Le signal faible à surveiller est l’export “retraité”. Dès qu’un fichier doit être corrigé à chaque clôture, le problème n’est plus un reporting; c’est une intégration incomplète.
- Rendre visibles les mouvements non rapprochés avant la clôture, pas après.
- Donner au support une chronologie unique : commande, capture, refund, litige, facture et versement.
- Bloquer les remboursements incohérents avec l’avoir ou le solde disponible.
- Conserver un état accepté pour les écarts qui ne doivent pas être corrigés automatiquement.
La meilleure automatisation n’est donc pas celle qui ferme tous les écarts seule. C’est celle qui sait distinguer ce qui peut être corrigé, ce qui doit être expliqué et ce qui doit rester bloqué jusqu’à décision humaine.
Conclusion : le rapprochement doit être conçu
Shopify, Stripe et PayPal peuvent cohabiter proprement si le rapprochement est conçu comme un flux métier, pas comme une exportation finance tardive.
La clé est de conserver les liens : commande, transaction, capture, refund, facture, avoir, frais et versement.
Quand ces liens existent, la finance réduit les écarts, le support répond plus vite et les automatisations paiement deviennent plus sûres.
Pour approfondir Stripe, continuez avec Stripe API : paiements, refunds, frais et factures, puis cadrez le socle avec l’intégration API paiement.
