Skip to main content
NewChargeback Protection + Fee Intelligence for high-volume merchants. Get a savings analysis and a review of your dispute handling.See how it works
Details

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

API de tokenisation

L'API de tokenisation permet de créer, de réutiliser et de retirer des jetons de paiement par programmation : une carte enregistrée devient une référence que vous détenez plutôt qu'un numéro que vous stockez. La carte est saisie sur une surface hébergée par RapidCents — champs intégrés, page de paiement hébergée, terminal de paiement ou terminal virtuel — et ce qui revient est un jeton associé à cette carte dans le coffre-fort. Le jeton ne vaut rien ailleurs : ce n'est pas un numéro déguisé et il ne peut être rejoué auprès d'un autre processeur.

  • Sandbox avec cartes test
  • Webhooks signés
  • Erreurs typées et idempotence
  • Support développeur dédié
Demander un accès sandboxSign Up
API de tokenisation RapidCents créant un jeton de carte, à côté d'un terminal de capture
L'API de tokenisation RapidCents renvoie un jeton de carte, pour que le logiciel marchand ne stocke jamais le PAN.

Ce qui passe sur le fil

  • Où elle se situe

    Entre la saisie de la carte et chaque débit ultérieur. Le jeton se crée une fois, depuis une surface hébergée; ensuite vos systèmes le référencent au lieu d’une carte : achat répété, abonnement, acompte et solde, ou débit dans un autre canal.

  • Ce que vous envoyez

    À la création, rien de sensible : la surface hébergée fournit la carte et votre serveur reçoit la référence. Pour la réutilisation et le cycle de vie, le jeton et la fiche client à laquelle il appartient. La référence nomme les champs.

  • Ce qui revient

    Une référence de jeton et juste assez de détail non sensible pour montrer au client quelle carte il utilise : marque et quatre derniers chiffres, pas le numéro. Tout ce qui permettrait de reconstituer la carte est volontairement absent.

Quand l’utiliser

  • Tout ce qui se facture plus d’une fois

    Abonnements, versements, adhésions, acompte suivi d’un solde : chacun exige une carte qui survive à la première transaction sans que vos systèmes la détiennent.

  • Achat en un clic et clients fidèles

    Un jeton enregistré transforme un rachat en confirmation plutôt qu’en saisie de carte, que le client revienne en ligne ou appelle.

  • Garder une portée PCI étroite

    Conserver des jetons plutôt que des numéros garde les données brutes hors de votre environnement : cela réduit ce qui doit être évalué au lieu d’ajouter des contrôles autour de leur détention.

Mettre en œuvre API de tokenisation

  1. Captez la carte sur une surface hébergée par RapidCents et recevez le jeton côté serveur.

  2. Conservez le jeton avec votre fiche client, avec la marque et les quatre derniers chiffres pour affichage.

  3. Facturez le jeton par l’API de paiement plutôt que de redemander la carte.

  4. Inscrivez les jetons facturés régulièrement à Account Updater pour qu’une réémission ne casse pas le calendrier.

  5. Retirez le jeton quand le client supprime le moyen ou que la relation prend fin.

Ce qui échoue, et comment vous l’apprenez

  • Conserver autre chose que le jeton

    Garder aussi le numéro, même brièvement, même chiffré, remet la carte dans votre environnement et annule la raison d’être de la tokenisation.

  • Un jeton qu’on ne peut attribuer

    Un jeton conservé sans la fiche client devient inutilisable dès qu’on demande quelle carte est enregistrée. Écrivez les deux dans la même transaction.

  • Des jetons jamais retirés

    Un client qui supprime une carte s’attend à sa disparition. Un coffre qui ne fait que grossir est un problème de conformité et de support, et le chemin de suppression est celui qu’on oublie de construire.

  • Croire qu’un jeton survit seul à une réémission

    La référence survit, mais la carte derrière doit être rafraîchie. Sans inscription à Account Updater, une carte réémise échoue au prochain débit avec un refus que personne n’a provoqué.

Sandbox par rapport à la production

  • Les jetons ne franchissent pas les environnements

    Un jeton créé en sandbox n’a aucun équivalent en production et ne peut être facturé avec des clés réelles. Chaque moyen enregistré doit être recréé dans l’environnement où il sera facturé.

  • Le cycle de vie se répète librement

    Créer, remplacer et supprimer des jetons en sandbox est la façon pratique de prouver que votre chemin de suppression fonctionne, difficile à démontrer sur de vraies fiches clients.

  • Le comportement de mise à jour est simulé

    Le sandbox peut montrer une carte rafraîchie parvenir au jeton, mais la couverture réelle dépend de la participation du réseau et de l’émetteur. Construisez le traitement en sandbox, attendez-vous à des écarts en production.

Questions sur API de tokenisation

Quelle différence entre un jeton et un numéro chiffré?

Un numéro chiffré reste un numéro de carte, et qui détient la clé détient la carte. Un jeton ne porte aucune donnée de carte : c’est une référence que seul RapidCents peut résoudre, sans valeur pour qui la copie.

Puis-je facturer le même jeton en ligne et en personne?

Oui. Un jeton créé sur n’importe quelle surface hébergée se facture sur les deux canaux du même compte : une carte prise au téléphone peut servir en magasin sans la redemander.

Qu’arrive-t-il au jeton quand la carte expire?

La référence reste valide; c’est la carte derrière qui doit être rafraîchie. Account Updater applique les réémissions et les changements d’expiration au jeton enregistré, sans contacter le client.

La tokenisation satisfait-elle mes obligations PCI?

Elle les réduit, ce qui n’est pas les supprimer. Que la carte n’entre jamais dans vos systèmes est le changement qui ramène la plupart des intégrations à une évaluation bien plus courte; votre évaluateur confirme ce qui reste.

Puis-je transférer mes jetons vers un autre fournisseur?

Un jeton n’a de sens que dans le coffre qui l’a émis, ce qui vaut pour tout service de tokenisation. La portabilité est une question contractuelle et réseau, pas une question d’API : posez-la au moment de choisir un fournisseur.

Ai-je besoin de l’API si je ne prends que des paiements uniques?

Pas pour le paiement lui-même. Elle prend son sens dès qu’un second débit devient possible — nouvelle commande, remboursement partiel, acompte puis solde — parce que l’autre option est de redemander la carte.

Que doit-il se passer quand un client supprime sa carte enregistrée?

Le jeton doit être retiré, et pas seulement masqué dans votre interface. Un client qui supprime une carte s'attend à ce qu'elle disparaisse, et un coffre-fort qui ne fait que grossir devient un problème de conformité et de support. Le chemin de suppression est celui que les intégrations oublient le plus souvent : répétez-le en sandbox.

Les jetons créés en sandbox fonctionnent-ils en production?

Non. Les jetons ne franchissent pas la frontière des environnements : un jeton sandbox n'a pas d'équivalent en production et ne peut être débité avec des clés de production. Chaque carte enregistrée doit être recréée dans l'environnement où elle sera facturée, ce qui fait du sandbox l'endroit pour éprouver le cycle de vie, pas pour constituer un vrai coffre-fort.

Suite de l’intégration

Take the next step

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
  • No obligation
  • Payment specialists, not a call centre
  • Secure statement upload