Le vrai enjeu d'une intégration API Mollie n'est pas de créer un paiement et de rediriger le client vers une page checkout.
Le risque apparaît quand un paiement reste open, devient expired, passe paid sans
commande corrélée, ou déclenche un refund que la finance ne sait pas rapprocher.
Mollie est souvent choisi pour sa simplicité et ses moyens de paiement européens. Cette simplicité devient pourtant une douleur opérationnelle si le SI ne distingue pas payment ID, metadata, webhook, statut définitif, statut temporaire, capture, refund, settlement et abonnement récurrent.
Le signal faible se voit quand l'équipe traite le retour navigateur comme une preuve de paiement, ou quand le support ouvre le Dashboard Mollie pour savoir si une commande peut être livrée. Le paiement semble fonctionner, mais la source de vérité se déplace déjà entre boutique, PSP, ERP, support et comptabilité.
Le bon arbitrage consiste à traiter Mollie comme une chaîne de décisions asynchrones. Le webhook signale un changement, le connecteur relit le paiement, compare le statut au métier, applique une action autorisée et conserve une preuve utilisable par le support comme par la finance.
Dawap traite Mollie comme une intégration API reliée aux flux API paiement. Notre accompagnement intégrateur Mollie aide à relier checkout, e-commerce, marketplace, ERP, support, abonnements et finance avec une preuve de run exploitable.
Pour qui Mollie devient un sujet critique
Mollie devient critique pour les e-commerces européens, DNVB, PME internationales, plateformes B2B, marketplaces légères et produits sur abonnement qui veulent proposer cartes, iDEAL, Bancontact, virement, PayPal ou moyens locaux sans dette support.
La priorité augmente dès que le paiement déclenche une livraison, une réservation, un accès numérique, une facture, un avoir, un mandat, un paiement récurrent ou un rapprochement comptable. Le statut Mollie ne reste plus une information de caisse; il devient une décision métier.
Le sujet est particulièrement sensible quand les moyens de paiement n'ont pas les mêmes délais. Un paiement carte, un iDEAL abandonné, un virement bancaire ou un paiement récurrent ne produisent pas la même attente opérationnelle, même si le back-office aimerait voir un statut unique.
Le bon signal de cadrage est simple: si un statut Mollie peut changer une commande, une livraison, un remboursement, une facture ou une relance client, alors le connecteur doit être conçu comme une architecture de run, pas comme un bouton de paiement posé à côté du tunnel de commande.
1. Créer payment, checkout link et metadata
Créer le payment avec une référence exploitable
La Payments API commence souvent par POST /v2/payments. Le connecteur crée un paiement avec montant, devise,
description, redirectUrl, webhookUrl et metadata permettant de relier le paiement à la commande
interne.
Mollie attribue ensuite un identifiant de paiement, souvent au format tr_.... Cet identifiant doit être stocké
immédiatement, exposé au support et relié à la commande, au panier, au client, au canal, au profil et à la version de prix.
La description ne doit pas être un libellé décoratif. Mollie recommande d'utiliser un identifiant unique pour relier le paiement au back-office et à la comptabilité. Cette règle devient précieuse lors d'un export ou d'un rapprochement.
Le mode test ou live doit également rester visible. Une erreur d'environnement peut donner l'impression qu'un paiement existe alors qu'il ne concerne pas le bon profil, le bon canal ou le bon périmètre financier.
Rediriger sans confondre retour client et preuve de paiement
Après création du payment, Mollie renvoie une URL dans _links.checkout. Le front peut rediriger le client vers
cette URL, puis le client revient vers le redirectUrl prévu par le marchand.
Ce retour ne doit pas valider la commande à lui seul. Le client peut revenir avant que le webhook soit traité, abandonner son parcours, changer de moyen de paiement ou se trouver dans un statut encore temporaire.
La contre-intuition utile est là: plus Mollie rend le checkout simple, plus le serveur doit rester strict. Le retour navigateur rassure l'utilisateur, mais la décision métier doit venir du statut relu côté API.
Utiliser metadata comme pont, pas comme base de vérité
Les metadata permettent de conserver des informations utiles autour du payment, par exemple un identifiant de commande ou de dossier. Elles aident à relire un webhook, un refund ou un paiement récurrent sans repartir d'un export.
Elles ne remplacent pas la base interne. Le SI doit garder sa propre preuve: montant attendu, devise, taxe, canal, statut normalisé, payment ID, mode test ou live, date de création et dernière décision appliquée.
Un modèle robuste garde aussi la version de la commande au moment du paiement. Si le panier, l'adresse ou les frais changent après la création du payment, l'équipe doit savoir quelle version a été présentée au client.
2. Lire open, pending, authorized, paid et expired
Distinguer les états temporaires
Le statut open signifie que le paiement est créé, sans action significative encore réalisée. Il ne déclenche pas
de webhook selon la documentation Mollie, et ne doit pas bloquer le SI comme un incident.
Le statut pending indique qu'un processus de paiement a commencé mais n'est pas terminé. Mollie précise que rien
n'a généralement besoin d'être fait côté marchand dans cet état temporaire.
Le back-office doit donc afficher une attente lisible. Un paiement pending ne doit pas être traité comme paid, mais il ne doit pas non plus produire une annulation automatique qui casserait un moyen de paiement plus lent.
Traiter paid comme définitif, après corrélation
Le statut paid indique que le paiement est réussi et définitif. C'est le signal attendu pour déclencher les suites
métier, à condition que le montant, la devise, la commande et le contexte interne correspondent bien.
Un paiement paid mais mal corrélé ne doit pas libérer automatiquement une livraison. Il doit passer en quarantaine avec payment ID, metadata, montant, commande candidate et action support autorisée.
Cette prudence évite les erreurs coûteuses: un client payé sans commande claire, une facture créée sur le mauvais panier, ou une livraison déclenchée alors que la commande interne a été annulée.
Cette grille doit rester lisible par moyen. iDEAL, Bancontact, virement bancaire, carte, Klarna, Riverty ou Billie peuvent imposer des attentes, des autorisations ou des écritures différentes. Le back-office gagne à afficher un vocabulaire précis plutôt qu'un état universel qui gomme les contraintes locales.
Respecter expired, failed et canceled
Les statuts expired, failed et canceled sont définitifs. Ils doivent fermer le parcours
ou déclencher une relance selon la règle commerciale, sans être écrasés par un retour front tardif.
Mollie documente des délais d'expiration qui varient selon les moyens de paiement, avec des écarts forts entre moyens rapides et virement bancaire. Le connecteur ne doit pas deviner ces délais; il doit attendre le webhook et relire le payment.
Contrairement à ce que l'on croit, prédire l'expiration est souvent plus risqué qu'attendre le statut officiel. Une estimation locale peut annuler trop tôt une commande qui dépend d'un moyen de paiement plus long.
Le bon compromis consiste à afficher une attente compréhensible au client tout en laissant Mollie trancher l'état final. Le SI évite ainsi de convertir une information d'expérience utilisateur en décision comptable prématurée.
Mapper authorized sans promettre paid
Le statut authorized existe pour les moyens de paiement qui supportent les captures. Il indique qu'une capture
peut être créée tant que l'autorisation reste exploitable.
Cet état ne doit pas être confondu avec paid dans une logique de fulfillment. Une commande authorized peut attendre une capture, une expédition, un contrôle stock ou une décision de risque avant de produire la suite métier.
Le support doit voir cette frontière. Dire "Mollie a autorisé" ne suffit pas; il faut savoir si l'entreprise doit capturer, annuler, attendre, relancer ou isoler le dossier.
3. Webhooks Mollie: notifier puis relire
Traiter le webhook comme un signal de rellecture
Le webhook Mollie ne doit pas être traité comme une source complète de vérité. Il signale qu'un payment a changé, puis le connecteur doit récupérer le payment via l'API pour lire son statut actuel et ses données utiles.
Cette rellecture protège contre les erreurs de synchronisation. Elle permet de vérifier payment ID, statut, montant, devise, metadata, mode, liens associés et éventuels objets de capture, refund ou settlement.
Le point de vigilance terrain est la rapidité de réponse. Le point d'entrée webhook doit journaliser, répondre proprement et déléguer le traitement métier à une file observée, afin d'éviter les retries inutiles.
Le webhook ne doit pas attendre un ERP lent, une facture ou un email client. Il doit prouver la réception puis laisser un worker appliquer la décision, avec des retries contrôlés et une trace consultable.
Dédupliquer les notifications avant d'agir
Un webhook peut revenir après un timeout, une indisponibilité ou une réponse serveur incorrecte. Le connecteur doit conserver l'identifiant du payment, l'heure de réception, le statut relu, la décision appliquée et la trace de corrélation.
Une même notification ne doit pas produire deux confirmations client, deux livraisons, deux écritures ERP ou deux refunds. La déduplication doit être visible dans la fiche support.
Le support doit comprendre pourquoi un event a été ignoré. "Déjà traité" est une décision utile si elle est prouvée; c'est une source de confusion si elle reste cachée dans un log technique.
Appliquer la décision dans l'ordre métier
L'ordre d'arrivée ne suffit pas. Un statut expired peut arriver après une relance client, un statut paid peut arriver après une correction support, et un paiement récurrent peut apparaître sans payment ID connu à l'avance.
Le worker doit comparer le statut Mollie à l'état courant de la commande. Il applique l'event s'il confirme une progression, l'isole s'il contredit une décision plus récente, ou déclenche une revue si le payment ne correspond à aucune commande.
Cette règle évite de faire reculer une commande déjà stabilisée. Elle donne aussi un langage commun aux équipes: reçu, relu, accepté, ignoré, isolé ou repris.
4. Captures, refunds et balance disponible
Capturer seulement les payments autorisés
Mollie permet de capturer un paiement autorisé via /v2/payments/{paymentId}/captures lorsque le paiement a été
configuré avec captureMode: manual et que le moyen de paiement le supporte.
La capture doit être reliée à une décision métier: expédition, prestation validée, stock confirmé, risque accepté ou période de réserve terminée. Capturer sans événement métier crée une dette côté support et finance.
Si aucun montant n'est fourni, l'endpoint capture le montant autorisé complet selon la documentation. Le SI doit donc éviter les captures implicites quand une livraison partielle ou une annulation partielle reste possible.
Le mode captureMode: manual doit être choisi volontairement. Il ajoute de la maîtrise sur le fulfillment, mais
il ajoute aussi une responsabilité de suivi sur les authorisations qui attendent capture.
Créer des refunds avec une preuve d'avoir
L'endpoint /v2/payments/{paymentId}/refunds crée un refund pour un paiement donné. Le refund doit porter montant,
devise, description, metadata, motif support, avoir et lien vers la commande.
Les refunds partiels sont supportés, et plusieurs refunds partiels peuvent être créés si nécessaire. Le connecteur doit donc suivre le cumul remboursé, le solde restant et les interdits de reprise.
Un refund ne doit jamais être un bouton isolé. Il modifie la promesse client, la comptabilité, le stock, la marge et parfois la relation avec un chargeback ou un paiement récurrent.
Suivre les statuts de refund
Les refunds Mollie ont leurs propres statuts: queued, pending, processing,
refunded, failed ou canceled. Ils ne doivent pas être écrasés par le statut du payment.
Le statut queued peut notamment apparaître lorsque la balance disponible ne suffit pas encore à couvrir le
refund. Le support doit savoir expliquer ce délai au client et à la finance.
Le statut refunded clôt le dossier côté remboursement, mais le rapprochement comptable peut demander une autre
preuve: date, montant, refund ID, payment ID, avoir, export et settlement.
La finance doit également voir les refunds échoués ou annulés. Un remboursement demandé puis failed ne doit pas rester dans l'ERP comme un avoir définitivement exécuté, sinon la clôture devient une enquête manuelle.
5. Idempotence, retries et doubles gestes
Protéger les POST sensibles avec une intention stable
Mollie documente l'idempotency API pour éviter qu'un retry ne crée plusieurs effets de bord. Le connecteur doit donc associer une clé stable aux opérations sensibles quand l'API l'exige ou le supporte.
Cette clé doit venir du métier: créer le payment de telle commande, capturer tel montant, rembourser tel avoir, créer tel paiement récurrent. Elle ne doit pas être un hasard perdu dans un worker.
L'idempotence ne remplace pas la preuve locale. Le SI doit conserver clé, payload, réponse, statut relu, payment ID, refund ID et décision appliquée après la tentative.
Relire avant de rejouer
Un timeout après création de payment, capture ou refund ne prouve pas que Mollie n'a rien fait. Avant de rejouer, le connecteur doit relire l'objet attendu et comparer avec la commande interne.
Cette rellecture évite les doubles gestes. Une commande peut déjà avoir un payment tr_..., un refund peut être
pending, ou une capture peut avoir été demandée sans que l'ERP ait reçu la réponse initiale.
Le runbook doit dire quoi faire: relire, attendre le webhook, rejouer avec la même intention, isoler en quarantaine, demander validation finance ou bloquer temporairement l'action support.
Surveiller les doublons de refund
Mollie peut répondre en erreur quand deux demandes de refund identiques arrivent sur le même payment en très peu de temps. Ce signal doit être traité comme une protection, pas comme un simple échec technique.
Le support doit voir qu'une demande similaire existe déjà, avec son statut actuel. Sinon, quelqu'un relance manuellement, aggrave la confusion et crée un écart comptable que la finance découvre plus tard.
Le coût caché d'un doublon de refund dépasse souvent le montant lui-même. Il ajoute un ticket client, une recherche finance, une correction back-office et une perte de confiance dans le flux de paiement.
6. Recurring, mandates et paiements inattendus
Relier customer, mandate et subscription
Les paiements récurrents Mollie reposent sur des objets comme customer, mandate et subscription. Le connecteur doit les relier au compte interne, au contrat, à la facture, au cycle de facturation et au moyen de paiement autorisé.
Le premier paiement sert souvent à mettre en place la relation. Les paiements suivants peuvent ensuite être créés selon la logique d'abonnement, avec des statuts à relire comme n'importe quel payment.
Les mandats doivent être visibles côté support. Un client qui conteste un renouvellement ou change de moyen de paiement ne doit pas obliger l'équipe à retrouver l'historique dans plusieurs outils.
Le modèle doit aussi conserver profil, customerId, mandateId, subscriptionId, sequenceType, périodicité, prochain prélèvement prévu et dernière facture émise. Ces clés évitent de confondre un renouvellement normal avec une tentative isolée, un impayé ou un changement de contrat.
Gérer le webhook d'un payment inconnu
Mollie précise que, pour les subscriptions, le webhook peut porter un payment ID que votre système ne connaissait pas encore.
Le payment contient alors un subscriptionId qui permet de retrouver l'abonnement.
Cette situation doit être prévue avant le go-live. Un worker qui rejette tout payment inconnu casse les abonnements; un worker qui accepte tout sans corrélation ouvre une porte aux erreurs de facture.
La bonne règle consiste à relire le payment, retrouver le subscriptionId, vérifier le client et le contrat, puis seulement appliquer la décision: facture payée, relance, suspension, échec ou revue support.
Cette règle doit être testée avec des abonnements en échec. Le cas utile n'est pas seulement le renouvellement réussi, mais le paiement inconnu qui arrive en webhook et doit retrouver son contrat sans intervention humaine.
Traiter l'échec récurrent sans panique
Un paiement récurrent peut échouer, expirer, être contesté ou rester pending selon le moyen de paiement. Le connecteur doit distinguer incident isolé, relance automatique, suspension de service et résiliation.
La décision doit être écrite avec le métier. Un SaaS peut tolérer plusieurs jours de relance; une livraison récurrente peut devoir bloquer plus vite; un B2B peut demander une validation finance avant suspension.
Cette grille évite les réactions excessives. Le système ne coupe pas un client fiable pour un échec temporaire, mais il ne laisse pas non plus s'accumuler des prestations non payées.
7. Erreurs fréquentes dans une intégration Mollie
Livrer sur redirectUrl au lieu de paid
La première erreur consiste à valider la commande dès le retour client. Le redirectUrl prouve que le client est
revenu, pas que le payment est paid ni que la commande est correctement corrélée.
Le bon réflexe consiste à afficher une attente puis à laisser le webhook et la rellecture API stabiliser le statut. Cette attente peut être très courte, mais elle protège contre les abandons, expirations et retours tardifs.
Cette erreur est fréquente parce que le premier test semble fonctionner. Elle devient coûteuse quand un moyen plus lent ou un pic de trafic révèle les commandes validées trop tôt.
Prédire les expirations localement
La documentation Mollie indique que les expirations dépendent du moyen de paiement et recommande d'attendre le webhook puis de récupérer le statut. Une estimation locale peut donc créer des annulations prématurées.
Le SI peut afficher un délai indicatif au client, mais il ne doit pas traiter cette estimation comme une source de vérité financière. La vérité de paiement reste le statut relu auprès de Mollie.
Cette règle protège la conversion. Elle évite de fermer trop vite une commande qui pouvait encore aboutir, surtout sur des moyens de paiement dont la confirmation est plus lente.
Rembourser sans suivre la balance
Un refund peut être queued si la balance disponible est insuffisante. Si le support ne voit pas cette nuance, il promet au client un remboursement déjà terminé alors qu'il est seulement en attente.
Le back-office doit afficher le statut du refund, pas seulement la demande. Il doit aussi montrer l'avoir, le montant, le payment ID, le refund ID et la prochaine action possible.
Sans cette preuve, la finance découvre l'écart en clôture. Le client pense être remboursé, le support pense avoir terminé, et l'ERP ne sait pas encore quelle écriture rapprocher.
Ignorer les payments créés par abonnement
Une intégration récurrente fragile échoue souvent sur les payments que le SI ne connaissait pas avant le webhook. Les rejeter comme inconnus casse le cycle d'abonnement.
Les accepter sans vérifier le subscriptionId est tout aussi dangereux. Le connecteur doit relier payment, subscription, customer, mandat, facture et contrat avant de déclencher une action.
La bonne version initiale peut rester limitée: relire, corréler, facturer et exposer au support les cas d'échec. Les automatisations commerciales plus fines peuvent venir après quelques semaines de données réelles.
8. Plan d'action avant go-live Mollie
Cadrer les objets et les décisions
La première étape consiste à lister les objets Mollie réellement connectés: payment, payment ID, checkout link, redirectUrl, webhookUrl, metadata, capture, refund, settlement, customer, mandate, subscription, facture, avoir et écriture ERP.
La deuxième étape consiste à écrire les décisions dépendantes: afficher une attente, confirmer une commande, livrer, annuler, relancer, capturer, rembourser, suspendre un abonnement, créer un avoir ou mettre un dossier en quarantaine.
La troisième étape consiste à figer les états normalisés. Le support n'a pas besoin de tous les détails Mollie dans chaque écran, mais il doit savoir ce qui est open, pending, authorized, paid, expired, failed, canceled, refunded ou à reprendre.
Installer les garde-fous techniques
Les garde-fous couvrent API key, séparation test et live, idempotency key, webhookUrl, queue, backoff, rellecture après webhook, stockage des payment IDs, déduplication, logs corrélés, statut refund et tableau de suivi support.
Les domaines doivent être séparés. Création de payment, retour client, webhook, capture, refund, abonnement, relance client et rapprochement finance n'ont pas les mêmes délais, les mêmes risques ni les mêmes owners.
Le runbook doit expliquer comment bloquer les livraisons sur statut non définitif, isoler un refund incertain, relire un payment inconnu, suspendre un abonnement et reprendre une commande sans créer un second paiement.
Préparer une bascule contrôlée
Le lancement doit commencer sur un périmètre maîtrisé: un canal, une devise, quelques moyens de paiement prioritaires, une famille de refunds et, si nécessaire, un seul flux récurrent clairement documenté.
Cette limitation donne assez de signal sans exposer tout le cash. Elle permet de relire les premiers webhooks réels, mesurer les statuts inconnus et corriger les écrans support avant d'ouvrir plus largement.
Pendant cette période, les équipes doivent relire chaque jour les payments non corrélés, les expirations, les refunds queued et les abonnements en échec. La bascule doit produire des décisions, pas seulement des courbes de succès.
- D'abord, à valider: payment ID stocké, metadata stable, webhook relu, paid corrélé, expired respecté, refund suivi et abonnement relié à son subscriptionId.
- Ensuite, à bloquer: livraison sur redirectUrl seul, refund sans avoir, payment inconnu sans rellecture, expiration prédite localement et doublon de payment sans owner.
- Puis, à corriger: description ambiguë, metadata insuffisante, tableau support sans statut refund, webhooks non dédupliqués et recurring sans règle d'échec.
- Enfin, à différer: nouveaux moyens locaux, routage marketplace, automatisation fine des relances et scénarios d'abonnement dont le support ne sait pas expliquer les exceptions.
Fixer le critère de sortie
Un bon go-live Mollie ne cherche pas à activer tous les moyens de paiement d'un coup. Il cherche à prouver que payment, webhook, statut, capture, refund, recurring et finance restent compréhensibles quand les premiers incidents réels arrivent.
Le critère de sortie doit être concret: aucun flux critique sans owner, aucun statut définitif sans action métier, aucun refund sans preuve d'avoir et aucun écran support qui confond retour client et paiement payé.
La décision de go-live doit donc être binaire sur les flux critiques. Si un payment, un refund ou un paiement récurrent ne peut pas être expliqué avec les preuves disponibles, le périmètre doit rester contrôlé jusqu'à correction.
9. Scénario terrain et recette Mollie
Le client revient, mais la commande reste incertaine
Imaginons une boutique qui active Mollie avec plusieurs moyens européens. Le client revient bien sur le site après checkout, mais une partie des commandes reste en attente car le webhook n'a pas encore stabilisé le statut.
Le support voit des clients qui demandent confirmation. Le Dashboard Mollie montre des payments open, pending, paid ou expired, mais l'ERP n'expose qu'un statut paiement en attente, trop pauvre pour décider.
Le problème ne vient pas forcément de Mollie. Il peut venir d'un retour navigateur traité comme vérité, d'un webhook non dédupliqué, d'une rellecture absente, d'une metadata trop faible ou d'un mapping qui confond pending, paid et expired.
La correction commence par la chronologie
La première correction consiste à reconstruire la ligne de temps: payment créé, checkout link utilisé, retour client, webhook reçu, payment relu, statut normalisé, écriture ERP, email client et décision support.
La deuxième correction consiste à isoler les commandes incertaines. Une commande revenue du checkout mais non paid ne doit pas être livrée automatiquement; elle doit afficher une attente contrôlée.
La troisième correction consiste à rendre la preuve visible. Le support doit voir payment ID, statut Mollie, metadata, dernier webhook, statut interne, action autorisée et action interdite.
Tester les cas qui coûtent vraiment
La recette doit couvrir payment open, pending, paid, expired, failed, canceled, authorized, capture manuelle, refund total, refund partiel, refund queued, webhook rejoué, webhook tardif et payment récurrent inconnu.
Chaque scénario doit préciser l'état attendu dans le checkout, l'ERP, l'OMS, le support et la finance. Le test est réussi quand ces systèmes racontent la même décision, même si le statut brut vient de Mollie.
Les preuves attendues doivent être conservées pendant la recette: payload, payment ID, metadata, statut relu, refund ID, subscriptionId, statut normalisé, écriture métier, owner de reprise et action interdite.
Fixer des seuils actionnables
Les seuils doivent décider le mode de run. Par exemple, si pendant 2 jours des payments paid restent sans commande corrélée, alors l'élargissement doit être bloqué, car le client, la logistique et la finance sont déjà exposés.
Si plus de 2 % des refunds d'un canal prioritaire restent queued ou incompris par le support, alors la priorité n'est pas d'ajouter de nouveaux moyens de paiement. La priorité est de fiabiliser balance, avoir, statut refund et preuve comptable.
Les 30 premiers jours doivent être relus avec support et finance. Si les mêmes questions reviennent sur expired, paid, refund, recurring ou rapprochement, il faut enrichir la preuve visible avant d'ouvrir Mollie à plus de volume.
Après cette période, l'élargissement devient une décision mesurée. Les nouveaux moyens locaux ou scénarios recurring ne doivent être ouverts que si les seuils restent stables et si les reprises ne dépendent plus d'une seule personne.
Mesurer les preuves de sortie
Cas concret: si pendant 7 jours plus de 2 % des payments paid restent sans commande interne corrélée, alors le seuil de sortie n'est pas atteint. La priorité doit rester sur le mapping et la preuve support, car le risque touche conversion, livraison, marge et confiance client.
Exemple concret: si plus de 5 refunds par semaine restent queued, failed ou incompris par le support, alors l'ouverture de nouveaux moyens de paiement doit être différée. Le seuil montre que la balance, l'avoir, le refund ID ou le rapprochement finance ne sont pas encore assez lisibles.
Le troisième seuil porte sur le délai d'explication. Si une personne support met plus de 15 minutes à retrouver payment ID, statut Mollie, dernière rellecture et action autorisée, alors l'intégration manque encore de preuves visibles, même si les appels API répondent correctement.
Questions fréquentes sur Mollie
Pourquoi faut-il relire le payment Mollie après un webhook ? Le webhook sert à signaler qu'un statut a changé. Le connecteur doit ensuite récupérer le paiement via l'API Mollie, vérifier son statut, son montant, sa devise, ses métadonnées et appliquer la décision métier.
Comment gérer les statuts open, pending, paid et expired ? Open et pending doivent rester des états d'attente, paid peut déclencher la suite métier après corrélation, tandis que expired, failed ou canceled doivent fermer ou relancer le parcours selon la règle commerciale.
Dawap peut-il accompagner une intégration Mollie API ? Oui. Dawap accompagne le cadrage Mollie, Payments API, captures, refunds, recurring payments, webhooks, mappings ERP/e-commerce, rapprochements finance, reprises, recette et observabilité de production.
Guides complémentaires pour Mollie
Une intégration Mollie touche rarement le checkout seulement. Les ressources suivantes aident à approfondir la chaîne paiement, la maîtrise des doublons, la réception d'événements et le rapprochement entre systèmes.
Architecture paiement de bout en bout
La lecture paiement API replace Mollie dans une chaîne complète: payment, redirect, statut, capture, refund, settlement, récurrence, écriture finance et preuve opérationnelle entre les systèmes métier.
Elle aide à décider ce qui appartient au checkout, au PSP, au middleware, à l'ERP ou à la comptabilité. Cette frontière évite les corrections tardives quand un retour client ne correspond pas encore à un payment paid.
Elle donne aussi une grille pour relire les exceptions: expiration, paiement pending, refund queued, payment récurrent inconnu ou écart entre montant payé et montant rapproché.
Protection contre les doubles traitements
La ressource idempotence API et doublons métier donne le cadre nécessaire pour éviter les payments recréés, les captures répétées, les refunds en double et les webhooks rejoués sans contrôle.
Elle devient prioritaire dès qu'un timeout peut masquer une opération réussie, qu'un opérateur peut relancer une commande ou qu'un webhook Mollie peut revenir après une correction support. Le coût d'un doublon financier dépasse souvent celui d'une validation stricte.
Elle donne enfin une méthode pour relier clé métier, journalisation, queue, retry, rollback et preuve support. Cette méthode s'applique directement aux flux Mollie les plus sensibles.
Webhooks et lectures contrôlées
La ressource webhook ou polling API permet de choisir une stratégie fiable pour les événements Mollie, les relances, les lectures contrôlées et les reprises.
Elle aide à décider quand accepter un webhook, quand le rejouer, quand le mettre en quarantaine et quand compléter par une rellecture du payment. Cette décision devient centrale quand les statuts dépendent du moyen de paiement.
Elle évite aussi de confondre temps réel et vérité métier. Un événement rapide peut être faux pour le SI si la chronologie, la clé de corrélation et l'état courant ne sont pas vérifiés avant écriture.
Réconciliation entre Mollie et l'ERP
La ressource réconciliation API prolonge les questions d'écart entre Mollie, e-commerce, ERP et comptabilité, surtout lorsque refunds, settlements, moyens lents et abonnements entrent dans le périmètre.
Elle devient utile quand le volume empêche de traiter les écarts à la main. La méthode consiste à rapprocher identifiants, montants, dates, statuts, devises et décisions avant d'ouvrir un incident.
Cette lecture convient aux équipes qui veulent passer de la correction manuelle au pilotage. L'écart n'est plus seulement une anomalie; il devient un objet de run avec cause, owner, seuil et prochaine action.
Runbook quand Mollie bloque un paiement
La ressource runbook d'incident API complète ce parcours quand un paiement Mollie reste pending, qu'un refund reste queued, qu'un moyen lent retarde la commande ou qu'un webhook signale un changement que l'ERP ne sait pas encore appliquer.
Elle aide à fixer les seuils d'action: combien de payments en attente justifient un gel, quand relire l'API Mollie, quand isoler un lot et quand escalader côté support ou finance. Le run reste ainsi borné au flux concerné au lieu de devenir une correction manuelle générale.
Conclusion: intégrer Mollie sans dette support
Une intégration API Mollie réussie ne se mesure pas au premier checkout ouvert. Elle se mesure à la capacité d'expliquer un payment, un statut, un webhook, un refund, un abonnement ou un écart finance sans reconstruire toute la chaîne.
Le bon ordre reste stable: créer le payment avec une référence fiable, relire après webhook, mapper les statuts, protéger les retries, encadrer les refunds, traiter les abonnements et donner au support une preuve lisible.
Cette discipline ne ralentit pas le projet. Elle évite que Mollie devienne une boîte noire paiement, réduit les doubles gestes, protège la marge et rend l'ouverture vers de nouveaux moyens européens beaucoup plus maîtrisable.
Si vous devez connecter Mollie à un ERP, un OMS, une marketplace, un SaaS ou une boutique avec une preuve de run solide, notre accompagnement en intégration API peut cadrer l'architecture, les mappings, les reprises et l'observabilité sans déplacer la dette vers le support ou la finance.
