Aller au contenu

Déclencher des événements

Produisez un véritable paiement dans la sandbox et les événements qui le suivent.

wajub trigger ne fabrique pas de payload. La commande appelle l'API de la sandbox comme votre code, avec le numéro de test qui produit le résultat demandé, puis laisse la plateforme émettre elle-même les événements. Votre handler reçoit donc exactement ce qu'aurait produit un véritable payeur.

Une commande, un paiement complet
$ wajub trigger payment.succeeded

Triggering payment.succeeded
 created payment trx_test_VPRKcDWn0pi29ScaQL9B
 dispatched cm.mtn charge (+237670000000)
 payment trx_test_VPRKcDWn0pi29ScaQL9B is succeeded

Le numéro composé révèle le mécanisme : +237670000000 est le préfixe MTN Cameroun de la sandbox, suivi du suffixe de réussite. Pour un échec, la commande utilise le suffixe d'échec.

La même commande avec l'autre résultat
$ wajub trigger payment.failed --amount 2500

Triggering payment.failed
 created payment trx_test_PR8mmBq5bfkxqGcJRtP5
 dispatched cm.mtn charge (+237670000002)
 payment trx_test_PR8mmBq5bfkxqGcJRtP5 is failed

Les huit événements

wajub trigger --list
Triggerable events:
  customer.created     Create a customer
  customer.updated     Create then update a customer
  payment.cancelled    Create and cancel a payment (mobile money canceled)
  payment.created      Create a payment and leave it unpaid
  payment.failed       Create and fail a payment (mobile money failure)
  payment.succeeded    Create and complete a payment (mobile money success)
  refund.failed        Complete a payment whose refund deterministically fails
  refund.succeeded     Complete a payment then refund it (refund succeeds)

Huit arguments produisent bien plus de huit événements, car chacun exécute un véritable parcours.

DéclencheurÉvénements reçus par votre endpoint, dans l'ordre
payment.createdpayment.created
payment.failedpayment.created, payment.processing, payment.failed
payment.succeededpayment.created, payment.processing, payment.succeeded, balance.updated, fee.charged
refund.succeededLes cinq précédents, puis refund.created, refund.succeeded, balance.updated

Le tout premier déclenchement sur un compte émet également customer.created, car la CLI crée le client CLI Trigger qu'elle réutilise ensuite.

La chaîne est l'enseignement principal, pas un effet secondaire

Un véritable paiement se comporte de la même manière. Si votre handler traite uniquement payment.succeeded, vous découvrez ici que quatre autres types arrivent déjà sans être traités, et que fee.charged manquait dans votre registre.

Adapter la ressource créée

OptionValeur par défautEffet
--amount5000Montant de la ressource créée
--currencyXAFDevise
--channelcm.mtnRéseau à débiter
--phoneDéduitRemplace le numéro du payeur. Option avancée qui détermine le résultat
-d, --dataChamp key=value supplémentaire sur la ressource, répétable
--listAffiche la liste ci-dessus et s'arrête
Se rapprocher de votre propre trafic
wajub trigger payment.succeeded --amount 250000 --currency XOF --channel ci.orange
wajub trigger customer.created -d name="Boutique Akwa" -d email=contact@example.com
wajub trigger payment.succeeded -d reference=order-4172 -d description="Order #4172"

L'option -d reference=order-4172 rend le test réaliste. Votre handler retrouve la commande comme en production, sans traitement spécial pour un faux paiement.

Événements impossibles à déclencher directement

La liste est volontairement courte. Un événement y figure uniquement si la CLI peut le produire sans configuration supplémentaire. Produisez les autres comme dans votre propre code.

ÉvénementMéthode
transfer.*wajub beneficiaries create, puis wajub transfers create
dispute.*Les litiges sont ouverts par l'acquéreur, pas par vous
invoice.*wajub invoices create, puis send ou mark-paid
link.*wajub links create
account.*wajub accounts create, pour les plateformes Sync
payment.expiredLaissez un paiement pending atteindre la fin de sa période
payment.split.*Envoyez split_count sur un paiement dans la sandbox

Utiliser volontairement la sandbox

wajub trigger écrit dans l'API avec le profil actif. Un mauvais profil crée un véritable client sur un véritable compte.

Soyez explicite lorsque c'est important
wajub config                                  # which profile is default?
wajub trigger payment.succeeded --profile sandbox

La boucle

Deux terminaux
# 1
wajub listen --forward-to localhost:3000/webhooks/wajub

# 2
wajub trigger payment.succeeded
wajub trigger payment.failed
wajub trigger refund.succeeded

Trois commandes couvrent les cas souvent mal gérés : la réussite, l'échec qui doit libérer la réservation et le remboursement qui ne doit pas être pris pour un nouveau paiement.

Que pensez-vous de ce contenu ?