Skip to main content
To proceed effectively, it is essential to understand the two-account mechanism used to create and simulate QR Code payments. If you need a refresher on this topic, please review the previous guide before continuing: Simulating Deposit Success

​
Account Configuration for Transaction Restrictions

To ensure security and data integrity, you can configure account settings to restrict specific transaction types, such as invalid third-party payments. It is also important to test scenarios involving incorrect or incomplete data, including:
  • Invalid CPF or CNPJ values
  • Incomplete tax numbers
  • Malformed strings or invalid values
When testing failure scenarios, you can follow two approaches:
  1. Enforce Data Validation
    Implement validation rules to prevent and properly handle invalid input.
  2. Simulate Invalid Scenarios
    Create test cases using incomplete or malformed data to observe how the system behaves.
The second approach requires changes to the account configuration in order to reproduce specific failure scenarios and explore a broader range of possibilities. The following sections explain the configurations required to test these scenarios and better understand the system’s capabilities and limitations.

​
Configuring the Account

To test failure scenarios, start by configuring your account settings. First, list your virtual accounts and click the Actions button to open the virtual account details. This account will be used to generate the QR Code for the payment. Image (37) At the bottom of the details page, you will find a set of security and compliance rules available for the virtual Pix account. These rules apply business logic and fraud-prevention measures to incoming and outgoing transactions. Understanding these rules is essential both for your integration and for properly testing different transaction scenarios. By enabling or disabling these rules, you can simulate different failure scenarios during testing.
Note
Most payment failures occur during the initial validation process, and the error is immediately returned to the payer’s banking application. In these cases, no transaction record is created on the Trio side, and no additional integration handling is required. This early rejection behavior applies to rules #1, #2, #5, #6, #8, #9, and #10.
When an invalid payment is attempted, the following error message will appear in the banking application: Invalid Pix Key/Copy & Paste This behavior is similar to what end users experience in production environments. Image (36)