PLATEFORME DÉVELOPPEUR
Démarrage rapide
Le démarrage rapide de RapidCents mène une intégration de zéro à un paiement test vérifié. Il émet des identifiants sandbox, crée un paiement avec une carte test documentée, livre le webhook signé qui en résulte à votre point de terminaison et confirme que la vérification de signature réussit. La séquence est volontairement serveur d’abord : l’appel qui autorise l’argent part de votre serveur avec une clé secrète, et le navigateur n’intervient qu’au moment d’ajouter la saisie de carte. Ces quatre gestes sont exactement ceux que la bascule en production répète.
- Sandbox avec cartes test
- Webhooks signés
- Erreurs typées et idempotence
- Support développeur dédié
Ce qui passe sur le fil
Vous envoyez une requête de paiement
Un corps JSON portant le montant, la devise, une référence au moyen de paiement et une clé d’idempotence, authentifié par votre clé secrète sandbox. La référence API nomme chacune de ces entrées.
Vous recevez un paiement et son état
La réponse indique si le paiement est autorisé, refusé ou en attente d’authentification, et porte un identifiant de requête à journaliser. C’est l’état, pas le seul code HTTP, qui guide votre application.
Le webhook arrive séparément
L’événement du cycle de vie est livré hors bande, signé, parfois après le retour de votre réponse initiale. Traitez les deux comme des arrivées indépendantes, pas comme un aller-retour unique.
Quand l’utiliser
Évaluer RapidCents
Le moyen le plus rapide de voir la forme des requêtes et des réponses dans un environnement réel plutôt que d’en lire la description.
Accueillir un nouveau développeur
Un parcours reproductible qui se termine par un paiement fonctionnel, et qui met l’étape webhook en évidence dès le départ.
Répéter une bascule
Ces quatre gestes sont exactement ceux que la mise en production refait avec des clés réelles : les rejouer avant la bascule coûte peu.
Mettre en œuvre Démarrage rapide
Demandez un accès sandbox et conservez la clé secrète côté serveur uniquement.
Créez un paiement d’un petit montant avec une carte test documentée.
Pointez un point de terminaison webhook vers un tunnel HTTPS local et recevez l’événement.
Vérifiez la signature sur le corps brut, puis accusez réception par un 2xx.
Recommencez avec une carte refusée et confirmez que votre gestionnaire a pris la bonne branche.
Ce qui échoue, et comment vous l’apprenez
La clé secrète a fui côté client
Si une clé secrète se retrouve dans un paquet navigateur ou un binaire mobile, considérez-la compromise et faites la rotation. La saisie de carte au navigateur utilise une clé publiable, incapable de déplacer de l’argent.
La signature échoue sur un événement valide
Presque toujours parce qu’un intergiciel a analysé, resérialisé ou nettoyé le corps avant la vérification. Captez les octets bruts, vérifiez, puis analysez.
Le paiement a réussi, la commande non
Votre gestionnaire de réponse et celui de webhook ont agi tous les deux, ou aucun. Indexez la mise à jour sur l’identifiant d’événement pour qu’une double livraison ne fasse rien.
Sandbox par rapport à la production
Le résultat est choisi, pas subi
En production, l’émetteur décide. En sandbox, c’est le numéro de carte : une approbation reste une approbation et un refus reste le même refus, ce qui rend l’exécution reproductible en intégration continue.
Un tunnel suffit
Les webhooks sandbox atteignent n’importe quel tunnel HTTPS local. La production exige un point de terminaison routable avec certificat : c’est la seule étape que le démarrage rapide ne répète pas.
Le règlement est comprimé
L’événement de versement qui suit une capture sandbox arrive en minutes. En production, il suit votre calendrier de dépôt : revalidez toute hypothèse de délai.
Questions sur Démarrage rapide
Combien de temps prend le démarrage rapide RapidCents?
Un premier paiement sandbox réussi prend habituellement moins d’une heure, émission des identifiants comprise. La vérification des webhooks ajoute environ une heure de plus, selon la configuration de votre tunnel.
Quelles cartes test devrais-je utiliser?
La page Tests documente les cartes d’approbation, de refus, de fonds insuffisants et de défi 3-D Secure, afin que chaque branche de votre gestion d’erreurs soit exercée délibérément.
Puis-je faire le démarrage rapide sans URL publique?
Oui. N’importe quel tunnel HTTPS vers localhost reçoit les webhooks du sandbox; un déploiement public n’est nécessaire qu’en production.
L’étape webhook est-elle utile si je lis déjà la réponse du paiement?
Oui. La réponse donne le résultat à cet instant. Les états ultérieurs — remboursement, contestation, versement — n’arrivent que sous forme d’événements : sans webhooks, votre système se périme dès qu’une chose change après le paiement.
Faut-il construire l’appel serveur ou les champs de carte en premier?
L’appel serveur. C’est lui qui autorise l’argent et qui porte votre gestion d’erreurs. Les champs Rapid.js s’ajoutent une fois qu’un paiement réussit déjà avec une carte test documentée.
Que reste-t-il à faire après un démarrage rapide réussi?
L’idempotence sur chaque appel qui modifie un état, une politique de relance qui sépare refus temporaires et définitifs, le rapprochement sur les règlements, et les secrets déplacés vers un gestionnaire. Le démarrage rapide prouve la connectivité, pas la maturité.
Puis-je faire le démarrage rapide avec des clés de production plutôt qu’en sandbox?
C’est possible, et cela débite de vraies cartes. Rien ne le justifie : les points de terminaison, les corps de requête et les codes d’erreur sont identiques dans les deux environnements, et une carte test documentée produit un refus reproductible et un défi 3-D Secure qu’aucune carte réelle ne donne sur demande.
Quel est le minimum de code que le démarrage rapide exige vraiment?
Un appel de paiement côté serveur et une route de webhook. Aucun champ de carte, aucune file d’attente et aucune base de données ne sont nécessaires pour voir à la fois un paiement et son événement signé, ce qui explique que la séquence tienne dans un après-midi. La saisie de carte avec Rapid.js s’ajoute une fois qu’un paiement réussit déjà.
Suite de l’intégration
Un compte marchand sandbox RapidCents exécute des paiements test, isolé de la production, un terminal sandbox sur le bureau. Sandbox
Demandez un accès sandbox avec des ID de marchand test et un environnement isolé.
DécouvrirTests sandbox RapidCents : cartes test documentées, un refus simulé, et un terminal pour les cas en personne. Tests
Cartes test, refus simulés et événements de règlement en sandbox.
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écouvrir
La référence de l'API RapidCents sur un poste, avec une requête type, la réponse correspondante et un terminal de test. Référence API
Points de terminaison REST pour les paiements, les clients, les remboursements et les webhooks.
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é
