Encaisser
Caisse, lien de paiement, transactions et export.
Caisse
L'écran Caisse sert à déclencher un encaissement à la main, typiquement face à un client : bouton d'encaissement, puis quatre étapes — numéro de téléphone, devise, opérateur, montant. Les étapes sans choix réel sont sautées (un seul opérateur disponible sur le corridor, une seule devise). À l'étape du montant, le champ facultatif Nom du payeur identifie qui paie ; il est repris dans l'écran Transactions et dans l'export CSV.
Le paiement lancé, la fenêtre suit son statut en direct :
| Ce que vous voyez | Ce que ça veut dire |
|---|---|
| Paiement en attente | La sollicitation est partie. Le client doit valider sur son combiné. |
| Validation du paiement + lien | Corridor en redirection : le client doit ouvrir le lien pour payer. Aucune validation passive n'est possible. |
| Traitement en cours | L'opérateur traite. Ne relancez pas. |
| Paiement réussi | Encaissé, le portefeuille est crédité. |
| Paiement échoué | Terminé et non payé. Relancer crée une nouvelle transaction. |
Chaque encaissement lancé ici est réel : le client reçoit une vraie sollicitation et son compte est vraiment débité. Il n'existe pas de mode test (Démarrage).
Les filtres de la Caisse ne portent pas sur tout l'historique
Le filtre Statut est appliqué par le serveur, sur l'ensemble des données. Les filtres numéro de téléphone, opérateur et pays sont appliqués dans le navigateur, sur la page affichée uniquement. Chercher un numéro qui se trouve trois pages plus loin ne renvoie rien.
Pour retrouver une transaction précise, utilisez l'écran Transactions, qui filtre par période côté serveur.
Le bandeau « En direct » signale l'état du rafraîchissement, pas un flux temps réel : la liste se recharge quand vous revenez sur l'écran ou via le bouton de rafraîchissement. Le suivi temps réel existe, mais dans la fenêtre d'un paiement en cours.
Lien de paiement
Votre organisation dispose d'un lien de paiement, permanent, sur l'écran Liens de paiement. Il n'y a pas de création de liens à la demande, ni de lien par montant : c'est une page de paiement unique où le client saisit ce qu'il doit. Il peut aussi y indiquer son nom, repris dans l'écran Transactions.
Deux réglages :
- Le slug personnalisé — la fin de l'URL. Minuscules, chiffres et tirets, de 3 à 100 caractères. Un slug déjà pris est refusé.
- Le QR code — téléchargeable en PDF A4 prêt à imprimer, avec les logos des opérateurs. Le pays est demandé au téléchargement, puisqu'il détermine les logos affichés.
Transactions
L'écran Transactions est le journal complet de l'organisation, pay-ins et pay-outs confondus. Les filtres statut, type et période (7 jours, 30 jours, ce mois, ou plage personnalisée) sont appliqués côté serveur.
La colonne Payeur affiche le nom saisi à l'encaissement (Caisse, lien de
paiement, ou payerName sur l'API). Elle reste vide sur les pay-outs et sur
les encaissements antérieurs au 30 septembre 2026 : les opérateurs ne
transmettent que le numéro de téléphone.
L'Export CSV exporte la sélection filtrée, pas seulement la page affichée : le fichier est reconstitué en parcourant les pages. Sur une large période, l'export prend donc quelques secondes. Il s'arrête à 10 000 lignes : au-delà, un message « Export tronqué » s'affiche et le fichier est incomplet — resserrez la période et exportez en plusieurs fois. Même limite sur l'écran Top-ups.
Le séparateur est le point-virgule et le fichier porte un BOM UTF-8 : il s'ouvre directement dans Excel en français, accents compris.
Sur la signification des statuts — et notamment sur le fait que cancelled est
un échec financier, pas une simple annulation — la référence est
Statuts de transaction.
Notifications webhook, dans la feuille de détail
Cliquer sur une ligne ouvre une feuille de détail qui porte la section Notifications webhook : une entrée par tentative d'envoi vers le serveur du marchand, avec son code HTTP, sa durée, et le motif quand elle a échoué. C'est le même journal que celui servi par l'API — sa lecture et son interprétation sont détaillées dans Réconciliation.
Un motif d'échec dit où chercher :
| Motif affiché | Où est le problème |
|---|---|
| « Votre serveur a répondu en erreur », « Aucune réponse reçue » | Chez le marchand : serveur ou réseau. |
| « Aucune URL de webhook configurée », « Aucun secret webhook actif », « URL bloquée » | Dans la configuration : webhookUrl de la transaction, secret de webhook. |
| « Devise de la transaction introuvable » | Chez az54 : à signaler au support. |
Les deux premières lignes se réessaient toutes seules, sauf « Aucune URL de webhook configurée » et « URL bloquée » — sans cible joignable, un rejeu ne changerait rien. « Aucune tentative de notification pour l'instant » signifie qu'aucun envoi n'a été tenté du tout.
Le bouton Renvoyer n'apparaît que sur une transaction terminale
(completed, failed, cancelled). Il programme une nouvelle notification —
avec sa propre suite de tentatives — plutôt qu'un envoi immédiat : le résultat
s'affiche dans ce même journal, après rafraîchissement.
Confirmations
Quand une transaction passe en réussie — pay-in comme pay-out — az54 envoie un email de reçu au compte qui l'a créée. Cet envoi n'est pas réglable depuis le tableau de bord.
Le payeur, lui, ne reçoit un email que s'il a laissé son adresse sur la page du lien de paiement. Un encaissement lancé depuis la Caisse ne capte pas d'email : le client n'en reçoit aucun.
Le reçu affichable, lui, est accessible depuis l'application après un paiement réussi. Sa version publique, partageable avec le payeur, est décrite dans Reçu public.
Un email n'est pas un canal d'intégration : si votre système doit réagir à un paiement, branchez le webhook sortant.