--- updatedAt: 2026-10-16T12:59:06.000Z agentTools: projectIndex: https://docs.infiniaweb.com/llms.txt --- # Testing in Sandbox Use magic values in the sandbox to simulate deposits, successful payouts, failures and other scenarios without moving real funds. The sandbox lets you exercise the full API without moving real funds. It runs at `https://app2test.infiniaweb.com/infinia_api`, and each product adds its own path, such as `/v1/accounts` or `/v2/payouts`. Sandbox credentials are separate from production credentials. See [Authentication](https://docs.infiniaweb.com/reference/authentication). To make testing deterministic, the sandbox supports **magic values**: specific amounts, labels and account details that trigger a predefined outcome. Each section on this page says what happens for a value it doesn't list. Magic values exist only in the sandbox. We recommend building your integration against the asynchronous scenarios on this page, with your webhook receiver, rather than relying on immediate completion. ## Magic values at a glance | Product | Endpoint | Field | Magic values | | :---------------------- | :------------------------------------------------------------------------------------------------------- | :--------------------------------- | :------------------------------------------------------------------- | | Accounts | [Create Account](https://docs.infiniaweb.com/reference/v1_0_create_account_) | `label` | `SIMULATE_STATUS_`, `SIMULATE_PROVISIONING_FLOW` | | Deposits | [\[Sandbox\] Create Deposit](https://docs.infiniaweb.com/reference/v1_7_create_deposit_) | `amount` | `101`, `102`, `103`, `104` | | Payins | [Create Payment](https://docs.infiniaweb.com/reference/v1_create_payment__post) | `amount` | `100`, `101`, `102` | | Payouts | [Create Payout](https://docs.infiniaweb.com/reference/v2_create_payout__post) | `amount` | `201`, `202`, `203` | | Internal transfers | [Make Internal Transfer](https://docs.infiniaweb.com/reference/v1_10_create_internal_transfer) | `source_amount` or `target_amount` | `302`, `303` | | Bank account validation | [Create Bank Account Validation](https://docs.infiniaweb.com/reference/v1_create_account_identity__post) | Account details | Per country, see [Bank account validation](#bank-account-validation) | | Identity validation | [Create Identity Validation](https://docs.infiniaweb.com/reference/v1_create_identity_validation__post) | Document number | See [Identity validation](#identity-validation) | ## Accounts Account creation is synchronous: the Create Account response returns the account's status. By default, a sandbox account is `ACTIVE` as soon as it's created. To test how your integration handles other statuses, set `label` to one of these values. The account is created directly in that status. | `label` | Resulting status | | :----------------------------- | :--------------- | | `SIMULATE_STATUS_PROVISIONING` | `PROVISIONING` | | `SIMULATE_STATUS_SUSPENDED` | `SUSPENDED` | | `SIMULATE_STATUS_CLOSED` | `CLOSED` | | `SIMULATE_STATUS_REJECTED` | `REJECTED` | | Any other label | `ACTIVE` | No status webhook is sent in these cases, because the account starts in that status instead of moving into it. To test a status change and your `status_callback_url` receiver, set `label` to `SIMULATE_PROVISIONING_FLOW`. The account is created as `PROVISIONING` and moves to `ACTIVE` a few seconds later, which sends the [Account status updated](https://docs.infiniaweb.com/reference/v1_webhook_account_status_updated) webhook. ## Deposits Use [\[Sandbox\] Create Deposit](https://docs.infiniaweb.com/reference/v1_7_create_deposit_) to simulate incoming funds on a virtual account. This endpoint exists only in the sandbox. | `amount` | Behavior | | :--------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------ | | `101` | Creates a deposit whose **refund fails**. Use it to test the [Refund Deposit](https://docs.infiniaweb.com/reference/v1_8_refund_deposit_) failure flow. | | `102` | Creates a deposit that includes **third-party payer data** with an individual document (CPF). | | `103` | Creates a deposit that includes **third-party payer data** with a business document (CNPJ). | | `104` | Creates a deposit that includes **crypto metadata**: sender address, network and transaction hash. | | Any other amount | Creates a standard completed deposit. | These amounts work on sandbox accounts in any country. The simulated payer document is always Brazilian (CPF or CNPJ). In production, the payer document reflects the sender's jurisdiction, for example an RFC in Mexico. ### Simulate a failed deposit refund When you refund a `101` deposit, the Refund Deposit response already returns the refund as `FAILED`, with a `failure_reason`. The refund's debit and the credit that returns it are created together, so the response includes both `debit_movement_id` and `bounce_movement_id`, and the balance is back where it was before the refund. The refund is also sent to your `callback_url` in the [Deposit refund updated](https://docs.infiniaweb.com/reference/v1_webhook_deposit_refund_updated) webhook. In production, a refund can also be reported as `SUCCESS` and change to `FAILED` later. Handle a `FAILED` webhook whatever status the create response returned. ## Payins Use these amounts with [Create Payment](https://docs.infiniaweb.com/reference/v1_create_payment__post) to simulate each payin outcome: | `amount` | Behavior | | :--------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `100` | The create response returns the payin as `COMPLETED`. | | `101` | The create response returns the payin as `AWAITING`. A few seconds later it moves to `COMPLETED`, the account is credited and the payin is sent to your `callbackUrl`. A refund of this payin **fails**. | | `102` | The payin **fails immediately**: the create response returns `ERROR`. | | Any other amount | The payin stays `AWAITING` until the payer acts. Open its `startUrl` in a browser and click **Complete Payment** to simulate the payment. The payin moves to `COMPLETED` and the webhook is sent. | Use `101` to test the asynchronous happy path, including the [Payin updated](https://docs.infiniaweb.com/reference/v1_webhook_payin_updated) webhook. You can also use it to test the [Refund Payment](https://docs.infiniaweb.com/reference/v1_6_refund_payment) failure flow. Wait for the payin to reach `COMPLETED` first, because only completed payins can be refunded. The Refund Payment response then returns the refund as `FAILED`. In production, a payin is always asynchronous. It's created as `AWAITING` and completes only when the payer's funds arrive, so the create response never returns `COMPLETED`. Build against `101` or the `startUrl` flow. ## Payouts In the sandbox, payouts run against a simulated rail. Use these amounts with [Create Payout](https://docs.infiniaweb.com/reference/v2_create_payout__post) to simulate each outcome: | `amount` | Behavior | | :--------------- | :------------------------------------------------------------------------------------ | | `201` | The payout is accepted as `IN_PROGRESS` and moves to `COMPLETED` a few seconds later. | | `202` | The payout is accepted as `IN_PROGRESS` and moves to `ERROR` a few seconds later. | | `203` | The payout **fails immediately**: the create response returns `ERROR`. | | Any other amount | The payout completes immediately: the create response returns `COMPLETED`. | When the payout reaches its final status, it's sent to your `callbackUrl` in the [Payout updated](https://docs.infiniaweb.com/reference/v2_webhook_payout_updated) webhook. Use `201` and `202` to test the asynchronous paths, including your webhook receiver. In production, a payout that is `IN_PROGRESS` can still fail, for example if the destination account is closed. Once a payout reaches `COMPLETED`, it can only move to `REFUNDED` or `PARTIALLY_REFUNDED`, on rails that support refunds. Build against `201` and `202` rather than relying on immediate completion. ## Internal transfers [Internal transfers](https://docs.infiniaweb.com/reference/v1_10_create_internal_transfer) succeed in the sandbox by default, so a successful transfer needs no magic value. Use these amounts in `source_amount` or `target_amount` to reach the failure paths, which the sandbox never produces on its own: | `source_amount` / `target_amount` | Behavior | | :-------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `302` | The transfer is accepted and the source account is **debited**. A few seconds later the rail rejects it: the transfer moves to `FAILED`, the debit is **refunded** to the source account, and the transfer is sent to your `callback_url`. | | `303` | The transfer **fails on the spot**: the create response returns `FAILED`. Anything already debited is refunded, so the balance ends where it started. | | Any other amount | The transfer follows the normal, successful flow. | The numbering parallels the payout amounts: `302` behaves like `202`, and `303` like `203`. Use `302` to test the whole failure flow: the balance drop, the refund and your webhook receiver. The rejection comes from the same simulated rail that would settle the transfer, so the failure runs through the real flow. A cross-currency transfer is quoted, and the funds are debited and then given back. That means: * **The source account must be funded.** If it can't cover the amount, the transfer fails with the usual insufficient-funds reason instead, as it would for any other amount. * **Both movements appear** in [List Account Movements](https://docs.infiniaweb.com/reference/v1_6_get_movements_). The debit has `operation.type` `INTERNAL_TRANSFER` and the refund `INTERNAL_TRANSFER_REFUND`, and both share the transfer's ID in `operation.operation_id`. The refund leaves the balance where it started. * **The refund can land a few seconds after** the transfer is reported `FAILED`. Read the balance after the refund movement appears, not immediately. These amounts apply only to transfers that settle over a rail. A transfer between two accounts held at the same underlying bank is a bookkeeping move that completes on its own, and it succeeds whatever the amount. ## Bank account validation In the sandbox, bank account validations return predefined responses, so you can test your request and response handling end to end without querying real registries. Use the values below to trigger each outcome. Unless a country's section says otherwise, any value not listed leaves the validation `IN_PROGRESS`. ### Argentina | Input | Value | Result | Returned data | | :------ | :------------------------ | :----------- | :----------------------------------------------------------------------------- | | `ALIAS` | `CALOR.ASPIRADORA.CUADRO` | `SUCCESSFUL` | POINCENOT S.A (LEGAL, CUIT `30714423033`), account `CC` in `ARS` | | `ALIAS` | `RELOJ.CAMARA.LADRILLO` | `ERROR` | Account not found | | `CBU` | `0170032450000643578149` | `SUCCESSFUL` | INNOVARTECH S.A (LEGAL, CUIT `30776436348`), account `CA` in `USD` | | `CBU` | `3220001805000046360015` | `SUCCESSFUL` | Díaz, Bruno (NATURAL, CUIT `20223385072`), account `CA` in `ARS` | | `CBU` | `3220001805000046360016` | `SUCCESSFUL` | Cooper Sheldon (NATURAL, CUIT `20313342042`), account `CA` in `ARS` | | `CBU` | `0170039420000033181593` | `ERROR` | Account not found | | `CVU` | `0000003100040000000015` | `SUCCESSFUL` | SOLUCIONES INTEGRALES S.R.L (LEGAL, CUIT `30888888882`), account `CC` in `ARS` | | `CVU` | `0000005700034525700013` | `ERROR` | Account not found | For `QR_CODE` validations, these payloads return `SUCCESSFUL`. **Any other QR code returns `ERROR`.** * Closed QR (holder JUAN CARLOS LOPEZ, CUIL `20123456789`, amount `5000`): ``` 00020101021243650016com.mercadolibre340130636f0f8b322-550d-3b3d-56b0-68d537d0997850150011273805090705204970053030325802AR5914John Doe 6004CABA6304ACF9 ``` * Open QR (holder MARIA GARCIA, CUIL `27123456789`, no amount): ``` 00020101021243650016com.mercadolibre340130636f0f4b421-310d-3b3d-46c1-48f542f0493850150011273805090705204970053030325802AR5914John Doe 6004CABA63041924 ``` ### Brazil | Input | Value | Result | Returned data | | :------------------------------------- | :---------------------------------------------------------------------------------------------------------------------- | :----------- | :------------------------------------------------------------------- | | `PIX_KEY` | `+5512575253111`, `anasilva@infiniaweb.com`, `12345678909`, `12345678000195`, or `4d8f085b-2d91-49de-b10c-3d0be5c59783` | `SUCCESSFUL` | ANA SILVA (NATURAL, CPF `12345678900`), account `SVGS` in `BRL` | | `PIX_KEY` | `+5587887815453` | `ERROR` | Account not found | | `ACCOUNT_NUMBER_WITH_BRANCH_NUMBER_BR` | Number `1323555513`, branch `00001`, ISPB `10853017`, type `CACC`, owner document `12345678901` | `SUCCESSFUL` | LUCAS OLIVEIRA (NATURAL, CPF `98765432101`), account `CACC` in `BRL` | | `ACCOUNT_NUMBER_WITH_BRANCH_NUMBER_BR` | Number `3252454544`, branch `00002`, ISPB `04866275`, type `SVGS`, owner document `42335453441` | `ERROR` | Account not found | For `QR_CODE` validations, these Pix QR codes return the result shown. **Any other Pix QR code returns `ERROR`**, the same result as a dynamic QR whose charge was already paid. * Static QR with amount, `SUCCESSFUL` (holder ANA SILVA, CPF `***456789**`, amount `150.0`, txid `INFINIASANDBOX01`): ``` 00020126450014br.gov.bcb.pix0123anasilva@infiniaweb.com5204000053039865406150.005802BR5909ANA SILVA6009SAO PAULO62200516INFINIASANDBOX016304BB9A ``` * Static QR without amount, `SUCCESSFUL` (holder LUCAS OLIVEIRA, CPF `***654321**`, no amount): ``` 00020126580014br.gov.bcb.pix01369b1c3f6e-2a47-4d1b-8c5e-7f0a2d3b4c5d5204000053039865802BR5914LUCAS OLIVEIRA6014RIO DE JANEIRO62070503***63047682 ``` * Dynamic QR, `SUCCESSFUL` (holder INFINIA SANDBOX LTDA, CNPJ `12345678000195`, amount `250.75`, expiration `2030-12-31T23:59:59Z`): ``` 00020101021226800014br.gov.bcb.pix2558pix.example.com/qr/v2/cob/4d8f085b2d9149deb10c3d0be5c597835204000053039865802BR5915INFINIA SANDBOX6009SAO PAULO62070503***63044C26 ``` * Static QR, `TEMPORARY_FAILURE`, to test your retries: ``` 00020126360014br.gov.bcb.pix0114+5511900000000520400005303986540510.005802BR5915INFINIA SANDBOX6009SAO PAULO62070503***63049B07 ``` * Recurring Pix (Pix Automático) QR, `ERROR`, because these QR codes aren't supported: ``` 00020101021226800014br.gov.bcb.pix2558pix.example.com/qr/v2/cob/7e2d4c1a9b3f4e5d8c6a0b1f2e3d4c5b5204000053039865802BR5915INFINIA SANDBOX6009SAO PAULO62070503***80800014br.gov.bcb.pix2558pix.example.com/qr/v2/rec/3a5b7c9d1e2f4a6b8c0d2e4f6a8b0c1d63048513 ``` A code that isn't a Pix QR code, for example one with a wrong checksum, returns `ERROR` with the `statusDescription` "The QR is not a valid Pix BR Code". As in production, a CPF comes partially masked in `holderDocument`. ### Colombia | Input | Value | Result | | :-------- | :---------- | :---------------------------------------------------------------------------- | | `ACH` | Any account | `SUCCESSFUL` immediately | | Bre-B key | Any key | Created as `IN_PROGRESS`, moves to `SUCCESSFUL` when you fetch the validation | ### Mexico | Input | Value | Result | Returned data | | :------ | :------------------- | :----------- | :--------------------------------------------------------- | | `CLABE` | `021060040538028986` | `SUCCESSFUL` | JUAN GARCIA (NATURAL, RFC `GATJ240309TE8`), currency `MXN` | | `CLABE` | `351483545522434846` | `ERROR` | Account not found | ### Peru | Input | Value | Result | Returned data | | :--------------- | :----------------------------------------------------------- | :----------- | :---------------------------------------------------------- | | `ACCOUNT_NUMBER` | Any CCI ending in `0001`, for example `00000100000000000001` | `SUCCESSFUL` | J\*\*E N\*V\*\*RO (NATURAL, DNI `4*****67`), currency `PEN` | | `ACCOUNT_NUMBER` | Any CCI ending in `0002`, for example `00000100000000000002` | `ERROR` | Account not found | | `PHONE_NUMBER` | `51987654321` | `SUCCESSFUL` | L\*\*S Q\*\*SP\* (NATURAL, DNI `0*****15`), currency `PEN` | | `PHONE_NUMBER` | `51900000000` | `ERROR` | Account not found | For `QR_CODE` validations, a QR code that credits a sandbox CCI (20 digits whose first three are `000`) returns `SUCCESSFUL` with the CCI, holder, currency, merchant category code and amount the QR carries. Its `type` is `closed` when the QR sets an amount and `open` when it doesn't. **Any other QR code returns `ERROR`.** For example, this open QR returns CCI `00000100000000420188`, holder INFINIA SANDBOX, currency `PEN` and merchant category code `4829`: ``` 00020101021126460018SANDBOX.INFINIA.PE0120000001000000004201885204482953036045802PE5915INFINIA SANDBOX6004LIMA62110507SANDBOX91230007FECVCTO0108203109226304DBEC ``` ### Uruguay | Input | Value | Result | Returned data | | :------------------ | :---------------------------------------- | :----------- | :-------------------------------- | | `ACCOUNT_NUMBER_UY` | Number `123456789000001`, bank code `001` | `SUCCESSFUL` | Masked owner name, currency `USD` | | `ACCOUNT_NUMBER_UY` | Number `123456789000002`, bank code `001` | `ERROR` | Account not found | | `PHONE_NUMBER` | `59891653354` | `SUCCESSFUL` | Masked owner name, currency `USD` | | `PHONE_NUMBER` | `59894054344` | `ERROR` | Account not found | ### United States | Input | Value | Result | | :------------- | :-------------- | :------------------------- | | Account number | `01323555555` | `ERROR`, account not found | | Account number | Any other value | `SUCCESSFUL` | ## Identity validation In the sandbox, identity validations also return predefined responses. Use these document numbers to get a `SUCCESSFUL` validation with predefined identity data. Any other document number results in a `FAILED` validation with an empty response, and `statusDescription` tells you why: the document isn't one of the test documents below, or the date of birth doesn't match. | Validation type | Document | Simulated result | | :-------------- | :--------------- | :-------------------------------------------------------- | | `AR_DNI` | `12345678` | Adult individual ("Eddie Brock", born 1982-12-28) | | `AR_DNI` | `05184530` | Underage individual ("Miles Morales", born 2015-08-14) | | `AR_CUIL` | `20343857398` | Adult individual ("Eddie Brock", born 1982-12-28) | | `AR_CUIL` | `27051845301` | Underage individual ("Miles Morales", born 2015-08-14) | | `AR_CUIT` | `20343857398` | Business ("Roxxon Corporation") | | `BR_CPF` | `12345678909` | Adult individual ("Robert Bruce Banner", born 1969-12-18) | | `BR_CNPJ` | `12345678901230` | Business ("Stark Industries") | Identity validations resolve synchronously in the sandbox: the final status is available immediately, and if you provide a `callbackUrl`, the callback is sent right away. ### Date of birth for CPF validations `BR_CPF` validations accept an optional `dateOfBirth` (`YYYY-MM-DD`). In production, the registry checks the CPF together with the date of birth, and a mismatch results in `FAILED`. The sandbox reproduces that check for the test CPF: | `cpf` | `dateOfBirth` | Result | | :------------ | :------------- | :---------------------------------------------------------------------------------------- | | `12345678909` | Omitted | `SUCCESSFUL` | | `12345678909` | `1969-12-18` | `SUCCESSFUL` | | `12345678909` | Any other date | `FAILED`, and `statusDescription` reports that the date of birth doesn't match | | Any other CPF | Any value | `FAILED`, and `statusDescription` reports that the document isn't a sandbox test document | Real CPFs are never looked up in the sandbox, so a document that is valid in production still returns `FAILED` here. Use the test CPF above to exercise the successful flow.