Démarrer

Sandbox et valeurs de test

Le Sandbox public reproduit l’API de production avec un simulateur à la place des canaux. Aucun argent ne circule, et c’est vous qui choisissez l’issue de chaque paiement.

Hôte et identifiants

Routes, champs, signature, idempotence, erreurs et limite de débit : tout est identique à la production. Seuls changent l’hôte, les identifiants, et le simulateur qui répond à la place de l’opérateur. Aucune demande n’arrive sur un vrai téléphone.

Le Sandbox public tourne sur une pile séparée : ses données et ses clés n’atteignent jamais la plateforme réelle.

Sandbox public

INOPAS_HOST=https://sandbox.inopas.net
INOPAS_KEY=ak_sandbox
INOPAS_SECRET=sk_sandbox_demo

Choisir l’issue d’un paiement

Les deux derniers chiffres de customer_ref décident de ce que répond le simulateur. Le reste du numéro est libre : les trois numéros ci-dessous sont prêts à copier.

Issue simulée selon la fin du numéro
Fin du numéro	Numéro de test	État final	Déroulé
Toute autre fin	`+243810000000`	Payé `SUCCEEDED`	CREATED, puis PENDING, puis SUCCEEDED en quelques secondes.
…13	`+243810000013`	Échoué `FAILED`	Le canal refuse la demande. Rien n’est débité.
…99	`+243810000099`	Non confirmé `UNKNOWN`	Le canal ne répond pas. Le paiement reste UNKNOWN : c’est le cas à tester.

Tester le paiement non confirmé

C’est le cas qui distingue une intégration solide d’une intégration fragile. Un paiement UNKNOWN n’a ni réussi ni échoué : le canal n’a pas répondu, et le payeur a peut-être déjà été débité. Face à lui, votre code doit :

ne pas livrer : rien ne prouve encore que l’argent est arrivé ;
ne pas redemander le paiement : si le premier a abouti, le client paie deux fois ;
le dire au client : « paiement en cours de vérification », jamais « échec » ;
attendre l’issue finale, par webhook ou en relisant l’encaissement.

En production, la réconciliation interroge le canal et fait passer le paiement à SUCCEEDED ou FAILED ; un cas qu’elle ne peut pas trancher passe en revue manuelle. Dans le Sandbox, rien ne le tranche : le paiement reste UNKNOWN, pour que vous puissiez observer votre code dans cet état aussi longtemps qu’il le faut.

Une clé publique, des données publiques

Tous les visiteurs utilisent la même clé ak_sandbox. Deux conséquences :

GET /v1/charges liste les essais de tout le monde, pas seulement les vôtres. N’envoyez aucune donnée réelle, et retrouvez vos paiements par leur id.
Le quota de débit est commun : si d’autres testent en même temps, vous pouvez recevoir un 429. Attendez la durée indiquée par Retry-After.

Test et argent réel ne se mélangent pas

Chaque réponse porte un champ environment : sandbox ou live. Il vient de la clé qui a créé l’objet, et il est étanche.

Une clé ne lit que son environnement. Une clé Sandbox ne liste ni ne lit un paiement réel, et inversement : l’identifiant de l’autre environnement répond 404.
Le solde de test est à part. Un paiement Sandbox réussi alimente un solde de test, qui sert à essayer reversements et remboursements. Il ne crédite jamais le solde réel et ne peut pas être reversé en argent réel.
Les litiges ne concernent que l’argent réel. Une clé Sandbox n’en voit aucun.

Et ensuite

Vos tests passent dans les trois cas ? Branchez la signature dans votre code, puis préparez le traitement des erreurs.