Tokenisation et paiements récurrents

Chaque paiement réussi crée automatiquement un token réutilisable (tok_xxx). Le token remplace la carte du client. Aucune donnée de carte n'est exposée à votre système, et le token fonctionne pour des paiements à tout montant ou calendrier.

Obtenir le token

Le token_id est renvoyé à deux endroits :

• La réponse de GET /checkout-sessions/{id} → transaction.token_id
• Le webhook payment.completed → payload_redacted.token_id

Stockez-le sur la fiche client.

Facturer un token

POST /api/v1/charge-token

{
  "token_id": "tok_abc123",
  "amount": 999,
  "currency": "USD",
  "order_id": "RENOUVELLEMENT-1042"
}

Réponse en cas de succès

{
  "status": "captured",
  "token_id": "tok_abc123",
  "amount": 999,
  "currency": "USD",
  "gateway_transaction_id": "5ABCABEC-4867-410B-B76C-E85721CF859B"
}

Réponse en cas d'échec

{
  "status": "failed",
  "token_id": "tok_abc123",
  "error_code": "05",
  "error_message": "Declined — insufficient funds"
}

Cas d'usage

• Renouvellements d'abonnement — facturez le token selon un calendrier.
• Cartes enregistrées — clients récurrents réutilisant une carte sans la ressaisir.
• Recharges — soldes de portefeuille, flux de rechargement.
• Paiement à l'usage — facturation par appel API, usage mesuré.

Facturation des abonnements

Genius Checkout intègre un moteur d'abonnements qui planifie les paiements, retente les renouvellements échoués et émet des événements subscription.charged. Voir la section Subscriptions du tableau de bord marchand, ou construisez votre propre planificateur sur charge-token.

Cycle de vie du token

• Un token reste actif jusqu'à révocation depuis le tableau de bord ou le portail client.
• Un token révoqué renvoie failed avec une erreur claire si vous tentez de le facturer.
• Les tokens sont scopés par marchand — la même carte chez deux marchands crée deux tokens distincts.

Suite

• Remboursements — totaux ou partiels
• Exemples de code → Facturation récurrente