Sandbox Magic Values
Sandbox reserves a few values that trigger a specific outcome on purpose, so you can exercise the failure paths your integration has to handle without waiting for one to happen in production.
The values below are generated from the same table the sandbox honours at runtime, so they cannot drift from what the environment actually does.
Scenarios
| Scenario | Trigger | You observe |
|---|---|---|
| PIX pay-out to a blocked institution | 00000000-0000-4000-8000-000099999999 | PARTIAL-FAILED |
PIX pay-out to a blocked institution
Pay out to a beneficiary whose bank is on the pay-out deny-list. Use it to exercise how your integration handles a delivery that fails after the ticket was paid.
| PIX key | 00000000-0000-4000-8000-000099999999 |
| Resolves to ISPB | 99999999 |
| Ticket status | PARTIAL-FAILED |
| Failure reason contains | receiver bank institution is blocked |
How to run it
- Register a BRL beneficiary using the PIX key above.
- Create a ticket paying out to that beneficiary.
- Wait for the delivery webhook, then read the ticket.
A beneficiary registered with bank account details instead of a PIX key never goes through key resolution, so the magic value is never seen and the pay-out behaves normally.
You can confirm the institution is blocked for your account before you spend a ticket on it:
curl "https://api.sandbox.avenia.io:10952/v2/account/bank-accounts/brl/blacklisted-ispbs" \
-H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
The response lists 99999999. It is a reserved code that belongs to no real
institution, which is why it has no bank name.
Simulation limits per currency
Sandbox also auto-settles deposits up to a cap that differs per currency, and uses mock account details for some rails. Those are documented with the flow they belong to: