Aller au contenu principal
NewChargeback Protection + Fee Intelligence for high-volume merchants. Get a savings analysis and a review of your dispute handling.See how it works
Détails

Chargeback Protection + Fee Optimization

See how it works: high-volume merchants get automated dispute evidence, interchange optimization, and real-time savings visibility.

See how it works
Fee Check

PLATEFORME DÉVELOPPEUR

Webhooks

Les webhooks RapidCents poussent les événements du cycle de vie d’un paiement vers un point de terminaison que vous possédez : autorisation, capture, remboursement, contestation ouverte et règlement versé. Chaque charge utile est signée par HMAC sur les octets exacts envoyés, donc votre serveur peut prouver qu’un événement est authentique avant d’agir, et la livraison est relancée jusqu’à ce que le point de terminaison réponde 2xx. La livraison est au moins une fois : le traitement doit être idempotent, dédoublonné sur l’identifiant de l’événement.

  • Sandbox avec cartes test
  • Webhooks signés
  • Erreurs typées et idempotence
  • Support développeur dédié
Demander un accès sandboxS'inscrire
Flux d'événements webhook RapidCents et chronologie de livraison près d'un terminal bleu
Une chronologie de livraison webhook RapidCents à côté du paiement qui l'a déclenchée, un terminal de test sur le bureau.

Ce qui passe sur le fil

  • Où ils se situent

    En sortie, de RapidCents vers un point de terminaison HTTPS routable que vous possédez. Ils suivent leur propre horloge, indépendante de la requête qui a créé le paiement, et peuvent arriver avant ou après son retour.

  • Ce que vous recevez

    Un corps JSON décrivant un événement : son identifiant, son type et la ressource concernée dans son état actuel. Un en-tête de signature l’accompagne, calculé sur les octets exacts envoyés. La référence liste les types et leur charge utile.

  • Ce que vous renvoyez

    Un code 2xx, et rien d’autre qui compte. Tout ce qui sort du 2xx est lu comme un échec et planifie une relivraison : une écriture lente dans le gestionnaire produit des doublons plutôt qu’un succès tardif.

Quand l’utiliser

  • Garder les commandes synchronisées

    Le statut d’une commande devrait suivre l’événement de paiement plutôt qu’une boucle d’interrogation, plus lente et plus lourde que d’attendre d’être averti.

  • Réagir aux contestations

    Un événement de contestation donne la fenêtre de preuve le jour même plutôt qu’en fin de mois : c’est souvent la différence entre répondre et renoncer.

  • Fermer les livres

    L’événement de versement est celui qui intéresse la finance : il nomme le lot d’où vient un dépôt et permet d’écrire une écriture sur de l’argent réellement arrivé.

Mettre en œuvre Webhooks

  1. Enregistrez un point de terminaison HTTPS et gardez le secret de signature dans un gestionnaire de secrets.

  2. Captez le corps brut de la requête avant tout intergiciel d’analyse.

  3. Vérifiez la signature en temps constant, puis rejetez tout ce qui ne correspond pas.

  4. Dédupliquez sur l’identifiant d’événement, répondez 2xx et mettez le travail lent en file.

  5. Rejouez un événement déjà livré et confirmez que le gestionnaire n’écrit qu’une fois.

Ce qui échoue, et comment vous l’apprenez

  • Signature vérifiée sur un corps analysé

    Un intergiciel qui analyse le JSON et vous remet un objet a déjà modifié les octets. Le HMAC ne correspondra pas, et le symptôme est un événement valide rejeté comme falsifié.

  • Des événements hors séquence

    Les relances font qu’un événement tardif peut précéder un plus ancien. Fiez-vous à l’état porté par la charge utile, pas à l’ordre d’arrivée, et ignorez ce qui ferait reculer une ressource.

  • Un accusé de réception trop tardif

    Si votre gestionnaire exécute le traitement avant de répondre, un dépassement de délai provoque une relivraison et un second traitement. Accusez d’abord, travaillez ensuite, et rendez ce travail répétable.

  • Un point de terminaison muet

    Les livraisons n’échouent pas bruyamment de votre côté. Chaque tentative et son résultat sont consignés avec l’événement : une alerte sur les réponses non 2xx répétées attrape un consommateur silencieusement brisé.

Sandbox par rapport à la production

  • Un tunnel fait un point de terminaison valide

    Les livraisons sandbox atteignent n’importe quel tunnel HTTPS local : la vérification de signature se construit sans rien déployer. La production exige une adresse routable et un certificat valide.

  • Des événements qui prendraient des jours

    Les événements de règlement et de versement se déclenchent selon un calendrier accéléré : le gestionnaire qui ferme vos livres s’exerce dans la même exécution que la création du paiement.

  • Secrets de signature distincts

    Le secret sandbox n’est pas celui de production. Un gestionnaire correct en sandbox rejettera chaque événement réel si le secret n’a pas été remplacé à la bascule : c’est l’échec de mise en production le plus courant.

Questions sur Webhooks

Comment vérifier la signature d’un webhook RapidCents?

Calculez un HMAC sur le corps brut de la requête avec votre secret de signature et comparez-le à l’en-tête de signature en temps constant. Vérifiez avant d’analyser, car l’analyse modifie la charge utile brute.

Que se passe-t-il si mon point de terminaison est hors service?

La livraison est relancée selon un calendrier de temporisation progressive. Les événements restent aussi consultables par l’API, donc une panne ne fait perdre aucune donnée.

Le même webhook peut-il arriver deux fois?

Oui. La garantie est une livraison au moins une fois, donc vos gestionnaires doivent être idempotents, indexés sur l’identifiant de l’événement.

Combien de points de terminaison puis-je enregistrer?

Plus d’un, et c’est le modèle le plus propre quand des systèmes différents s’intéressent à des événements différents : un service de commandes et un traitement financier n’ont pas à partager un gestionnaire.

Le webhook ou la réponse API doit-il mettre à jour ma commande?

Le webhook. La réponse dit ce qui s’est passé à cet instant; le webhook dit tout ce qui suit, et c’est le seul canal qui vous prévient quand un remboursement ou une contestation naît hors de votre application.

Et si je n’accuse jamais réception d’un événement?

Les relances se poursuivent selon leur calendrier, puis cessent. L’événement ne disparaît pas : il reste lisible par l’API, donc la reprise après une panne prolongée est une requête de rattrapage, pas un billet de support.

Comment tester le chemin d’échec sans casser mon point de terminaison?

Rejouez un événement déjà livré vers un gestionnaire que vous forcez à répondre autrement qu’en 2xx, puis confirmez l’arrivée de la relance et que votre déduplication n’écrit qu’une seule fois.

À quelle vitesse mon point de terminaison doit-il répondre?

Assez vite pour que la livraison n’expire pas, c’est-à-dire accuser réception avec un 2xx d’abord et mettre le travail lent en file ensuite. Un gestionnaire qui traite la commande avant de répondre transforme un événement en nouvelle livraison et en second traitement.

Les webhooks m’informent-ils des remboursements faits depuis le tableau de bord?

Oui, et c’est la principale raison de les consommer. Un remboursement fait par un employé dans le tableau de bord, une contestation déposée des semaines plus tard et un dépôt versé pendant la nuit arrivent tous sous forme d’événements. Aucun n’apparaît dans une réponse synchrone que votre application attendait.

Suite de l’intégration

Prochaine étape

Parlez à un spécialiste RapidCents

Fee Check de RapidCents lit un relevé de traitement et sépare l’interchange de la marge. Téléversez un relevé pour une analyse instantanée, ou ouvrez un compte marchand et commencez à encaisser sur un seul compte.

Vérifier mes fraisCommencer
  • Sans engagement
  • Spécialistes paiement au Canada
  • Téléversement sécurisé