Simulating failures
Beyond the guaranteed-fail test numbers and cards, exercise these scenarios before going live:
- Decline — use a failing test number/card and confirm your UI shows a clear message and lets the customer retry.
- Customer abandons the flow — start a transaction, then close the tab before completing it. Confirm your reconciliation (callback or polling) eventually resolves it to a terminal, non-paid status instead of leaving it “pending” forever. See Transaction Statuses.
- Duplicate callback delivery — if you’re relying on the result callback, send the same result twice and confirm your handler doesn’t double-fulfill the order.
- Network failure mid-request — kill your connection after sending an
initiate/make-payment request but before reading the response. Confirm
you can recover using the
referenceNumber(if you have it) or by checking status before retrying, rather than blindly creating a second transaction.
Per-method failure modes
Section titled “Per-method failure modes”What a failure actually looks like differs by method — the message for a bad mobile-money number comes from the provider, while a bad card number is rejected by Pesepay’s own validation before it reaches anyone. Each method page lists its own: