Démarrage
Premier pay-in, sur le sandbox d'abord.
Deux serveurs, deux clés
L'API az54 existe sur deux serveurs, et une clé n'est valide que sur celui où elle a été émise :
| Serveur | Clé | Ce qu'il fait |
|---|---|---|
https://api.sandbox.az54.com | sk_test_… | Aucun opérateur réel. L'issue d'un pay-in est pilotée par le numéro appelé — voir Numéros de test. |
https://api.az54.com | sk_live_… | Production. Toute requête sollicite réellement le combiné indiqué et déplace de l'argent réel. |
Une clé sk_test_ présentée sur api.az54.com, ou une sk_live_ sur
api.sandbox.az54.com, est refusée en 401 : les deux serveurs ne partagent
ni base de données ni configuration. Le préfixe de la clé n'est donc plus
cosmétique — c'est lui qui détermine le seul serveur où elle fonctionne.
Il n'existe pas encore de tableau de bord sandbox (pas de
app.sandbox.az54.com), et la création de clé n'est pas un endpoint public
(Authentification). Une clé sk_test_ s'obtient
aujourd'hui auprès du support az54 — pas en libre-service. Le tableau de bord
app.az54.com n'émet que des clés sk_live_.
Premier paiement, sur le sandbox
- Munissez-vous d'une clé
sk_test_(support az54). - Appelez
GET /v1/corridors/available?phone=…&transactionType=payinavec un numéro de votre pays d'intégration. La réponse est la même qu'en production — mêmes pays, mêmes opérateurs, mêmes bornes de montant — puisque le catalogue de corridors du sandbox est une copie de celui de production. Seul le PSP qui répond derrière change. - Postez un pay-in au montant minimum du corridor, vers un numéro dont les deux derniers chiffres pilotent le résultat que vous voulez observer — voir le catalogue complet dans Numéros de test.
- Attendez la notification sortante. Elle porte l'issue du paiement, avec les mêmes champs, la même signature HMAC-SHA512 et la même échelle de rejeu qu'en production (Webhook sortant).
- Si elle n'arrive pas, lisez
GET /v1/transactions?orderId=…avec la même clé : c'est l'état courant de la transaction. Le journal des tentatives de notification, lui, n'est renvoyé que parGET /v1/transactions/by-id/{transactionId}(Réconciliation).
Configurez le webhook sortant avant votre premier appel :
c'est le chemin nominal, et le seul qui livre l'authorizationUrl d'un
corridor en redirection (utilisez operatorCode: "wave" sur le sandbox pour en
déclencher un — voir Workflows de pay-in).
Ce qui reste vrai des deux côtés
Le sandbox n'est pas un environnement dégradé : c'est le même code, la même
validation, les mêmes limites de débit, la même signature de webhook, les mêmes
statuts et transitions. Ce qui change, c'est uniquement ce qui répond derrière
initiatePayinPayment — un PSP fictif au lieu d'un opérateur réel. Une
intégration qui fonctionne sur le sandbox fonctionne en production, à
l'exception des montants réellement débités.
Ce que cette documentation ne couvre pas
Elle décrit la surface accessible avec une clé d'API d'organisation. Les liens
de paiement, le flux SSE de suivi temps réel, la gestion des utilisateurs et
tout ce qui est préfixé /v1/admin/ sont des surfaces internes az54 : ils ne
font pas partie du contrat public et peuvent changer sans préavis. Le tableau
de bord marchand, lui, n'existe qu'en production (voir le Callout plus haut).