Simulating Depoisit Failures

To progress efficiently, it is essential to understand the two-account mechanism used to create and simulate a payment via QR Code. If you need a refresher on this concept, refer to the previous guide: Successful Deposit Simulation.

Account Configuration for Transaction Restrictions

To ensure security and data integrity, you can set up rules to restrict specific types of transactions, such as:

• Invalid third-party payments.

• Incorrect or incomplete data (invalid CPF/CNPJ, malformed values, etc.).

Approaches to Test Failure Scenarios:

1. Data Validation: Implement checks to prevent invalid inputs.

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

   • The second scenario requires adjustments to account settings to explore potential failures.

Configuring the Account for Testing

1. List

traduza mantendo a mesma estrutura

To move forward efficiently, it is crucial to understand the dual-account mechanism used to create and simulate a payment via QR Code. If you need to revisit this concept, check the previous guide: Deposit Simulation with Success.

Account Setup for Transaction Restrictions

To ensure security and data integrity, you can configure rules to restrict specific transaction types, such as:

• Invalid third-party payments.

• Incorrect or incomplete data (invalid CPF/CNPJ, malformed values, etc.).

Approaches to Test Failure Scenarios:

1. Data Validation: Implement checks to block invalid inputs.

2. Simulating Invalid Scenarios: Create test cases with incomplete or incorrect data to monitor system behavior.

   • The second scenario requires adjustments in account settings to explore potential failures.

Setting Up the Account for Testing

1. List your virtual accounts and click "Actions" to view details of the account used in the QR Code.

2. At the bottom of the page, you'll find configuration options for security and compliance rules, applying anti-fraud logic.

Available Rules:

ID	Rule	Description
1	Block deposits from unverified senders	Rejects payments without sender verification.
2	Block duplicate payments via QR Code	Prevents repeated transactions using the same QR Code.
3	Block amounts that differ from dynamic QR Code	Ensures the paid amount matches the QR Code.
4	Block deposits from legal entities (CNPJ)	Restricts payments to individuals (CPF) only.
5	Block CPF/CNPJ different from QR Code	Requires payer’s CPF/CNPJ to match the registered one.
6	Block unauthorized participants	Prevents payments from blacklisted accounts.
7	Automatic refund for under 18 years old	Returns payments sent by legally underage individuals.
8	Automatic refund for deceased individuals	Reimburses payments from individuals registered as deceased.
9	Automatic refund for invalid CPF/CNPJ	Rejects incorrect tax ID numbers.
10	Block withdrawals to legal entities (CNPJ)	Restricts transfers to individuals (CPF) only.

🔹 Note: Most failures occur during initial validation, and the error is displayed in the user's banking app. In these cases, no record is created in Aurix Pay, and no integration action is required. This applies to rules #1, #2, #4, #5, #7, #8, and #9.

Error Message: If an invalid payment is attempted, the message "Invalid Pix Key/Copy & Paste" will appear (matching the end-user experience).

Asynchronous Responses for Invalid Payments

Some cases are not immediately rejected—the payment is created, and an asynchronous response is sent to your webhook. Examples:

Scenario: Block deposits from bank accounts different from the QR Code's.

Request Payload: // Exemplo de código (omitido no original)

Next Steps

1. Configure the rules according to your tests.

2. Monitor webhooks for asynchronous responses (failed).

3. Refer to the guide Deposit Failure Simulation for practical examples.