Payment API testing: a checklist for the whole journey
A payment API test should follow the journey from permission to the recorded outcome. Start with a known synthetic account and recipient, then test expired consent, changed details, uncertain responses and repeat delivery. ZILLQ provides an open banking sandbox in which to explore those mechanics.
Scope: A reusable integration checklist. Expected behaviors must be adapted to the provider contract. ZILLQ uses synthetic accounts and funds; this page is not a report that its current build passes every case.
Start with one traceable payment
- Enter the public sandbox.Open the portal and use the public demo-access instructions on the landing page. The environment is shared; keep every detail synthetic.
- Inspect the permission.Look at the consent, its scope and current status. Distinguish account-data access from authority to initiate a payment.
- Prepare a known payment.Use a demo account and recipient, record the amount and currency, and inspect the payee-check result before initiation.
- Follow the result.Keep the payment reference. Compare payment detail, history and the relevant account records instead of treating a redirect as the final outcome.
For API exploration, use the platform’s public OpenAPI contract as the route and field reference. These checklist terms are conceptual; they do not invent endpoints or imply every provider uses the same status codes.
What to include in a payment test plan
| Boundary | Change one fact | Evidence to inspect |
|---|---|---|
| Permission | Use an expired or revoked consent. | The service refuses the unauthorized action without initiating a payment. |
| Owner isolation | Use a different synthetic user for the same resource ID. | Account and payment data remain restricted to the authorized identity. |
| Recipient | Change the destination after a payee check. | The old result is not silently applied to new payment details. |
| Authentication | Abandon, fail or repeat the bank step. | The payment state and user-facing next action remain accurate. |
| Retry | Lose the response after submission. | The same logical payment can be investigated without creating a duplicate. |
| Event handling | Deliver the same event twice or deliver an older one later. | One outcome, one fulfilment action, and a valid state transition. |
| Reconciliation | Compare the payment with account records. | References, amount, currency and destination agree. |
Keep a successful control case alongside each failure case. A test that always refuses payment is not evidence that the intended flow works. Record the evaluated build and actual result, including unsupported and untested cases.
How should retries and webhooks behave?
A timeout leaves uncertainty: the provider may already have accepted the instruction. Preserve the original reference and follow the documented status and retry mechanism. Idempotency keys have scope, payload-matching and retention rules; do not assume an arbitrary repeated key works across users or indefinitely.
To compare a same-key retry with a new-key retry step by step, use the payment retry simulator. It plays seven synthetic scenarios, including duplicate and late webhooks, in your browser.
For a real example of a provider-specific lifecycle, TrueLayer distinguishes authorization, execution and settlement. Its webhook reference describes corresponding events. Map your tests to the provider you integrate with; do not import these labels as universal requirements.
The pending-payment guide gives an investigation sequence. Agent spending adds another constraint: an unresolved payment may need to retain its budget reservation until its result is reconciled.
Include identity and authorization in the same review
Test credentials as part of the boundary: wrong audience, insufficient privilege, expired access and an identity that does not own the resource. The IETF’s OAuth security guidance provides the standards context for token protection and constrained access.
Consent, Strong Customer Authentication and a software agent’s mandate answer different questions. Use the worked consent and SCA comparison to define what each test is meant to prove. If your interface shows “approved,” make the approved action visible.
For automated purchasing, extend the plan with the 16 downloadable agent mandate cases. They introduce budget limits, revocation, concurrent spending and replay without assuming a particular bank API.
A compact test evidence record
Capture the environment and build; fixture identifiers; expected permission; amount and currency; internal and provider references; expected result; actual result; and the observed account or status evidence. Include the observation time so later asynchronous updates can be understood.
Keep real credentials and unnecessary customer information out of screenshots and tickets. ZILLQ’s shared sandbox is for synthetic exploration. Passing a demonstration is a starting point for evaluation; production approval needs the target provider’s behavior and the controls appropriate to the actual service.
Bring the question into ZILLQ.
The public portal connects payment consent, synthetic transfers, recipient checks and recorded outcomes. The platform also includes agent mandate mechanisms and EUDI wallet emulation. Use synthetic data and inspect what the current build actually supports.
Open the payments sandbox → · Explore the platform · Investor and partner brief