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").

​
Confirmation OTP

Certains réseaux (par exemple Wizall au Sénégal ou Coris au Bénin) exigent une deuxième étape : 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’en ont pas besoin — le client valide directement sur son téléphone.
POST /checkout-sessions/ n’exige pas de header Idempotency-Key (dette technique connue) — un double-clic côté client ou un retry réseau non protégé peut créer deux sessions de checkout distinctes. Softpay, retry et payout, eux, exigent bien cette clé.

​
Cycle de vie d’un paiement

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