Skip to main content

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, requestId et l’en-tête X-Request-Id
  • les sept statuts et le cycle de vie asynchrone
  • l’interrogation, l’idempotence par ref et les garde-fous 403 / 409
  • les codes d’erreur et leurs statuts HTTP
Le passage en production change votre clé. Il ne change pas une ligne de votre intégration.

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/partners renvoie une table fixe plutôt que la disponibilité réelle.
  • Les factures du sandbox sont renvoyées avec fee: 0, donc total est égal à amount. Lisez fee et total dans 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 UNKNOWN reste délibérément en attente pendant environ 60 secondes pour que vous puissiez exercer votre parcours d’examen.
Le sandbox n’est ni un test de charge ni un test de disponibilité. Un facturier ACTIVE dans la table du sandbox peut être hors service en production — gérez 503 PARTNER_UNAVAILABLE quoi que le sandbox vous ait indiqué.

Scénarios de flux métier

Envoyez l’identifiant dans l’objet account 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.
Les formes complètes des objets, à copier :

Scénarios d’authentification et de contrôle

Exercez les trois. Le chemin 403 DUPLICATED_REF en particulier est celui dont dépend votre logique de reprise — si la réutilisation d’un ref surprend votre code en sandbox, elle le surprendra en production avec de l’argent en jeu.

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 :
Le scénario d’examen est le test le plus important de ce tableau. C’est le seul moyen économique de prouver que votre code ne rembourse pas un client dont la facture a réellement été payée.

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é API
3

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 REFUNDED

Gestion des erreurs

Tous les codes d’erreur au même endroit