PLATEFORME DÉVELOPPEUR
Référence API
La référence API de RapidCents documente chaque point de terminaison avec son schéma de requête, son schéma de réponse et ses cas d’erreur : autorisation et capture, annulation, remboursement, tokenisation, gestion des clients et des identifiants enregistrés, consultation des règlements et rejeu des événements webhook. Les appels sont serveur à serveur, en HTTPS, avec une clé secrète, une version d’API fixée et une clé d’idempotence sur tout ce qui modifie un état. La réponse porte l’état de la ressource, un identifiant de requête et, en cas d’échec, un code typé.
- Sandbox avec cartes test
- Webhooks signés
- Erreurs typées et idempotence
- Support développeur dédié
Ce qui passe sur le fil
Où elle se situe
De serveur à serveur, en HTTPS, avec une clé secrète. C’est la couche derrière le checkout hébergé, Rapid.js et le tableau de bord : un paiement créé par l’un d’eux se lit et se rembourse par les mêmes points de terminaison.
Ce que vous envoyez
Un corps JSON et des en-têtes : la clé secrète, la version d’API fixée à votre compte et une clé d’idempotence sur tout ce qui modifie un état. La référence nomme chaque entrée et indique lesquelles sont obligatoires.
Ce qui revient
Un objet JSON portant la ressource et son état, un identifiant de requête pour le traçage et, en cas d’échec, un code typé lisible par machine. Le code HTTP classe le résultat; c’est le code du corps qui guide votre logique.
Quand l’utiliser
Développer côté serveur
Création, capture, annulation et remboursement s’exécutent depuis votre serveur avec la clé secrète, le seul endroit où une clé secrète a sa place.
Rapprocher les systèmes financiers
Les points de terminaison de règlement exposent lots, frais et dépôts : un export comptable relie un dépôt aux transactions qu’il contient, pas aux réponses d’autorisation.
Automatiser le back-office
Fiches clients, moyens enregistrés et remboursements sont adressables : ce que le personnel ferait à la main au tableau de bord peut s’exécuter sur un calendrier.
Mettre en œuvre Référence API
Authentifiez-vous avec votre clé secrète en HTTPS et fixez explicitement la version d’API.
Envoyez une clé d’idempotence avec chaque requête qui modifie un état, générée par opération logique.
Aiguillez sur les codes d’erreur typés plutôt que d’analyser le texte des messages.
Conservez l’identifiant de requête de chaque réponse avec votre propre enregistrement.
Faites le rapprochement à partir des enregistrements de règlement, pas des réponses d’autorisation.
Ce qui échoue, et comment vous l’apprenez
Une clé d’idempotence réutilisée
Réutiliser une clé pour une opération réellement différente renvoie le premier résultat : la seconde transaction paraît avoir disparu. Dérivez la clé de l’opération, pas du client ni de la session.
Une autorisation jamais capturée
Elle expire dans le délai de l’émetteur et la retenue est levée. Rien ne se règle : un pipeline qui attend un événement de capture s’arrête sans erreur à intercepter.
Une limitation prise pour une panne
Dépasser les limites appliquées à votre compte renvoie un état documenté avec une indication de relance, pas une requête abandonnée. Temporiser est la correction; insister transforme cela en incident.
Sandbox par rapport à la production
Mêmes points, mêmes schémas
Le sandbox n’est pas une surface réduite. Les points de terminaison, les corps de requête et les codes d’erreur sont ceux de la production : une suite de régression sandbox garde donc sa valeur.
Refus déterministes
Un refus en production dépend de l’émetteur et peut varier d’une tentative à l’autre. En sandbox, la carte test fixe le résultat : un test qui attend un code précis reste vert pour la bonne raison.
Un règlement sans attente
Lots, frais et dépôts apparaissent selon un calendrier accéléré : le code de rapprochement s’exerce en une seule exécution plutôt qu’au fil d’un cycle de versement.
Questions sur Référence API
Comment fonctionne l’idempotence dans l’API RapidCents?
Fournissez une clé d’idempotence à la création du paiement : une relance avec la même clé renvoie le résultat original au lieu de facturer deux fois, ce qui rend les délais d’attente réseau sécuritaires à relancer.
Que se passe-t-il si un paiement est autorisé mais jamais capturé?
L’autorisation expire à l’intérieur du délai de l’émetteur et les fonds retenus retournent au titulaire de la carte. Rien n’est réglé et aucuns frais ne s’appliquent à l’autorisation expirée.
Y a-t-il des limites de débit?
Oui, appliquées par compte. Les dépasser renvoie un code d’état documenté avec une indication de relance plutôt qu’une requête abandonnée. La référence documente les limites applicables et la façon dont une réponse signale qu’une limite est atteinte.
Faut-il lire le résultat dans la réponse ou dans un webhook?
Les deux, pour des raisons différentes. La réponse est le résultat synchrone que le client attend. Le webhook est la trace durable de chaque changement ultérieur — remboursement, contestation, versement — et c’est lui que votre grand livre doit suivre.
Comment retracer une transaction de bout en bout?
Conservez l’identifiant de requête de l’appel de création, l’identifiant de chaque événement traité et l’enregistrement de règlement correspondant. Ces trois identifiants permettent au support de suivre une tentative précise.
Quelle différence entre annuler et rembourser?
Une annulation supprime une autorisation avant son règlement : le titulaire ne voit jamais de débit complet. Un remboursement rend l’argent après règlement et apparaît comme un crédit distinct. Le choix dépend de l’étape du cycle de vie, pas d’une préférence.
Puis-je rembourser un paiement que l’API n’a pas créé?
Oui. Les paiements encaissés par page de paiement hébergée, lien de paiement, Rapid.js, terminal de paiement ou tableau de bord sont tous consultables et remboursables par les mêmes points de terminaison, parce qu’ils aboutissent à un seul compte marchand et non à des systèmes séparés.
Comment fonctionnent une capture partielle et un remboursement partiel sur une même autorisation?
La capture et le remboursement sont des opérations distinctes sur le paiement, et chacune porte sa propre clé d’idempotence dérivée de cette opération. Ce qui reste disponible dépend de l’état courant du paiement, que la réponse indique, et la page du point de terminaison précise les transitions permises.
Suite de l’intégration
Une requête RapidCents serveur à serveur en cours de signature, un terminal sandbox pour la contrepartie en personne. Authentification
Clés API, OAuth pour les partenaires et signature des requêtes serveur à serveur.
DécouvrirUne erreur API RapidCents typée à l'écran, à côté de la vente sandbox refusée qui l'a produite. Erreurs
Codes d’erreur typés, consignes de relance et modèles d’idempotence.
Découvrir
Une chronologie de livraison webhook RapidCents à côté du paiement qui l'a déclenchée, un terminal de test sur le bureau. Webhooks
Événements webhook signés pour le cycle de vie des paiements, traités de façon idempotente.
DécouvrirUn projet SDK RapidCents exécute un paiement test, la même vente visible sur un terminal sandbox. SDK
SDK officiels Node.js, Python, PHP et mobile, avec modèles typés et relances.
Découvrir
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.
- Sans engagement
- Spécialistes paiement au Canada
- Téléversement sécurisé
