How to test critical actions and token validations
Some API operations require a critical action token as an additional security confirmation. In addition, some account flows, such as activation, email confirmation, and registration of an SMS Token or App Token device, request a code sent by email or SMS.
In the Sandbox, use a default token to validate these flows before implementing the handling used in Production, without depending on receiving the real code.
By the end of this guide, you will have validated an operation protected by a critical action, the account validation flows, and how your application handles the result.
When to use it
Use this flow when testing operations that request additional confirmation, such as:
- transfers;
- withdrawals;
- sensitive financial transactions;
- other operations protected by a critical action.
Whether the token is required depends on the operation, the account settings, and the endpoint used.
Also use the default token in the account validation flows in the Sandbox:
| Flow | Where to enter the token |
|---|---|
| Account activation | In place of the activation code |
| Email confirmation | In place of the code sent by email |
| Registration of a new SMS Token device | In place of the code sent by SMS |
| Change of the SMS Token phone number | In place of the code sent to the old number and to the new number |
| App Token validation | In place of the code generated by the app |
Test token
When the operation or flow requires a token or validation code in the Sandbox, enter:
000000The
000000token works exclusively in the Sandbox.It must not be used or stored as a Production credential. In Production, validations still require the real code or token.
How it works
%%{init: {"flowchart": {"nodeSpacing": 28,"rankSpacing": 32,"diagramPadding": 8,"padding": 10}}}%%
flowchart TD
A["Start the operation"] --> B["API requests critical action"]
B --> C["Send the 000000 token"]
C --> D["Process the operation"]
D --> E["Validate the result"]
classDef inicio fill:#DBEAFE,stroke:#2563EB,color:#1E3A8A,stroke-width:3px,font-size:17px
classDef processo fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E,stroke-width:2px,font-size:17px
classDef sucesso fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:3px,font-size:17px
class A inicio
class B,C,D processo
class E sucesso
linkStyle default stroke:#94A3B8,stroke-width:2px
How the token is sent depends on the endpoint. See the operation's reference to identify the field or step in which it must be provided.
1. Start the operation
Send the request using a Sandbox API key.
If the operation is protected, the API will indicate that additional validation is required.
2. Provide the token
Repeat or continue the operation according to the flow documented for the endpoint, using the token:
0000003. Validate the result
After sending the token, confirm that:
- the request was processed;
- the operation status was updated;
- the returned ID was stored;
- the related Webhooks were received;
- your application handled the result correctly.
The token only confirms the critical action or code validation step.
The operation is still subject to the API's other validations, such as balance, recipient data, limits, and required fields.
Validation example
%%{init: {"flowchart": {"nodeSpacing": 28,"rankSpacing": 32,"diagramPadding": 8,"padding": 10}}}%%
flowchart TD
A["Add balance"] --> B["Create transfer"]
B --> C["Enter 000000"]
C --> D["Run the operation"]
D --> E["Validate status and Webhooks"]
classDef inicio fill:#DBEAFE,stroke:#2563EB,color:#1E3A8A,stroke-width:3px,font-size:17px
classDef processo fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E,stroke-width:2px,font-size:17px
classDef sucesso fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:3px,font-size:17px
class A inicio
class B,C,D processo
class E sucesso
linkStyle default stroke:#94A3B8,stroke-width:2px
Also test the application's behavior when:
- the token is not provided;
- the token provided is invalid;
- the operation returns another error;
- the Webhook is received more than once.
Account validations in the Sandbox
In the account activation, email confirmation, and SMS Token or App Token device registration or change flows, enter 000000 in the validation code field.
%%{init: {"flowchart": {"nodeSpacing": 28,"rankSpacing": 32,"diagramPadding": 8,"padding": 10}}}%%
flowchart TD
A["Start the validation"] --> B["Enter 000000 in place of the received code"]
B --> C["Confirm the validation"]
C --> D["Check the account or device status"]
classDef inicio fill:#DBEAFE,stroke:#2563EB,color:#1E3A8A,stroke-width:3px,font-size:17px
classDef processo fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E,stroke-width:2px,font-size:17px
classDef sucesso fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:3px,font-size:17px
class A inicio
class B,C processo
class D sucesso
linkStyle default stroke:#94A3B8,stroke-width:2px
When changing the phone number linked to the SMS Token, the 000000 token is accepted for validating both the old number and the new number.
With the default token, you don't need to wait for the code by email or SMS to complete these flows in the Sandbox.
If the operation is not completed
Check that:
- the request was sent to the Sandbox;
- the API key belongs to the same environment;
- the token was provided in the expected place;
- the account has sufficient balance;
- the required fields are correct;
- the operation is available for the account;
- the returned error is actually related to the critical action or code validation.
Disabling in the Sandbox
In specific scenarios, the token requirement can be disabled for transfer tests in the Sandbox.
Validate the flow with the token enabled first.
Disabling it is intended only for specific tests and does not represent the recommended configuration for Production.
To request the change, see the Contact us page.
Before going to Production
Confirm that your integration:
- does not use the
000000token; - correctly handles the critical action request;
- correctly handles the real activation, email confirmation, and SMS Token or App Token codes;
- protects the tokens and credentials received;
- records operation attempts and results;
- restricts access to financial operations;
- uses additional security mechanisms when applicable.
Complementary mechanisms include:
- IP whitelist;
- withdrawal validation via Webhook;
- internal approval controls;
- operation logging and monitoring.
Related content
Updated 18 days ago
