Le webhook arrive deux fois
Répondre rapidement, dédupliquer localement et relire le checkout par l’API avant tout nouvel effet métier.
API
Intégrateur SumUp API : réconcilier checkout, transaction et remboursement
Dawap relie chaque intention de paiement SumUp à la commande qui l’a créée, à la transaction qui fait foi, au remboursement éventuel et à l’état attendu dans l’ERP, le CRM ou le portail. Le middleware conserve les identifiants, relit les notifications par l’API et bloque les clôtures que la chaîne de preuve ne permet pas encore de défendre.
APIs, données et infrastructures que nos projets savent connecter
Du besoin métier au run mesurable
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
actionnable
Réponse immédiate
Un intégrateur SumUp API relie le paiement au dossier métier et garde chaque compensation vérifiable.
Dawap construit la couche entre les checkouts SumUp et vos commandes, factures, CRM ou ERP. L’intégration conserve checkout_reference, checkout ID et transaction ID, traite la notification comme un signal à relire, rapproche les remboursements et ne ferme un dossier que lorsque l’effet métier correspond au résultat SumUp.
- Créer le checkout avec une référence métier stable, un montant, une devise et le bon marchand.
- Recevoir la notification, répondre vite, dédupliquer puis vérifier l’état courant par l’API SumUp.
- Utiliser la transaction comme résultat de paiement et conserver ses événements financiers associés.
- Rapprocher refund, avoir, commande et solde net avant clôture ou replay.
Registre checkout → transaction · scénario illustratif
Un paiement accepté n’est utile que si la commande, le remboursement et le solde racontent la même histoire.
La société, les montants et les identifiants ci-dessous sont fictifs. Ce dossier montre la preuve attendue lorsqu’un checkout SumUp réussit, qu’un remboursement partiel intervient, mais que l’ERP n’a pas encore reçu l’avoir.
Décision de rapprochement
NE PAS CLÔTURER
1 écart ouvert
-
01IntentionCommande et checkout corrélésAccepté
-
02NotificationWebhook reçu puis relu par l’APIVérifié
-
03RésultatTransaction autoritative retrouvéeAccepté
-
04CompensationRefund de 29,90 € rapprochéAccepté
-
05ComptabilitéAvoir et écriture encore absentsBloqué
Prochaine action
Créer l’avoir une seule fois, puis comparer le net de 100,00 €.
order ≠ closed
Le support ne possède que le code transaction
Retrouver la chaîne transaction–checkout_reference–commande ; ne jamais rattacher sur le seul montant.
Le refund existe sans avoir ERP
Bloquer la clôture, conserver le motif et produire une compensation idempotente plutôt qu’un resync général.
Ce que SumUp documente — et ce que votre SI doit décider
Checkout, transaction et remboursement sont trois objets à relier, pas un seul statut à recopier.
SumUp documente le checkout comme intention de paiement, la transaction comme résultat autoritatif et le remboursement comme opération financière liée. Le webhook signale un changement, mais la documentation demande de vérifier l’événement par l’API : la notification ne devient donc jamais seule la vérité métier.
Premier lot recommandé
Une commande, un checkout, un refund partiel et une clôture témoin.
La recette exerce le succès, le doublon de notification, le statut relu, le remboursement partiel et l’écriture manquante avant d’ouvrir un autre canal ou un autre parcours.
Quand le paiement passe mais que le dossier reste faux
La panne SumUp commence souvent après le checkout, au moment où chaque outil interprète le succès différemment.
Un checkout terminé, un webhook reçu ou une ligne visible dans le dashboard ne suffisent pas à solder une commande. Le connecteur doit retrouver la transaction autoritative, appliquer les compensations et prouver le même net au support comme à la finance.
01
Identité
Le montant ne rapproche jamais seul une commande
La commande, checkout_reference, checkout, transaction et écriture locale conservent chacun leur identifiant. Une relation manquante ouvre un écart, pas une correspondance approximative.
02
Événement
Le webhook déclenche une vérification, pas une vérité définitive
La notification est acquittée rapidement puis le checkout ou la transaction est relu par l’API SumUp avant de modifier la commande, l’avoir ou le dossier client.
03
Finance
Un remboursement n’est clos qu’une fois son effet métier rapproché
Refund SumUp, avoir, écriture ERP et solde net sont comparés. La transaction peut être remboursée alors que la clôture interne reste légitimement bloquée.
Contrats d’une intégration SumUp exploitable
Six contrats empêchent un paiement réussi de devenir un dossier impossible à solder.
SumUp expose des objets de paiement. Votre système doit encore décider comment ils se corrèlent, quelle lecture fait foi et à quel moment une commande peut réellement changer d’état.
La clé reste côté serveur et limitée au bon usage
Environnement, marchand, secret, scopes et consommateurs sont inventoriés. Aucun secret SumUp n’est exposé dans le navigateur, les logs ou les outils de support.
L’intention de paiement part d’une référence métier stable
checkout_reference, montant, devise, marchand, description et retour sont décidés depuis la commande. Une nouvelle tentative ne réutilise pas silencieusement une ancienne identité.
Le signal reçu ouvre une relecture ciblée
Le endpoint répond rapidement, trace l’ID, déduplique et demande la ressource courante à SumUp avant toute transition irréversible dans le SI.
Le résultat financier reste distinct du checkout
Transaction ID, code, statut, montant, devise, moyen et événements sont conservés. Le support retrouve le paiement sans chercher par montant ou par date approximative.
La compensation garde son motif et son effet local
Un remboursement complet ou partiel est rattaché à la transaction, à la commande, au motif, à l’avoir et au solde restant.
Le dossier ne ferme que lorsque les deux soldes convergent
Somme encaissée, événements de remboursement, avoirs et écritures sont comparés. Chaque écart mène à une action bornée, jamais à un replay général par réflexe.
Méthode Dawap
Prouver le net d’une commande avant d’industrialiser le volume.
Nous partons du dossier qui coûte déjà du temps au support ou à la clôture. La chaîne d’identifiants et les transitions sont stabilisées, puis chaque notification, lecture et compensation est exercée avant d’ajouter un second parcours.
Décision 1
Une commande témoin, pas tout l’historique.
Décision 2
Une chaîne d’identifiants, jamais un rapprochement au montant.
Décision 3
Une notification vérifiée, pas un statut recopié.
Décision 4
Une compensation prouvée, pas une clôture supposée.
Premier lot SumUp
Prouver une commande, un checkout et un remboursement partiel de bout en bout.
On choisit le parcours où le support ou la finance ouvre aujourd’hui plusieurs outils pour comprendre le solde. Le lot est accepté quand le dossier local et SumUp convergent, y compris après une notification doublée ou une compensation incomplète.
1 commande
1 checkout
1 transaction
1 refund partiel
5 contre-tests
Sorties attendues
Carte portail–middleware–SumUp–ERP–support avec owner de chaque état et de chaque compensation.
Modèle pivot reliant commande, checkout_reference, checkout, transaction, refund, facture, avoir et écriture.
Contrat de notification : accusé rapide, déduplication, relecture API, ordre local et reprise bornée.
Cinq contre-tests : webhook doublé, checkout absent, transaction retardée, refund partiel et avoir manquant.
Journal expurgé avec requête, réponse, ressource relue, effet métier, décision et prochaine action.
Recette commerce–support–finance, alerte sur écart, export de balance et runbook de compensation.
Trois scénarios de preuve
La recette porte sur les écarts qui changent réellement le solde ou le service rendu.
Les commandes, marchands, montants et identifiants ci-dessous sont illustratifs. La recette finale utilise vos comptes, droits, parcours et règles comptables validés.
Le retour client ne libère rien avant la transaction relue
Un scénario concret à cadrer et vérifier.
- Décision
- Afficher un état de confirmation borné puis libérer uniquement après résultat vérifié.
Deux notifications ne produisent qu’un effet métier
Un scénario concret à cadrer et vérifier.
- Décision
- Acquitter, classer en doublon et ne pas recréer facture, email ou commande.
Le remboursement partiel bloque la clôture tant que l’avoir manque
Un scénario concret à cadrer et vérifier.
- Décision
- Créer une compensation unique puis comparer de nouveau les deux soldes.
Frontières éditoriales
Choisir la page capable de répondre précisément au besoin.
Service SumUp, guide générique, architecture multi-PSP et comptabilité se renforcent sans se remplacer.
Avis & exigence projet
Une intégration SumUp jugée sur le même solde dans tous les outils.
5/5★★★★★Avis clients Dawap
“
Référence, montant, devise, marchand, parcours et droits sont explicitement choisis.
“
Checkout et transaction sont relus avant chaque effet irréversible dans le SI.
“
Refund, avoir, écriture et net métier convergent avant clôture.
Pour Art’Sacs, activité reprise depuis par France Appro, Dawap a relié Aster et PrestaShop afin de transformer le catalogue fournisseur, synchroniser les quantités, enrichir les fiches et préparer les commandes dropshipping. Les tâches, états et erreurs donnent aux équipes un flux pilotable plutôt qu’une synchronisation opaque.
Ciama sélectionne quatre lecteurs spécialisés pour collecter commandes et variantes Shopify ou Wix, puis les normalise dans deux modèles communs. Le pipeline protège le compte et le canal, décide entre ajout et mise à jour, distribue les écritures et sécurise la désactivation après un snapshot complet.
Le paiement via API ne se résume pas à encaisser. Il faut cadrer PaymentIntents, captures, refunds, webhooks, idempotence, wallets, KYC et réconciliation sans transformer le support en table de reprise manuelle. Ce cadrage protège marge, trésorerie et taux d’acceptation avec une preuve de reprise exploitable.
Une intégration API peut sembler fonctionner correctement pendant des semaines, puis générer soudainement des doublons de commandes, de paiements ou d’écritures comptables. Ce type d’incident coûte rarement seulement du temps technique. Il mobilise aussi le support, la finance et le commerce dans le run métier.
La réconciliation API devient utile quand chaque écart est relié à une source de vérité, à une preuve d’exécution et à une action bornée. Elle évite les resync massifs et transforme un doute sur la donnée en décision lisible. Le dispositif conserve la fenêtre, le watermark, la clé métier et le droit de correction avant tout replay ou compensation.
Un webhook utile ne se juge pas à sa vitesse, mais à sa capacité à garder un événement lisible, rejouable et sûr quand le run se tend. Ce repère aide à cadrer signature, idempotence, retries bornés et supervision pour éviter les doublons, les files opaques et les reprises manuelles coûteuses en production au quotidien.
Questions d’achat
Questions fréquentes sur l’intégration SumUp API
Les réponses à clarifier avant de relier les paiements SumUp à un portail, un e-commerce, un CRM, un ERP ou la comptabilité.
01Quand faire appel à un intégrateur SumUp API ?
Quand un checkout SumUp doit déclencher des états fiables dans un portail, une commande, un CRM, un ERP ou la comptabilité, avec remboursements, rapprochement et reprise.
02Quelle différence entre checkout et transaction SumUp ?
Le checkout porte l’intention et le parcours de paiement ; la transaction porte le résultat financier associé. Nous conservons leurs deux identités et leur lien avec la commande.
03Un webhook SumUp suffit-il à valider un paiement ?
Non. La documentation SumUp demande de vérifier que l’événement a réellement eu lieu en appelant l’API concernée. Le webhook déclenche donc une relecture ciblée avant l’effet métier.
04Comment éviter les doublons après un retry ?
Nous acquittons rapidement, journalisons le signal, dédupliquons la transition et relisons la ressource. Un événement rejoué ne recrée ni commande, ni facture, ni email.
05Comment gérer un remboursement partiel ?
Le montant est contrôlé face au solde remboursable, puis le refund est relié à la transaction, au motif, à l’avoir, à l’écriture et au net métier restant.
06Quel premier lot SumUp recommandez-vous ?
Une commande, un checkout, une transaction, un refund partiel et une clôture témoin, avec cinq cas d’échec. L’extension attend une chaîne d’identifiants et un solde prouvés.
SumUp API · checkout · transactions · refunds
Votre prochain paiement SumUp restera-t-il explicable après un retry ou un refund partiel ?
Dawap cadre les identifiants, lectures, événements, compensations et soldes avant d’ouvrir le connecteur à plus de commandes ou de consommateurs.
Cadrer mon intégration SumUp