Le statut du paiement et celui de la commande sont liés mais distincts
La passerelle décrit le paiement ; votre application détermine le sort de la commande. Ne livrez jamais à partir d’un webhook non vérifié, ne faites pas régresser un état après un événement récent et n’acceptez pas un montant exceptionnel comme payé sans politique explicite.
Aucune requête, webhook, transaction, remboursement ou modification de commande n’est envoyé à OxaPay. Les données restent dans le navigateur ; seule la réponse API réelle fait foi.
Il explique les transitions probables et actions commerçant ; il ne crée pas de paiement, ne contacte pas d’API, ne vérifie aucune transaction et ne remplace pas Payment Information.
Utiliser le simulateur de statuts de paiement
Ce simulateur aide commerçants et développeurs à comprendre comment un événement de paiement agit sur une commande. Choisissez un scénario ou réglez montant, expiration, confirmations, méthode de paiement et comportement des webhooks. C’est un modèle pédagogique : aucune transaction réelle n’est contrôlée et aucun appel à OxaPay n’est envoyé.
Statut de paiement et statut de commande sont distincts
La passerelle indique l’état du paiement ; le commerçant décide séparément de maintenir la commande en attente, de livrer ou de vérifier. Un transfert détecté n’est pas un paiement accepté. Une livraison irréversible exige un état final vérifié et autorisé. Des webhooks en double ou désordonnés ne doivent jamais déclencher une seconde livraison.
Sous-paiements et délais
L’écart admissible dépend du montant demandé et de la tolérance configurée. Un sous-paiement important, un virement tardif ou un flux inhabituel requiert une politique explicite et non une livraison automatique. Les dépôts sur adresse statique doivent être associés au bon client et à la bonne transaction. Zéro confirmation ne remplace pas un état final attesté par la passerelle.
Livraison des webhooks et reprise
Les scénarios couvrent les doublons, un HMAC incorrect, les événements hors ordre, le premier essai échoué et les tentatives épuisées. Vérifiez la signature sur le corps brut, associez la référence de commande, appliquez les changements de façon idempotente et consultez Payment Information ou Payment History en cas de doute. Le JSON présenté n’est qu’un exemple.
Limites du modèle
Les commandes, empreintes, horodatages et données sont fictifs. Les statuts, limites et délais de reprise OxaPay peuvent évoluer : vérifiez toujours la documentation à jour avant mise en production. Aucune somme, aucun remboursement, webhook réel ou secret n’est transmis.
Statuts de paiement OxaPay documentés
L’écart admissible dépend du montant demandé et de la tolérance configurée. Un sous-paiement important, un virement tardif ou un flux inhabituel requiert une politique explicite et non une livraison automatique. Les dépôts sur adresse statique doivent être associés au bon client et à la bonne transaction. Zéro confirmation ne remplace pas un état final attesté par la passerelle.
new- Facture créée ; devise non choisie.
waiting- Devise choisie ; paiement attendu.
paying- Une tentative de paiement ou une transaction est en cours.
paid- La facture a été réglée.
manual_accept- Le commerçant a accepté manuellement la facture.
underpaid- Le paiement partiel ne couvre pas la facture.
refunding- Un remboursement a été lancé.
refunded- Le paiement a été remboursé.
expired- La facture a expiré sans paiement accepté.
Documentation actuelle OxaPay
Consultez les statuts, paramètres de facture, recherche de paiement et webhooks.