Simulating Deposit Failures

In order to proceed effectively, it's essential to have a comprehensive understanding of the two accounts mechanism used for creating and simulating a QRCode payment.

Should you need a refresher on this topic, please make sure to review the previous guide thoroughly before moving forward: 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's also essential to handle scenarios where data is incorrect or incomplete, such as incomplete CPF or CNPJ entries, or malformed strings or values.

When testing failure scenarios, you can follow two approaches:

1. Enforce Data Validation: Implement validation checks to prevent and manage invalid input cases effectively.

2. Simulate Invalid Scenarios: Create test cases with incomplete or malformed data to observe system behavior.

The second scenario demands modifications to account configurations to create specific conditions that allow us to explore a wider array of possibilities.

We'll detail the specific configurations needed to reach these scenarios, ensuring a thorough examination of the system's capabilities and limitations.

---

Configuring the Account

To test failure scenarios, begin by setting your account configurations. First, list your virtual accounts. Click the "Actions" button to view the virtual account details, which will be used to generate the QR Code for the payment.

In the bottom of the details page there is a set of options to configure security and compliance rules for a virtual Pix account, applying business logic and fraud-prevention measures.

Understanding these rules is crucial for your integrations, as well as testing your integration properly.

Rule ID	Rule	Description
1	Block payins from unidentified individuals	Rejects payments where the sender's identity could not be verified.
2	Block duplicated QRCode payins	Blocks repeated payments using the same QR Code to prevent duplicate transactions.
3	Block payins with a different amount from the dynamic QRCode's amount	Ensures that the received amount matches the value encoded in a dynamic QR code.
3	Block payins from legal entities	Prevents receiving funds from companies (CNPJ), allowing only individuals (CPF).
4	Block payins from tax number different from the dynamic QRCode's tax number	Ensures that the payer’s tax ID matches the one associated with the QR code creation.
5	Block payins from unauthorized participants	Blocks payments from blacklisted participants.
6	Block payins from counterparty bank accounts different from the QRCode	Verifies that the sending bank account matches the one expected based on the QR code payment.
7	Automatic refund for deposits incoming from a minor	Automatically returns funds sent by someone legally underage (18 years old).
8	Automatic refund for deposits incoming from deceased individuals	Refunds any payment made by an individual marked as deceased in official records.
9	Automatic refund for deposits incoming from individuals with an invalid tax number	Returns funds from individuals with invalid CPF/CNPJ.
10	Block payouts to legal entities (with a legal tax number/CNPJ)	Disables outgoing transfers to companies, restricting payouts to individuals only.

By activating or deactivating these options you are able to check failure scenarios.

Note: Most payment failures occur during initial verification and the error is promptly returned to the user's banking app. As a result, no record of the attempt is created on the Trio side, and no integration action is needed,

This early rejection happens for rules #1, #2, #4, #5, #7, #8, and #9

When an invalid payment is attempted, the error message "Invalid Pix Key/Copy & Paste" will appear on your interface, similar to what end-users experience, as shown below.

Async Responses for Invalid Payments

A few cases will not be rejected upfront, the payment will be created and an async responses will be sent to your callback endpoint. Next, we present some of those cases:

Block pay-ins from counterparty bank accounts different from the QRCode

• Request Payload

// Some code