Test prepaid order failures before going live
Make the test supplier accept an order and then drop the reply. Can an operator find the first order without buying airtime again? Test that alongside definite rejections and pending outcomes before release. Check the original reference whenever the result is unclear.
| Scenario | Expected handling |
|---|---|
| Validation rejection | Correct input, then submit new approved request |
| Definite supplier failure | Record failure and follow approved resubmission process |
| Timeout after submit | Query using original reference |
| Pending status | Wait and reconcile according to supplier guidance |
| Duplicate reference | Confirm documented supplier behaviour |
By Freepaid · Published
Set up the test environment
Give each test a unique made-up approval reference and write down how many purchase requests you expect. Use a sandbox or a stub that can accept a purchase and drop its reply. Check what your app saves, what the operator sees and what finance gets. If the supplier offers no suitable sandbox, test your app against the stub and confirm separately how the live status lookup works.
| Test case | Observable result | Evidence to keep |
|---|---|---|
| The application rejects a malformed recipient before submitting | The purchase endpoint receives zero requests | Validation result and request count |
| The supplier accepts the order, then the client loses the response | The original attempt remains visible for investigation. The purchase endpoint receives one request | Request log, original reference and unresolved record |
| The status route temporarily fails | The case stays open with the last trusted result and a next check | Status check timestamps and escalation owner |
| The original purchase later confirms delivery | The existing order updates once and the finance export shows one completed purchase | Final status, supplier identifier and export row |
| A second click submits the same approval while the first is unresolved | The application preserves one purchase attempt for that approval | Request count and audit record |
| The statement shows a debit that cannot be matched to the order | Finance sees an unresolved exception with an owner | Statement entry, amount and original reference |
Rehearse the missing response
Try TEST-2026-001. Tell the stub to accept the purchase and drop the reply. Reload the page and see whether the operator can still find the attempt. Check that the purchase log contains one request. Then have the stub confirm delivery and check that the app updates the same order and exports one completed purchase.
Test with the identifiers your supplier returns. SIMcloud’s Airtime API returns a request_id when it queues an accepted request, and its status lookup uses that ID. Ask how to recover when the reply disappears before you receive it. Use your own reference as an idempotency key only if the supplier documents that it accepts one. SIMcloud Airtime API
Have operations and finance run the same test
Keep the environment, date, expected result, actual result and reviewer for each test. Mask recipient details and leave live credentials and voucher PINs out of captures. Ask an operator and a finance reviewer to run one case together. The operator should find the original order without placing another. Finance should be able to tell whether the statement includes it. Record who acts if the result stays unclear.
Keep a failing case open until the team can reproduce the corrected behaviour. If a pending order disappears from the review queue or a duplicate enters the supplier export, hold the release and fix that path. Keep the test record with the release so the team can repeat it when an interface, retry policy or status mapping changes.