4 endpoints
Checkout direct
Les appels que la page de paiement exécute elle-même : vérification de la session, envoi des données de carte, retour de 3-D Secure.
Les intitulés et descriptions d'endpoints viennent du contrat OpenAPI, en anglais — ils ne peuvent pas diverger de l'API.
En clair
Votre propre formulaire de carte, piloté étape par étape.
Quand l'utiliser
Uniquement si vous construisez votre propre formulaire de carte. Ces endpoints ne sont pas authentifiés par votre clé d'API mais par la session, et ils vous placent dans le périmètre de conformité des données de carte.
Comment l'intégrer
- 1Récupérez l'identifiant de session et la clé de vérification (vk) à usage unique — renvoyés à la création de la session, ou portés par la redirection du payUrl — puis vérifiez la session avec ce couple pour obtenir le contexte d'affichage : la vk est consommée par cette vérification.
- 2Envoyez les données de carte avec cette clé — jamais avec votre clé d'API.
- 3Suivez la redirection 3-D Secure si la banque l'exige, puis confirmez le retour.
- 4Interrogez l'état du paiement pour l'affichage, et attendez le webhook pour la décision métier.
Carte de test sandbox
La sandbox tourne sur de vrais rails, contre un environnement de test : les parcours sont réels, l'argent non. Une seule carte y est acceptée.
Seul ce PAN est accepté. Tout autre numéro — y compris les 4242… d'autres plateformes — est rejeté en amont — en général avec un 502 — et le code stable BAAS_CHARI_ERROR. Si vous rencontrez cette erreur en test, vérifiez d'abord la carte saisie.
- POST
/checkout/verifyVérifier une session de paiement - POST
/checkout/submitSoumettre les données de carte pour une session de paiement - POST
/checkout/returnConfirmer le retour 3-D Secure - GET
/checkout/payments/{reference}Obtenir le statut de paiement côté acheteur
Vérifier une session de paiement
Ouvre une session de paiement en vue du paiement, à partir de son sessionId et de la clé de vérification (vk) renvoyée par la réponse de création de session. Renvoie le montant, la devise, l'habillage et les capacités de la session. Verify DOIT être appelé avant submit ; sur une session à usage unique, la vk est consommée par le premier verify et ne peut pas être rejouée. Pas de clé d'API — n'envoyez pas X-CHARI-PAY-API-KEY.
Schéma · CheckoutVerifyRequest
| Champ | Type | Emplacement | Requis | Description |
|---|---|---|---|---|
sessionId | string | body | Requis | Identifiant de session issu de la réponse de création de session. |
vk | string | body | Requis | Clé de vérification (verifyKey) issue de la réponse de création de session ; à usage unique sur les sessions à usage unique. |
Soumettre les données de carte pour une session de paiement
Paie une session vérifiée par carte, de serveur à serveur (sans page hébergée). Prérequis : verify doit avoir été appelé au préalable ; lorsque la session a été créée avec keepAlive=true, savePaymentMethodConsent=true est obligatoire ; l'en-tête Idempotency-Key est obligatoire pour une session réutilisable (non à usage unique). Renvoie un statut final, ou PENDING_3DS avec une redirectionUrl que l'acheteur doit ouvrir pour effectuer le challenge 3-D Secure — appelez ensuite POST /checkout/return. Les appelants qui manipulent des données de carte brutes sont responsables de leur propre conformité PCI DSS. Pas de clé d'API — n'envoyez pas X-CHARI-PAY-API-KEY.
Schéma · CheckoutSubmitRequest
| Champ | Type | Emplacement | Requis | Description |
|---|---|---|---|---|
Idempotency-Key | string | header | Optionnel | Obligatoire pour une session réutilisable ; facultatif (mais recommandé) pour une session à usage unique. Rejouer la même clé renvoie le premier résultat. |
sessionId | string | body | Requis | Identifiant d'une session déjà vérifiée. |
card | Card | body | Requis | |
card.firstName | string | body | Requis | |
card.lastName | string | body | Requis | |
card.pan | string | body | Requis | Numéro de carte complet (PAN). Jamais stocké en clair. |
card.expiryDate | string | body | Requis | Expiration de la carte, au format MM/YY. |
card.cvv | string | body | Requis | |
card.cardName | string | body | Optionnel | Nom tel qu'imprimé sur la carte. |
savePaymentMethodConsent | boolean | body | Optionnel | Consentement explicite de l'acheteur à l'enregistrement du moyen de paiement ; requis (true) lorsque la session a keepAlive=true, ignoré sinon. |
Confirmer le retour 3-D Secure
Met en correspondance le retour de l'acheteur depuis le défi 3-D Secure avec l'opération soumise, puis renvoie le statut final ainsi que le redirectUrl d'acceptation ou de refus du marchand. À appeler une fois que l'acheteur a terminé le parcours de la redirectionUrl issue de submit. Aucune clé d'API requise.
Schéma · CheckoutReturnRequest
| Champ | Type | Emplacement | Requis | Description |
|---|---|---|---|---|
sessionId | string | body | Requis | |
operationId | integer (int64) | body | Requis |
Obtenir le statut de paiement côté acheteur
Résout le statut d'un paiement à partir de la référence de commande, de la référence du lien de paiement ou de l'identifiant de passerelle du fournisseur issu du retour 3-D Secure. Répond toujours avec notre référence et ne contient aucune donnée personnelle. Utilisez-le pour interroger le résultat après submit/return. Sans clé d'API.
| Champ | Type | Emplacement | Requis | Description |
|---|---|---|---|---|
reference | string | path | Requis | Référence de commande, référence du lien de paiement ou identifiant de passerelle du fournisseur. |
Une question sur l'intégration ?
Notre équipe technique répond aux intégrateurs, du premier appel en sandbox jusqu'à la mise en production.