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

Erreurs

Les erreurs de l’API RapidCents renvoient un code typé, un message lisible et, s’il y a lieu, une consigne de relance. Trois catégories se comportent différemment : une requête mal formée ou non autorisée, qu’aucune relance ne corrige; une défaillance de la plateforme, qu’une relance avec la même clé d’idempotence corrige généralement; et un refus de l’émetteur, qui se divise en refus temporaire et refus définitif. Un refus temporaire peut réussir plus tard, un refus définitif jamais. Branchez sur le code, jamais sur le texte du message.

  • Sandbox avec cartes test
  • Webhooks signés
  • Erreurs typées et idempotence
  • Support développeur dédié
Demander un accès sandboxS'inscrire
Réponse d'erreur API RapidCents sur un écran développeur, à côté d'un terminal de test en refus
Une erreur API RapidCents typée à l'écran, à côté de la vente sandbox refusée qui l'a produite.

Ce qui passe sur le fil

  • Où elles se situent

    Sur la réponse à un appel et sur l’événement qui signale un échec ultérieur. Le même vocabulaire de codes sert aux deux : un refus capté sur-le-champ et un renouvellement échoué la nuit passent par une seule table.

  • Ce qui revient

    Un code HTTP qui classe l’échec, et dans le corps un code typé, un message destiné à un lecteur humain et un identifiant de requête. La référence énumère les codes; le texte du message ne fait pas partie du contrat.

  • Ce que vous en faites

    Associez chaque code à une action, une seule fois et à un seul endroit : échouer, relancer, demander un autre moyen de paiement ou escalader. Aiguiller sur le texte casse à la première reformulation.

Quand l’utiliser

  • Gérer les refus

    Aiguillez sur le code, pas sur le message, qui est écrit pour des humains et peut changer sans préavis.

  • Récupérer des débits récurrents

    Les refus temporaires alimentent le calendrier de relance; les refus définitifs doivent l’arrêter et mener à demander une nouvelle carte plutôt qu’à brûler des tentatives.

  • Décider quoi montrer au client

    Certains codes portent une information exploitable par le titulaire, d’autres une information que l’émetteur s’attend à ne pas voir divulguée. La table décide du message affiché.

Mettre en œuvre Erreurs

  1. Associez chaque code documenté à une action, et faites échouer par défaut tout code inconnu.

  2. Ne relancez que les échecs temporaires et les échecs de plateforme, avec temporisation et la même clé d’idempotence.

  3. Limitez le nombre de tentatives par moyen de paiement plutôt que par requête.

  4. Affichez aux clients des messages exploitables, pas le texte brut du processeur.

  5. Journalisez ensemble le code et l’identifiant de requête pour retracer une tentative précise.

Ce qui échoue, et comment vous l’apprenez

  • Relancer un refus définitif

    Cela ne peut pas réussir, et les tentatives répétées sur un compte fermé ou bloqué sont visibles par l’émetteur. La sortie est un nouveau moyen de paiement, pas une nouvelle tentative.

  • Relancer sans la clé d’idempotence

    Une relance sans la clé est une nouvelle requête. Si la première a abouti, le client est débité deux fois et le doublon se découvre au rapprochement plutôt qu’à la caisse.

  • Montrer le message brut au client

    Le texte du processeur s’adresse à un opérateur, pas à un titulaire de carte. L’afficher donne un checkout qui invite les gens à joindre une banque qui n’est pas la leur.

  • Des codes inconnus qui passent au travers

    Un code non associé doit échouer et alerter, pas tomber par défaut dans la branche de relance. De nouveaux codes apparaissent, et le journal des modifications est l’endroit où ils sont annoncés.

Sandbox par rapport à la production

  • Vous choisissez l’erreur

    Les refus de production dépendent de l’émetteur et ne se convoquent pas. En sandbox, une carte test documentée produit le même code à chaque fois : c’est la seule façon d’écrire un test qui l’affirme.

  • Les échecs de plateforme aussi

    Les dépassements de délai et les échecs relançables se provoquent volontairement : le chemin d’idempotence s’exerce au lieu d’être présumé. C’est le chemin que personne ne teste avant qu’il coûte un double débit.

  • Le vocabulaire est identique

    Le sandbox n’utilise pas un jeu de codes réduit. Une table bâtie sur les codes sandbox est celle dont la production a besoin : l’exercice vaut donc la peine avant la bascule.

Questions sur Erreurs

Quelle est la différence entre un refus temporaire et un refus définitif?

Un refus temporaire, comme des fonds insuffisants ou une limite de vélocité, peut se dissiper à une relance ultérieure. Un refus définitif, comme un compte fermé, est permanent et ne doit pas être relancé.

Faut-il relancer immédiatement une carte refusée?

Non. Les relances immédiates sont jugées suspectes par les émetteurs. Espacez les tentatives et limitez-en le nombre, ce que le moteur récurrent fait automatiquement.

Comment retracer une seule requête en échec?

Chaque réponse porte un identifiant de requête. Journalisez-le avec le code d’erreur et le support peut localiser la tentative exacte.

Un code HTTP 200 signifie-t-il toujours un paiement réussi?

Non. Un 200 signifie que l’appel a été accepté et traité; l’autorisation, elle, est rapportée par l’état dans le corps. Confondre les deux mène à expédier des commandes refusées.

Que relancer, et combien de fois?

Relancez les échecs de plateforme et les refus temporaires, avec temporisation et la même clé d’idempotence, en limitant les tentatives par moyen de paiement plutôt que par requête. Un refus définitif n’en mérite aucune.

Comment distinguer un double débit de deux débits légitimes?

Par la clé d’idempotence. Deux débits sous la même clé sont un seul paiement rapporté deux fois; sous deux clés différentes, ce sont deux paiements, et les identifiants de requête de vos journaux le confirment.

Pourquoi un paiement réussi peut-il échouer plus tard?

L’autorisation et le règlement sont distincts. Un paiement peut être autorisé sans se régler, ou se régler puis être contesté. Ces cas arrivent en événements, avec leurs propres codes : la même table doit couvrir les échecs asynchrones.

Que faire d’un code d’erreur que je n’ai jamais vu?

Échouez de façon sûre et déclenchez une alerte. Un code non mappé ne doit pas tomber par défaut dans la branche de relance. De nouveaux codes apparaissent à mesure que la plateforme évolue et sont annoncés dans le journal des modifications : un code inconnu est un signal pour aller le lire, pas quelque chose à avaler.

Quelle part du motif de refus puis-je montrer au client?

Seulement ce que votre table de correspondance autorise. Certains codes portent une information sur laquelle le titulaire peut agir, d’autres une information que l’émetteur s’attend à ne pas voir divulguée. Afficher le texte brut du processeur produit un paiement qui invite les gens à appeler une banque qui n’est pas la leur.

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é