PLATEFORME DÉVELOPPEUR
Rapid.js
Rapid.js place la saisie de carte dans votre propre page de paiement sans placer les données de carte dans votre application. Les champs s'affichent dans votre balisage et adoptent votre style, mais ils sont hébergés par RapidCents : le numéro n'entre jamais dans votre JavaScript, vos serveurs ni vos journaux. Votre page reçoit un jeton, que votre serveur débite ensuite avec une clé secrète. L'effet concret porte sur la portée PCI : une page qui transmet la carte en clair relève de l'auto-évaluation la plus large, une page à champs hébergés de la plus étroite.
- Sandbox avec cartes test
- Webhooks signés
- Erreurs typées et idempotence
- Support développeur dédié
Ce qui passe sur le fil
Où il se situe
Dans le navigateur, en amont de votre appel serveur. Il s’initialise avec une clé publiable, monte des champs hébergés dans votre balisage et remet un jeton à votre page. Votre serveur crée ensuite le paiement avec ce jeton et sa clé secrète.
Ce que vous fournissez
La clé publiable, votre configuration de thème et les conteneurs où monter les champs. Aucune donnée de carte ne traverse votre code : c’est précisément ce que la conception protège.
Ce qui revient
Un jeton, et des rappels de cycle de vie que votre page peut écouter : validation en cours de saisie, succès, échec et défi 3-D Secure affiché en ligne plutôt qu’en redirection. La référence nomme les événements et les options de montage.
Quand l’utiliser
Garder le checkout dans votre design
Quand une redirection vers une page hébergée casserait le parcours, la marque ou la conversion que vous avez déjà réglés.
Réduire la portée PCI sans tout refaire
Les champs hébergés gardent la carte hors de votre environnement : c’est le changement qui fait basculer la plupart des intégrations vers l’autoévaluation la plus étroite.
Ajouter les portefeuilles à un checkout existant
Les boutons Apple Pay et Google Pay côtoient les champs de carte : les deux chemins produisent le même jeton à facturer côté serveur.
Mettre en œuvre Rapid.js
Chargez Rapid.js et initialisez-le avec votre clé publiable.
Montez les champs de carte dans vos conteneurs et appliquez vos valeurs de thème.
Écoutez les événements de validation et de soumission, et désactivez le bouton tant que les champs ne sont pas valides.
Transmettez le jeton reçu à votre serveur, qui crée le paiement avec la clé secrète.
Traitez le rappel de défi 3-D Secure et confirmez l’état final depuis la réponse du paiement.
Ce qui échoue, et comment vous l’apprenez
Une politique de sécurité de contenu trop stricte
Les champs hébergés se chargent depuis RapidCents : une politique restrictive affiche une case vide, sans erreur JavaScript utile. C’est l’échec le plus fréquent du premier jour.
Vouloir lire la valeur saisie
Les champs sont isolés par conception et votre page ne peut pas inspecter la saisie. L’état de validation passe par des événements; exiger le numéro revient à demander ce que les champs hébergés empêchent.
Prendre le jeton pour un paiement
Un jeton est une permission de débiter, pas un débit. Tant que votre serveur n’a pas créé le paiement, rien n’est autorisé, aussi réussi que le navigateur ait paru.
Ignorer le rappel d’authentification
Si 3-D Secure présente un défi et que votre page n’écoute pas le rappel, le client le complète et votre checkout n’en sait rien. C’est la réponse du paiement qui confirme le résultat.
Sandbox par rapport à la production
La clé publiable choisit l’environnement
Une clé publiable sandbox produit des jetons sandbox, facturables uniquement par une clé secrète sandbox. Une version livrée avec la mauvaise clé échoue à l’appel serveur, pas dans le navigateur.
Les deux résultats d’authentification à la demande
Des cartes test documentées forcent un passage 3-D Secure sans friction et un défi : le rappel en ligne s’exerce délibérément au lieu d’être attendu.
Le style se comporte pareil
Valeurs de thème, points de rupture et claviers mobiles se comportent identiquement dans les deux environnements : la revue visuelle faite en sandbox tient en production.
Questions sur Rapid.js
Rapid.js réduit-il ma portée PCI?
C’est généralement le changement qui la réduit. Le numéro est saisi dans des champs hébergés : il n’atteint ni vos serveurs ni votre JavaScript, ce qui fait passer le checkout du questionnaire le plus large au plus étroit. Votre évaluateur confirme lequel s’applique.
Puis-je styliser les champs selon mon checkout?
Oui. Les champs acceptent des valeurs de thème : typographie, espacement, couleurs et états d’erreur suivent votre design. Ce que vous ne pouvez pas faire, c’est lire ou écrire la valeur du champ, et c’est le prix de la réduction de portée.
Quelle différence entre Rapid.js et le checkout hébergé?
Le checkout hébergé est une page RapidCents vers laquelle le client est dirigé. Rapid.js garde le client sur votre page et n’héberge que les zones de saisie. Les deux gardent la carte hors de vos systèmes; le choix porte sur la part d’expérience que vous voulez posséder.
Comment 3-D Secure fonctionne-t-il avec des champs intégrés?
Le défi s’affiche en surimpression sur votre checkout plutôt que par redirection, et votre page est avertie par un rappel. Le résultat qui fait foi reste l’état du paiement créé par votre serveur.
Les boutons de portefeuille exigent-ils une autre intégration?
Ils côtoient les champs de carte et aboutissent au même jeton : votre création de paiement côté serveur ne change pas. Ce qui diffère est l’admissibilité par appareil et par domaine, documentée dans la référence.
Qu’est-ce qui casse Rapid.js le plus souvent au déploiement?
Une politique de sécurité de contenu non mise à jour pour les domaines d’où se chargent les champs. Le symptôme est un conteneur vide plutôt qu’une erreur levée : vérifiez la politique avant votre propre code.
Peut-on enregistrer une carte depuis une page de paiement Rapid.js?
Oui, puisque la carte est déjà saisie sur une surface hébergée par RapidCents et que votre serveur reçoit un jeton. Conservez ce jeton avec la fiche du client, avec la marque et les quatre derniers chiffres à titre d'affichage seulement, et débitez-le plus tard par l'API de paiement au lieu de redemander la carte.
Suite de l’intégration
L'API de tokenisation RapidCents renvoie un jeton de carte, pour que le logiciel marchand ne stocke jamais le PAN. API de tokenisation
Créez, réutilisez et retirez des jetons de paiement par API, sans jamais stocker de numéros de…
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écouvrirUne 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écouvrirUn exemple de paiement RapidCents prêt à copier, à côté de la réponse sandbox qu'il produit. Exemples de code
Exemples prêts à copier : création, capture, remboursement et vérification des 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é
