Skip to main content
Toutes les routes de ce groupe nécessitent le header Authorization: Bearer sk_... et un scope de clé API PAYIN ou BOTH (voir Format des réponses pour l’enveloppe de réponse et Idempotence pour le header Idempotency-Key).

​
Vue d’ensemble

SasPay propose deux façons d’encaisser, selon que vous connaissez déjà le réseau et le numéro du client ou non :
Softpay vs checkout hébergé — le softpay pousse directement une demande de paiement (USSD/notification) sur le téléphone du client à partir du réseau et du numéro que vous fournissez : idéal quand votre propre interface a déjà collecté ces informations. Le checkout hébergé génère une page de paiement SasPay (checkout_url) où c’est le client qui choisit son réseau et saisit son numéro — idéal pour un lien envoyé par email/SMS ou un bouton “Payer” qui redirige vers nous.

​
Softpay (push direct)

​
Checkout hébergé

​
Commun aux deux

Pour l’historique complet, les filtres, l’export CSV et la facture PDF, voir Transactions — softpay et checkout hébergé produisent tous les deux une Transaction classique (flow_direction: "INBOUND").

​
OTP pré-paiement

Certains réseaux (Orange Money Côte d’Ivoire et Burkina Faso) exigent l’inverse : le client doit obtenir un code avant même votre appel API, en composant un code USSD sur son téléphone (#144*82# en Côte d’Ivoire, un autre au Burkina). Ce code se transmet dans le champ otp de POST /payments/softpay/. Pour savoir à l’avance si le réseau visé l’exige — et afficher la bonne consigne USSD à votre client avant qu’il ne paie — consultez otp_required/otp_instructions dans GET /pricing/my-rates/.
Sans ce code sur un réseau qui l’exige, la requête échoue avec 422 prepayment_otp_missing plutôt que de pousser une demande vouée à l’échec sur le téléphone du client.
Sur le checkout hébergé, cette étape est gérée automatiquement par la page de paiement SasPay — vous n’avez rien à transmettre vous-même.

​
Confirmation OTP

Certains réseaux (par exemple Wizall au Sénégal ou Coris au Bénin) exigent l’inverse chronologique : après le push initial, le client reçoit un code qu’il doit vous communiquer, à transmettre ensuite via POST /payments/{payment_id}/confirm-otp/. La plupart des réseaux mobile money n’ont besoin ni de l’un ni de l’autre — le client valide directement sur son téléphone.
Les deux mécanismes ci-dessus sont indépendants et ne concernent jamais le même réseau : l’un se fournit avant le paiement (otp sur la requête initiale), l’autre après (confirm-otp, une fois le paiement déjà poussé).
POST /checkout-sessions/ ne prend pas en charge Idempotency-Key — un double-clic ou un retry réseau peut y créer deux sessions distinctes (sans conséquence financière : une session ne débite rien tant qu’elle n’est pas payée). Sur softpay, retry et payout, la clé est prise en charge et vivement recommandée.

​
Cycle de vie d’un paiement

Un paiement FAILED peut être rejoué sans créer de nouvelle transaction via POST /payments/{payment_id}/retry/.