Ce que couvre l'intégration des paiements au-delà du tunnel de commande
Choisir une passerelle de paiement est une décision liée à la boutique, et l'échange qu'elle gère n'est qu'un instantané. La relation de paiement génère des données pendant des semaines, et chaque type de flux a une destination différente.
- Autorisation et capture : la boutique confirme la disponibilité des fonds, puis les capture, souvent au moment de l'expédition plutôt qu'à la commande
- Règlement : le prestataire regroupe les paiements capturés et les dépose, généralement nets de frais et avec un délai
- Remboursements et remboursements partiels : l'argent est restitué sur la transaction initiale, parfois longtemps après la clôture de la commande
- Rétrofacturations et litiges : les fonds sont annulés avec un code motif et une date limite pour fournir des preuves
- Frais : par transaction, par méthode et par devise, ce qui différencie le montant brut du montant net
Seul le premier point concerne la boutique. Les quatre autres relèvent de la finance, et ce sont eux qui se retrouvent sans destination si le prestataire de paiement est uniquement connecté au tunnel de commande.
Pourquoi les règlements ne correspondent-ils plus au carnet de commandes ?
Les prestataires de paiement regroupent les transactions capturées. Un dépôt de 48 000 EUR ne correspond à aucune commande unique dans l'ERP. Il correspond à plusieurs centaines de captures effectuées sur deux jours, moins les frais, moins trois remboursements, plus une annulation de rétrofacturation du mois précédent.
La multiplication des méthodes de paiement aggrave le problème. Les paiements par carte sont réglés selon un calendrier, les prélèvements automatiques selon un autre, et les solutions de paiement fractionné selon un troisième, chacun avec sa propre structure de frais et son propre format de rapport. Une entreprise utilisant quatre méthodes doit rapprocher quatre flux distincts avec un seul carnet de commandes.
La devise ajoute une couche de complexité supplémentaire. Un paiement encaissé dans une devise et réglé dans une autre entraîne une conversion que l'ERP n'a pas calculée ; le montant enregistré pour la commande et le montant reçu diffèrent donc d'une somme que personne n'avait prévue.
Le coût d'une intégration de paiement défaillante
Personne ne crée de ticket lorsqu'un règlement ne correspond pas à une commande. Les coûts s'accumulent silencieusement et apparaissent dans cet ordre :
- Clôtures mensuelles interminables : L'équipe financière rapproche manuellement les règlements des commandes dans un tableur, et la date de clôture dépend du nombre d'anomalies rencontrées.
- Revenus comptabilisés en retard : les commandes restent sans rapprochement, ce qui fait que le chiffre d'affaires déclaré accuse un retard sur l'activité réelle, proportionnel au temps nécessaire au rapprochement.
- Rentabilité des canaux basée sur des suppositions : les frais de paiement ne sont pas attribués par commande, ce qui rend la marge par canal et par produit purement estimative.
- Remboursements effectués en double : lorsque le système de paiement et l'ERP ne sont pas d'accord sur le traitement d'un remboursement, le service client en émet un second.
- Litiges perdus par dépassement de délai : Les preuves de rétrofacturation sont éparpillées entre la boutique en ligne, l'entrepôt et le portail du prestataire, et le délai expire avant que quelqu'un ne puisse les rassembler.
Intégration des paiements au sein d'une architecture composable
Auparavant, les entreprises utilisaient un seul prestataire de paiement pour une seule plateforme, et le plugin fourni par le prestataire couvrait l'essentiel des besoins. Cette configuration est devenue rare. Un détaillant de taille moyenne utilise généralement un prestataire principal, une méthode régionale pour un marché spécifique, une option de paiement sur facture ou fractionné, ainsi qu'une marketplace avec son propre flux de paiement.
Essentiel Antwerp est une marque de mode de luxe belge présente à l'international, tant en boutique physique qu'en ligne. En utilisant la plateforme d'intégration en tant que service (iPaaS) Alumio, elle a construit une architecture composable plutôt qu'une suite unique, combinant Microsoft Dynamics 365 Business Central pour la finance, Adobe Commerce pour la boutique en ligne, Channable pour le marketing et Adyen pour les paiements.
Le point crucial pour le rapprochement bancaire réside dans ce que cette architecture exige en arrière-plan. Lorsque les paiements, les commandes et les données financières sont répartis dans trois systèmes distincts, la connexion entre eux doit être rigoureusement encadrée, car aucun fournisseur ne contrôle l'ensemble de la chaîne.
Comment une plateforme d'intégration connecte les paiements à l'ERP
Décomposer un virement global en paiements individuels n'est que la première étape. Chaque paiement doit être associé à ses frais et à sa référence de commande afin que l'ERP puisse l'imputer au bon document. Ce travail nécessite une couche intermédiaire entre le prestataire de paiement et les systèmes financiers. Un outil de rapprochement dédié effectue ce travail efficacement, mais il doit être alimenté par les deux extrémités. Les plugins standards des prestataires ne vont pas aussi loin.
L'iPaaS Alumio occupe cette position stratégique, reliant le prestataire de paiement aux systèmes comptables. Ce processus prend quatre formes :
- Décomposition des règlements : un transformateur de données divise un dépôt groupé en transactions individuelles et associe chacune à sa référence de commande, permettant à l'ERP de recevoir des détails au niveau de la ligne plutôt qu'un montant global.
- Attribution des frais par commande : un mappeur de données associe chaque coût de transaction à la commande correspondante, faisant de la marge par canal une donnée précise plutôt qu'une estimation.
- Gestion unifiée des remboursements : un routage de données transmet le remboursement dès son émission, à la fois au prestataire de paiement et à l'ERP, évitant ainsi toute divergence sur le statut de l'opération.
- Centralisation des preuves : des journaux détaillés regroupent les enregistrements de commande, d'exécution et de paiement d'une transaction contestée, garantissant le respect des délais de réponse aux litiges.
Ces flux sont configurés plutôt que développés sur mesure pour chaque prestataire. Le transformateur de code est disponible lorsque la configuration ne suffit pas à exprimer une règle complexe, et l'écriture de code est privilégiée. L'ajout d'un nouveau moyen de paiement réutilise ainsi la logique de rapprochement déjà en place.
Ce qu'apporte une intégration de paiement connectée
La réussite d'une intégration de paiement ne se mesure pas au taux de conversion au moment du paiement. Elle se mesure à la capacité du service financier à clôturer le mois sans tableur Excel, et à la possibilité de connaître précisément la marge nette après frais pour chaque commande.
Les entreprises qui maîtrisent cet aspect cessent de considérer les prestataires de paiement comme un simple choix lié à la boutique en ligne pour les traiter comme un enjeu financier. Grâce à une plateforme d'intégration, l'ajout d'un moyen de paiement régional devient une décision commerciale plutôt qu'un casse-tête comptable, ce qui est déterminant lors de l'entrée sur un marché où les méthodes locales conditionnent la conversion.
L'entreprise bénéficie alors d'une clôture mensuelle qui ne dépend plus de rapprochements manuels, d'un chiffre d'affaires comptabilisé dès son acquisition et d'une vision claire de la rentabilité réelle de chaque canal après déduction des frais.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
