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.

Last updated

Was this helpful?