Testing in the sandbox

Scenarios, simulations, the payer's bank, time travel, chaos options and the developer portal's tools.

The developer portal#

Tool	What it does
Scenarios	Seventeen complete flows run against your workspace through the real API, consumer and merchant. Each step shows the request and response
Records	Every record, shown on its state machine, with its webhooks, ledger postings and RTP message timeline
Events and Webhooks	Every event and delivery attempt, resend, sample events, a signature checker, a tampered-event drill and a built-in inbox
Request logs	The last 2,000 requests with full bodies, and copy as curl
Compliance and rail desk	Approve or reject onboarding reviews and bank links, advance disputes, and answer Requests for Payment as the payer's bank
Time travel	Move your workspace's clock forward
API explorer	Send any request to your workspace without handling secrets
Certification	Evidence of your integration's progress towards go-live

Finish hosted screens without a customer#

In automated tests, complete a hosted session with one call. The outcome, records and webhooks are the same as when a customer completes the screens.

Shell

curl -X POST https://sandbox.a2ainstapay.com/v1/sandbox/sessions/ses_.../complete \
  -H "Authorization: Bearer $A2A_ACCESS_TOKEN" -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" -d '{"outcome":"in_review"}'

outcome applies to onboarding (approved, in_review or rejected). Send {"cancel": true} to test a customer who leaves. This endpoint exists only in the sandbox.

Simulate events#

POST /v1/sandbox/simulate/{event} with {"object_id": "..."} moves a record as A2A InstaPay's operations or the network would: approve a review, settle or fail a load, complete a payment, suspend an account, advance a dispute or produce a statement. The list is in Test data.

Answer as the payer's bank#

In the portal settings, set the rail mode to manual. Requests for Payment then wait at the payer's bank until you answer them at the rail desk:

Answer	Result
Approve and pay in full	`settled` or `completed`
Customer declines	`failed` with `declined_by_customer`
Let the request expire	`failed` with `request_expired`
Payer's bank rejects	`failed` with `rejected_by_bank`
No answer	The record stays `processing` and becomes an exception for operations

In automatic mode, the cents of the amount decide the answer; see Test data.

Move the clock#

Each workspace has its own clock. Moving it forward runs everything due in order, each at its own time: webhook retries, session and payment request expiry, PIN unlocks, Regulation E deadlines, dormancy after 365 days and month-end statements. The clock moves forward only; resetting the workspace returns it to real time.

Chaos options#

Turn on duplicate webhooks, out-of-order webhooks, a failed first delivery of every event, or a percentage of 503 errors from the API, to prove your integration copes.

Test from a merchant's side only#

If you build only for merchants, open a payment request's record in the portal and choose Pay as a test payer: a sandbox customer pays it, and your merchant receives the payment and its webhooks.

Reset#

Settings has a reset that removes every record, event, log and scheduled job in the workspace and returns its clock to real time. Credentials and settings stay.

Questions about this page? Contact developer support.