Skip to main content
Besides validating input on your side, you should see how Trio behaves when a deposit is refused: a payer with an invalid CPF or CNPJ, a legal entity paying a code meant for individuals, a repeated payment of the same QR code. This guide turns on the bank account rules that reject or refund such deposits and pays a QR code against them.

​
Before you start

The simulation uses the two-account setup from Simulate a successful deposit: one bank account generates the QR code and the other pays it. Read that guide first if you have not set the accounts up.

​
Account rules

Each bank account carries a set of security and compliance rules that apply business logic and fraud prevention to incoming and outgoing transactions. In V2 they are exposed as the parameters object of the bank account. Read them with GET /v2/bank_accounts/{id} and toggle them with PUT /v2/bank_accounts/{id}, which takes the boolean flags listed in the table:
The V2 parameters object also carries an out_blocked flag, which has no counterpart in this table. Understanding these rules matters both for your integration and for testing the different transaction scenarios.

​
Simulate a failure

1

Open the rules of the receiving account

In the Trio App, list your bank accounts and click Actions on the account that generates the QR code. The rules are at the bottom of the account details page.Through the API, read the same rules with GET /v2/bank_accounts/{id}.
2

Enable the rule you want to test

Turn on the rule in the Trio App, or send its parameter as true with PUT /v2/bank_accounts/{id}. The JSON above enables rules 3 and 4.
3

Create a QR code on that account

Generate a dynamic QR code with the receiving account’s id in bank_account_id, as in Cash in.
4

Pay the QR code from the other account

Paste the BR code in the Trio App as described in Simulate a successful deposit. The banking application shows the error below instead of settling the payment, which is what end users see in production:Invalid Pix Key/Copy & Paste

​
What you see on the Trio side

Most payment failures happen during the initial validation, and the error goes straight back to the payer’s banking application. In these cases no transaction record is created on the Trio side and your integration has nothing to handle. This early rejection applies to rules 1, 2, 5, 6, 8, 9 and 10.
When a deposit is recorded on the Trio side, follow it through its status and stages, listed by GET /v2/documents/in, and through webhook events. The Document lifecycle guide describes the statuses.

​
Next steps