Intégration d'une API de paiement en ligne
L'encaissement ouvre le service, pas un ticket interne
Notre équipe câble votre prestataire de paiement dans le produit : droits, abonnement, reversements, litiges. Le checkout n'est que le début du flux.
- Connecteurs de paiement en production
- modèle de flux cadré
- webhooks idempotents
Qu'est-ce qu'une API de paiement en ligne et quand la faire intégrer ?
Une API de paiement en ligne permet à votre application de déclencher un encaissement, de suivre son issue et de réagir à ce qui se passe ensuite : un impayé, un remboursement, un litige. Les modules prêts à l'emploi couvrent la vente simple. On fait développer une intégration sur mesure quand l'argent circule entre plusieurs parties, quand la facturation suit un cycle avec essais, paliers et prorata, ou quand l'encaissement doit ouvrir des droits dans votre produit et retomber juste en comptabilité.
Les solutions de paiement que nous intégrons
Stripe
Le plus complet. Encaissement, abonnements, places de marché et reversements.
PayPal
Un moyen de paiement que vos acheteurs connaissent déjà, souvent en complément.
SumUp
L'encaissement en présence du client, quand la vente se conclut sur le terrain.
GoCardless
Le prélèvement SEPA récurrent, pour les abonnements et les échéanciers.
Mollie
L'option européenne, avec les moyens de paiement locaux de vos marchés.
Ce que le prestataire de paiement ne fait pas tout seul
Le module d'encaissement encaisse. Le reste (droits, reversements, livres) reste à construire dans votre application.
Je ne sais pas qui a payé quoi
Nous rattachons chaque encaissement à sa facture et à son client dans votre outil, avec une référence portée de bout en bout plutôt qu'un rapprochement au jugé.
Un client paie et n'a toujours pas ses accès
L'événement de paiement ouvre les droits dans la foulée, et l'impayé les restreint. Plus d'intervention manuelle entre le règlement et le service rendu.
Mes reversements aux vendeurs sont un casse-tête
Nous câblons la répartition et la commission au moment du flux, avec les cas de bord traités : commande annulée, remboursement partiel, solde vendeur insuffisant.
Ma comptabilité ne retombe jamais juste
Encaissements, commissions, remboursements et frais sont poussés avec le bon découpage vers votre comptabilité, et un contrôle périodique signale tout écart.
Ce que chaque solution implique concrètement
GoCardless
Prélèvement SEPALe prélèvement SEPA, adapté aux abonnements B2B et aux échéanciers où la commission carte devient difficile à justifier. Le sujet d'intégration est le cycle de vie du mandat et le traitement des rejets, pas la transaction : un prélèvement rejeté doit déclencher une action, pas un silence.
- Mandats et échéanciers pilotés
- Coût adapté aux montants élevés
- Rejets traités comme un cas nominal
Mollie
Option européenneL'option européenne, utile quand vos marchés attendent leurs moyens de paiement locaux et qu'un catalogue international ne suffit pas. L'intégration se juge sur la couverture réelle des méthodes dont vous avez besoin, marché par marché, plutôt que sur la longueur du catalogue annoncé.
- Moyens de paiement locaux
- Couverture à vérifier marché par marché
- Alternative crédible sur l'Europe
PayPal
Réflexe acheteurUn moyen de paiement que vos acheteurs reconnaissent, ce qui pèse sur le taux de conversion en vente aux particuliers. Il s'ajoute le plus souvent à un prestataire principal plutôt qu'il ne le remplace, et l'intégration se conçoit alors comme un second flux à réconcilier, pas comme un second système.
- Réflexe d'achat côté acheteur
- Vient en complément d'un prestataire principal
- Flux à réconcilier avec le reste
Stripe
Le plus completLa plateforme la plus complète, et celle qui va le plus loin quand l'argent circule entre plusieurs parties ou quand la facturation suit un cycle. En contrepartie, les décisions structurantes se prennent tôt : qui porte les litiges, qui paie les frais, quel modèle de flux. Elles se changent ensuite au prix d'une reprise complète.
- Places de marché et commission au flux
- Abonnements, essais et prorata gérés
- Horloges de simulation pour tester le futur
SumUp
Vente en présentielL'encaissement en présence du client, sur un terminal, quand la vente se conclut en boutique, en tournée ou sur un chantier. L'enjeu d'intégration n'est pas le paiement lui-même mais son retour dans votre logiciel métier, pour que la vente terrain existe au même titre que la vente en ligne.
- Encaissement en face à face
- Vente terrain remontée dans l'outil
- Même traitement que la vente en ligne
Quatre architectures de flux que nous câblons
État de facture, état du produit
Essai, palier, prorata et impayé deviennent des états métier. Les fonctionnalités s'ouvrent et se ferment sans un tableau de bord tenu à la main.
Place de marché à la capture
Commission et parts vendeurs se calculent au moment du flux, y compris remboursement partiel et solde insuffisant, pas en refacturation de fin de mois.
Couche interne multi-prestataires
Stripe, un complément carte, un prélèvement : un seul modèle de paiement côté produit. Ajouter un moyen ne duplique pas la facturation.
Séquence d'impayé dans l'application
Échec, relance, restriction : la dunning vit dans le produit. Le recouvrement devient une file mesurable, pas une boîte mail.
Qui gagne, et ce que nous tranchons avec vous
Nous ne choisissons pas un prestataire dans l'absolu. Nous cadrons le modèle de flux avec le produit, la finance et les ops.
Le produit traite l'accès comme un état
Produit et CS arrêtent de débloquer les comptes à la main. Nous posons l'événement de paiement comme source de l'entitlement.
La finance lit trois montants, pas un net
Encaissé, reversé, prélevé : le DAF et le comptable voient le découpage. Nous le poussons tel quel vers la comptabilité.
Les ops marketplace cessent d'arbitrer à la main
Annulation, litige, solde vendeur : les cas de bord sont des règles, pas des tickets. Nous les écrivons au cadrage avec vous.
Le recouvrement n'est plus une chasse dans la boîte
Chaque échec a un âge, un responsable, une prochaine action. Nous branchons cette file sur le prestataire, pas l'inverse.
Des encaissements Stripe qui tournent en production
Ce qu'un flux de paiement force comme méthode
Modèle de flux
Vente, abonnement ou place de marché. Commerçant, litiges, frais : tranché avant le code.
Livrable : carte du modèle de fluxIdempotence et 3DS
Idempotence, secrets isolés, parcours 3DS dessiné dans le tunnel.
Livrable : contrat d'idempotenceWebhooks rejoués
Signature, file, rejeu désordonné. Refus, remboursement, litige avant bascule.
Livrable : suite de webhooks rejouableExploitation des litiges
Litige, représentation, écriture inverse : le flux vit après la capture.
Livrable : runbook des litigesCe que personne ne vous dit avant de signer
Un webhook mal traité coûte de l'argent
Chez la plupart des prestataires, l'issue d'un paiement arrive par événement. Si votre serveur ne répond pas correctement, vous ne perdez pas un message : vous perdez la trace d'un encaissement, et parfois vous retardez toute une facturation.
Les événements arrivent en désordre et en double
Aucun prestataire sérieux ne garantit un ordre de livraison. Une logique qui suppose une séquence est fausse par construction : il faut dédupliquer, et relire l'objet concerné quand un événement arrive en avance.
L'authentification forte casse les parcours trop optimistes
Une part des paiements réclame une validation supplémentaire du porteur. Ce n'est pas une erreur à rattraper, c'est une étape à dessiner dans le parcours, sous peine d'un taux d'échec inexpliqué à la mise en ligne.
Changer de modèle de flux coûte une reprise complète
Qui apparaît comme le commerçant, qui porte les litiges, qui paie les frais : ces choix structurent le code et la comptabilité. Ils se tranchent au cadrage, avec votre direction financière, pas six mois plus tard.
Ce que nous mesurons sur un projet de paiement
Intégration d'une API de paiement : vos questions
Trois étapes. D'abord choisir le modèle de flux : vente simple, abonnement, ou circulation d'argent entre plusieurs parties. Ensuite construire le connecteur côté serveur, avec une clé d'idempotence sur chaque création pour qu'un rejeu ne produise jamais un second paiement, et les secrets isolés hors du code applicatif. Enfin traiter les événements correctement : vérifier la signature, répondre immédiatement, faire le travail dans une file, dédupliquer. La partie sensible n'est jamais l'appel de paiement, c'est ce qui se passe après : impayé, remboursement, litige, et le retour de tout cela en comptabilité.
Cela dépend du modèle de flux bien plus que du prestataire choisi. Un encaissement simple avec confirmation par email se chiffre bien plus bas qu'un abonnement avec paliers et prorata, et bien plus bas encore qu'une place de marché où l'argent se répartit entre plusieurs vendeurs. Le coût réel se cache dans les cas de bord : commande annulée après reversement, remboursement partiel, litige ouvert deux mois plus tard, écart entre le prestataire et la comptabilité. Nous cadrons le périmètre en amont et donnons une estimation ferme.
Cela se décide sur trois critères, dans cet ordre. Le modèle économique d'abord : vente simple, abonnement, ou reversement à des tiers, ce dernier cas réduisant nettement le nombre d'options crédibles. Les moyens de paiement attendus par vos clients ensuite, qui dépendent de vos marchés et du profil des acheteurs, particuliers ou entreprises. Le coût enfin, en regardant le montant moyen et la récurrence plutôt que le pourcentage affiché : sur des factures B2B élevées, le prélèvement bat la carte. Dites-nous votre modèle, nous vous dirons ce que ça implique.
Oui, et c'est fréquent : un prestataire principal, un moyen de paiement complémentaire pour la conversion, parfois un prélèvement pour les abonnements. La difficulté n'est pas de les brancher, c'est de garder une seule vérité côté produit. Nous posons un modèle interne de paiement indépendant du prestataire, où chaque flux entrant est normalisé avant d'atteindre votre logique métier. Sans cette couche, chaque ajout de moyen de paiement duplique la logique de facturation et de comptabilisation, et les écarts commencent.
En poussant les flux avec le bon découpage plutôt qu'un montant net. Un encaissement, la commission du prestataire, un éventuel reversement à un tiers et un remboursement sont quatre écritures différentes, et les agréger fait perdre l'information au moment où le comptable en a besoin. Nous construisons le flux vers votre outil comptable, puis un contrôle de cohérence périodique entre ce que le prestataire expose et ce que la comptabilité enregistre, avec alerte sur écart plutôt que correction silencieuse. Une écriture ne se répare pas dans le dos du comptable.
Quel est votre modèle de flux ?
Vente simple, abonnement ou place de marché : 30 minutes pour le poser, et vous dire ce que ça impose côté prestataire, 3DS et comptabilité.
Parler de mon projet de paiement