Vue d’ensemble
Le sandbox est l’endroit où vous prouvez que votre intégration gère un refus, un remboursement et un paiement non confirmé — des résultats que vous ne pouvez pas produire à la demande avec de l’argent réel. L’identifiant de compte que vous envoyez choisit le résultat. Chaque scénario ci-dessous est déterministe : le même identifiant produit toujours le même résultat.Le sandbox utilise le même hôte, les mêmes routes et le même en-tête de clé que la production. La seule chose qui change, c’est la clé. Appelez Valider la clé API et lisez
key.type pour confirmer dans quel environnement vous vous trouvez.Ce qui est identique
Tout ce qui compte pour votre code :- l’URL de base,
https://billapi.oneclickdz.com - l’en-tête
X-Access-Token - les huit routes
- l’enveloppe de réponse,
requestIdet l’en-têteX-Request-Id - les sept statuts et le cycle de vie asynchrone
- l’interrogation, l’idempotence par
refet les garde-fous403/409 - les codes d’erreur et leurs statuts HTTP
Ce qui diffère
- Une requête sandbox n’atteint jamais un facturier et ne déplace jamais d’argent.
- Les résultats sont choisis par l’identifiant de compte, non par ce qu’un compte doit réellement.
GET /v3/partnersrenvoie une table fixe plutôt que la disponibilité réelle.- Les factures du sandbox sont renvoyées avec
fee: 0, donctotalest égal àamount. Lisezfeeettotaldans la réponse — en production, ils ne seront pas nuls. - Les transitions sont rapides : une découverte aboutit en bien moins d’une seconde, un paiement en environ une demi-seconde. Le scénario
UNKNOWNreste délibérément en attente pendant environ 60 secondes pour que vous puissiez exercer votre parcours d’examen.
Scénarios de flux métier
Envoyez l’identifiant dans l’objetaccount pour le partenaire indiqué. « Découverte » est l’état que la transaction atteint après POST /v3/bills/discover ; « Paiement » est celui qu’elle atteint après POST /v3/bills/pay.
Les deux lignes SEAAL et la ligne AADL.
SEAAL et AADL sont actuellement désactivés dans les deux environnements, et cette vérification s’exécute avant le choix du scénario sandbox — ces trois identifiants répondent donc 503 PARTNER_UNAVAILABLE plutôt que le résultat décrit par leur scénario. Ils sont listés ici parce qu’ils redeviendront accessibles dès que ces facturiers seront réactivés. Pour tester « aucune facture à payer » et « compte invalide » aujourd’hui, utilisez les lignes ADE.Scénarios d’authentification et de contrôle
Un parcours sandbox de bout en bout
Le cas nominal ADE, de la découverte au reçu. Chaque valeur ci-dessous est réelle et reproductible.Utilisez un
ref neuf à chaque exécution, sinon la deuxième exécution répond 403 DUPLICATED_REF. Suffixer le ref avec votre propre compteur d’exécutions de test est l’approche la plus simple.Validation d’intégration recommandée
Trois vérifications qui prouvent le contrat avant d’aller plus loin :1
Vérifier la forme de /v3/validate
account.id, account.status, account.currency et key.type sont tous présents, et key.type vaut SANDBOX.2
Confirmer la table /v3/partners
Cinq clés, chacune avec un
status valant ACTIVE ou UNAVAILABLE, y compris Algérie Télécom avec ses accents.3
Exécuter un aller-retour complet
Découverte, paiement et recherche par
ref — prouvant que votre ref renvoie bien à la transaction que vous avez créée.Scénarios qui méritent d’être automatisés
Au-delà du cas nominal, ces quatre-là sont ceux qui débusquent de vrais bugs :Passage en production
1
Changer la clé, ne rien changer d'autre
Même URL de base, même en-tête, mêmes routes. Seule la valeur de la clé change.
2
Vérifier l'environnement au démarrage
Appelez
/v3/validate et faites échouer votre séquence de démarrage si key.type n’est pas celui que ce déploiement attend.→ Valider la clé API3
Relire fee et total dans la réponse
Le sandbox renvoie
fee: 0. Pas la production. Si quoi que ce soit dans votre code supposait des frais nuls, cela casse ici.4
Confirmer que votre interrogation gère UNKNOWN
En production, cet état est rare et coûteux à mal gérer. Prouvez que la branche existe avant d’en avoir besoin.
5
Vérifier que votre tâche de rapprochement s'exécute
Elle aurait déjà dû tourner face au sandbox, sans rien trouver. Le premier jour en production, c’est votre filet de sécurité.→ Reçus et rapprochement
6
Conserver la clé sandbox
Chaque changement futur est testé contre ces scénarios avant d’atteindre la production.
Liste de vérification avant mise en production
Bonnes pratiques
Automatiser les quatre scénarios difficiles
Factures vides, refus, remboursement et examen. Ils sont déterministes, donc ils ont leur place dans votre suite de tests.
Ne jamais présumer de la disponibilité en sandbox
La table des partenaires du sandbox est fixe. La disponibilité en production est réelle et change.
Varier le ref à chaque exécution
Sinon, la deuxième exécution de votre suite de tests échoue sur
DUPLICATED_REF.Continuer à tester après la mise en production
Le sandbox ne coûte rien. Exécutez la suite à chaque version.
Pages associées
Valider la clé API
Prouver à quel environnement appartient une clé
Vue d'ensemble du paiement de factures
La carte en cinq étapes
Interrogation du statut
Gérer
UNKNOWN et REFUNDEDGestion des erreurs
Tous les codes d’erreur au même endroit

