Intégration API Mollie
Nous développons votre connecteur Mollie
Nous câblons l'API Mollie à votre tunnel de vente pour encaisser en Cartes Bancaires, gérer mandats et abonnements, et rapprocher les versements.
- Équipe produit senior
- intégrations de paiement en production
- du cadrage au monitoring
À quoi sert l'API Mollie et pourquoi l'intégrer comme solution de paiement ?
Mollie est un PSP européen qui regroupe dans une seule intégration les principaux moyens de paiement : carte bancaire, virement instantané, prélèvement SEPA, PayPal, et les méthodes locales comme Bancontact ou iDEAL. Son API permet à votre application de créer un lien de paiement, de gérer des abonnements et des mandats, et de suivre les règlements et remboursements. On l'intègre pour proposer à chaque client le moyen de paiement qu'il préfère sans multiplier les contrats, et pour que les événements de paiement déclenchent automatiquement les actions dans votre logiciel.
Ce que nos clients construisent sur l'API Mollie
Tunnel français avec Cartes Bancaires
La Methods API choisit CB, Visa, Mastercard, PayPal selon le pays. L'absence du logo CB se lit dans le taux de conversion.
Abonnement avec mandat au premier paiement
sequenceType first, puis recurring sans session navigateur. La relance part avant la 5e tentative Mollie, pas après l'annulation.
Lien de paiement pour un acompte
Payment Link envoyé par e-mail, clôture du dossier sur payment-link.paid. Pas de tunnel à construire pour une facture ponctuelle.
Rapprochement par versement bancaire
Settlements explique l'écart entre encaissements et virement reçu. Balances donne la vue au fil de l'eau. Les deux questions, deux API.
Ce que ça change dans votre tunnel
La technique au service d'un résultat mesurable : CB au bon moment, des mandats vivants, un rapprochement lisible.
Le bon logo au bon moment
Cartes Bancaires est un moyen de première classe chez Mollie. Le tunnel français n'affiche plus seulement Visa et Mastercard.
Vous savez si le client est débitable
Un mandat a un statut. On le contrôle avant de facturer, au lieu de découvrir l'absence de mandat par un échec.
L'impayé a une séquence
Mollie retente jusqu'à 5 fois, puis annule. Nous prévenons avant la 5e, et nous traitons la révocation du mandat si l'abonnement le porte en dur.
Le virement reçu s'explique
Settlements détaille frais et encaissements du versement. Votre comptable arrête de reconstituer l'écart à partir d'un export.
Comment nous livrons votre connecteur Mollie
Cadrage
Moyens, récurrent, classiques et next-gen, Connect ou non. On tranche les deux systèmes de webhooks avant d'écrire une ligne.
Développement
Connecteur typé, montants en chaînes, handler sous 15 secondes, une seule URL de webhook (plafond de 3 souscriptions).
Recette
Paiement, 3DS, échec d'abonnement, redirection 301 sur l'URL de webhook, rotation de secret à deux en-têtes.
Monitoring
Alerte sur passage en blocked, journal des paiements, tableau de bord de santé. Un webhook bloqué coupe tout jusqu'à réactivation manuelle.
Ce que permet l'API Mollie
- Paiements et moyens
- Payments API plus Methods API. Cartes Bancaires, cartes internationales, PayPal, iDEAL, Bancontact, prélèvement, selon le profil et le pays.
- Clients, mandats, récurrence
- Premier paiement sequenceType first, suivants recurring avec mandateId. iDEAL et Bancontact créent un mandat directdebit, à activer sur le profil.
- Abonnements
- Montant, intervalle, occurrences. Si le jour n'existe pas dans le mois, Mollie prélève le dernier jour. Pas de webhook d'état d'abonnement : on rattache par subscriptionId.
- Soldes et règlements
- Balances pour la vue au fil de l'eau, Settlements pour le virement reçu. Deux comptabilités, explicitement nommées par Mollie.
Le vocabulaire de l'API Mollie
- sequenceType
- first crée le mandat, recurring prélève sans navigateur. iDEAL, Bancontact, eps, kbc, belfius et paybybank donnent un mandat directdebit.
- X-Mollie-Signature
- HMAC-SHA256 du corps POST non altéré, préfixé sha256=, sur la nouvelle génération. Pendant 24 heures après rotation, deux en-têtes coexistent.
- Montant chaîne
- {"currency" : "EUR", "value" : "24.95"}. Un client TypeScript typé en number produit des erreurs de validation ou des arrondis silencieux.
- blocked
- Après des échecs répétés sur 24 heures, le webhook next-gen s'arrête. Réactivation manuelle. Sans alerte, on le découvre par un client mécontent.
- mandateId fixe
- Si l'abonnement porte un mandateId, son annulation révoque aussi le mandat. C'est un événement métier majeur, pas un détail d'API.
- RateLimit-Policy
- Présent sur toutes les réponses. Lectures et écritures dans des seaux séparés. Toutes les clés d'un marchand partagent le même seau : l'export peut affamer le tunnel.
Les contraintes réelles de l'API Mollie
Deux systèmes de webhooks à tenir
Mollie recommande les classiques pour les paiements (les payment.* next-gen sont en bêta sur demande) et la nouvelle génération pour le reste. Une intégration qui ne branche que le next-gen manquera des paiements.
Quinze secondes, pas seize
Un 200 renvoyé après 16 secondes est compté en échec, et le traitement a eu lieu. 10 tentatives sur 26 heures, aucun renvoi manuel : il faut passer par le support.
3 souscriptions, puis blocked
Jusqu'à 3 souscriptions actives par organisation en production. Une URL unique, dispatch interne. Après 24 heures d'échecs, l'état blocked coupe tout jusqu'à réactivation manuelle.
L'échec d'abonnement annule
Jusqu'à 5 tentatives, une par jour, puis annulation. AC01, AC04, AC06, MD07 annulent tout de suite. Un mandateId fixe révoque aussi le mandat. On prévient avant la 5e.
Webhooks classiques ou nouvelle génération ?
Deux systèmes coexistent. Mollie recommande de les tenir tous les deux, pour des raisons précises.
| Critère | ClassiquesPaiements | Nouvelle générationHors paiement |
|---|---|---|
| Charge utile | id=tr_... en formulaire | JSON, simple ou complète |
| Signature | Aucune : relecture API | X-Mollie-Signature HMAC |
| Événements paiement | Le chemin recommandé aujourd'hui | payment.* en bêta sur demande |
| Factures, versements, soldes | Hors sujet | Le chemin recommandé |
| Plafond d'abonnements | Un webhook par paiement (usage unique) | 3 souscriptions actives par organisation |
| Panne prolongée | 10 tentatives sur 26 heures | blocked après 24 heures, réactivation manuelle |
| Le bon cas | Mises à jour de paiement | Comptabilité événementielle, hors paiement |
Nous branchons les deux. Une architecture qui n'en choisit qu'un manque soit des paiements, soit les événements comptables durables.
Ce que nous mesurons sur une intégration Mollie
Les autres API de paiement
Si Mollie n'est pas le bon choix pour votre modèle, ces options se discutent au cadrage.
MollieNous développons votre connecteur MollieCette page
StripeConnect et Billing les plus complets, quand la plateforme et le prorata sont le cœur du produit.
PayPalUn compte que l'acheteur possède déjà, souvent en complément de CB.
SumUpL'encaissement en présence, quand la vente se conclut sur un terminal.
GoCardlessNous développons votre connecteur GoCardlessOn combine Mollie avec
La stack qui entoure Mollie sur nos projets.
Intégration Mollie : vos questions
Trois étapes. D'abord une clé d'API (paire test et production) et la Methods API pour afficher Cartes Bancaires au bon moment. Ensuite POST /v2/payments avec des montants en chaînes, et pour le récurrent un customer plus un premier paiement sequenceType first. Enfin le webhook classique : lire l'id, enfiler, répondre 200 en moins de 15 secondes, relire GET /v2/payments/{id}. La nouvelle génération se branche en plus pour les événements hors paiement. La partie sensible n'est pas l'appel, c'est le plafond de 3 souscriptions, l'état blocked, et le fait qu'un 200 trop lent compte comme un échec alors que le traitement a eu lieu.
Cela dépend des moyens et du récurrent. Un tunnel CB plus carte est plus court qu'un abonnement avec mandats, relance avant 5 tentatives, Settlements et Mollie Connect. Un premier flux utile se livre en deux à trois semaines. Une chaîne complète demande plutôt six à huit semaines. Nous ne citons pas de tarif éditeur : les grilles publiques consultées visent d'autres pays. Nous cadrons le périmètre et donnons une estimation ferme avant de commencer.
Le classique envoie id=tr_... en formulaire, sans signature : la protection est la relecture API authentifiée. Mollie le recommande encore pour les mises à jour de paiement. La nouvelle génération s'abonne à des types durables, signe en X-Mollie-Signature, et couvre factures, versements, transferts. Les événements payment.* y sont en bêta sur demande. Il faut les deux. Une URL unique côté next-gen, à cause du plafond de 3 souscriptions. Une redirection 301 ou 302 sur l'URL transforme le POST en GET et perd le corps : il faut 307 ou 308, ou mieux aucune redirection.
Mollie retente jusqu'à 5 fois, une fois par jour, puis annule l'abonnement. Certains codes SEPA annulent tout de suite (AC01 IBAN invalide, AC04 compte clos, AC06 bloqué, MD07 décédé). D'autres après 3 occurrences (MD01, MD06, MS02, MS03, SL01). Si l'abonnement porte un mandateId fixe, l'annulation révoque aussi le mandat. Il n'existe pas de webhook d'état d'abonnement : les paiements arrivent avec un id inconnu, rattachés par subscriptionId. Nous prévenons l'utilisateur avant la 5e tentative, et nous traitons la révocation du mandat comme un événement métier, pas comme un détail.
Oui. Nous poussons les encaissements avec la référence de commande, et nous adossons le rapprochement aux deux API prévues pour cela : Balances pour la vue au fil de l'eau, Settlements pour le virement bancaire. Un contrôle périodique signale l'écart, sans correction silencieuse. payout.completed côté next-gen peut déclencher la clôture du lot. Une écriture ne se répare pas dans le dos du comptable.
Un projet d'intégration Mollie ?
Parlons-en. 30 minutes pour cadrer CB, mandats et webhooks, vérifier ce que l'API permet vraiment et vous dire franchement ce qui est faisable.
Parler de mon projet Mollie