az54 API docs

Sur le serveur Production, déclenche une sollicitation réelle (push, USSD ou SMS) vers le numéro du payeur ; sur Sandbox, l'issue est pilotée par les deux derniers chiffres du numéro (cf. [numéros de test](/docs/numeros-de-test)). La réponse `200` signifie « demande acceptée », jamais « payé » : l'issue est poussée par le webhook sortant, et se relit sur `GET /v1/transactions/by-id/{transactionId}` avec l'`id` renvoyé ici — cf. [réconciliation](/docs/reconciliation).

Authorization

AuthorizationBearer <token>

Clé d'API de l'organisation, envoyée en Authorization: Bearer sk_live_… (sk_test_… sur le serveur Sandbox). Il n'existe aucun header X-API-Key.

In: header

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

orderId*string

Match^[A-Za-z0-9_-]+$

Length1 <= length <= 100

amount*number

Montant en unité majeure de currencyCode (100 = 100 XOF, pas 1 XOF). Le nombre de décimales admis est le decimalPlaces de la devise, lisible sur /v1/corridors/available ; au-delà, 400 VALIDATION_ERROR.

Range0 < value

phoneNumber*string

Numéro du payeur au format E.164, indicatif compris.

Match^\+[1-9]\d{8,14}$

Length1 <= length

currencyCode*string

Length1 <= length

operatorCode?string

À n'envoyer que pour choisir Wave. Wave n'est pas un opérateur télécom : son compte se superpose à celui du telco, un même numéro peut donc porter les deux — le préfixe ne suffit pas à trancher. Une seule valeur a un effet : wave, sensible à la casse, qui force le rail Wave. Pour tous les autres opérateurs, le préfixe du numéro décide et la valeur envoyée est ignorée en silence. Sur le pay-in, wave exige redirectUrls.

otp?string

Code généré par le payeur sur son combiné, requis par les corridors en workflow pre_authorized. Aucun format n'est garanti. Le corridor payant n'étant résolu qu'au pay-in, le protocole est de poster sans otp et de réagir au 422 OTP_REQUIRED.

redirectUrls?

Où renvoyer le payeur après la page du PSP. Obligatoire pour les corridors en workflow redirect_url et pour operatorCode: "wave" ; sinon 422 REDIRECT_URLS_REQUIRED. Seuls les schémas http:// et https:// sont acceptés.

description?string

Lengthlength <= 500

webhookUrl?string

Destination de la notification sortante. Vérifiée à l'émission, pas ici : https en production, hôte résolvant vers une IP publique unicast, aucune redirection suivie, une seule tentative sans retry. Une URL invalide donne donc un pay-in qui réussit et une notification perdue en silence.

Formaturi

Lengthlength <= 2048

customerId?string

Référence libre côté marchand. Stockée, jamais restituée par l'API.

Lengthlength <= 100

payerName?string

Nom de la personne ou de l'entité qui paie, 100 caractères au plus, espaces de bord retirés ; vide, il est ignoré. Restitué par GET /v1/transactions ; le PSP ne le reçoit pas.

Lengthlength <= 100

Response Body

`application/json`

curl -X POST "https://example.com/v1/pay-in" \  -H "Content-Type: application/json" \  -d '{    "orderId": "string",    "amount": 100,    "phoneNumber": "string",    "currencyCode": "string"  }'

{  "success": true,  "data": {    "orderId": "string",    "transactionId": "75906707-8c31-479c-b354-aa805c4cefbc",    "status": "string",    "message": "string",    "failureCategory": "INSUFFICIENT_FUNDS",    "failureReason": "string",    "failureCode": "string"  }}

Encaisser un paiement mobile money

Authorization

Request Body

Response Body

200application/json

400application/json

401application/json

403application/json

409application/json

413application/json

422application/json

429application/json

502application/json

`application/json`

`application/json`

`application/json`

`application/json`

`application/json`

`application/json`

`application/json`

`application/json`

`application/json`