Introduction to Transactions within the PIX Scope
The Indirect Participant's client (Alias) can request various functionalities related to transactions within the PIX scope. Among them are:
Pix transfer types (pix_transfer_type)
| Enumerator | Description |
|---|---|
| manual | Pix using destination account details. Must send target_account. |
| key | Pix using a PIX key. Must send target_pix_key. Recommended to send end_to_end_id from the key query if performed |
| static_qr_code | Pix using a static QR code. Must send the end_to_end_id returned in the QR code decoding |
| dynamic_qr_code | Pix using a dynamic QR code. Must send the end_to_end_id returned in the QR code decoding |
| reversal | Pix refund |
Among these functionalities, there is the type of 'synchronicity' of the transaction that an Indirect Participant can choose to make, according to their needs.
Everything described in this introduction section is also detailed in the subsequent sections on how the Indirect Participant should handle it via API.
End to end ID
Every PIX transaction has a unique identifier at the central bank. End to End ID is the end-to-end identifier of a PIX transfer. It is used for rate-limiting control at the Central Bank.
Each individual or business registration has a bucket with the Central Bank. PIX key query requests consume tokens from this bucket, which are recovered upon making a PIX transaction linked to a query. The link between a PIX key query and a transaction is made through the End to End ID.
Transaction Synchronicity
The Indirect Participant can choose to perform a PIX transaction synchronously or asynchronously. In both modes, the PIX transaction will be executed within the established time by the Central Bank of Brazil.
Our team will configure the regime of synchronicity to be used as agreed with the client.
The endpoints, methods, payloads, and other components of the request are identical for synchronous and asynchronous regimes. The only difference is that for asynchronous regime, the response will always be a pix_transfer with status pending if approved in the initial validations. Then a webhook will be sent informing the final status of the transaction (sent or rejected).
Retrying Transactions
Due to potential delays in the messaging system at the Central Bank of Brazil concerning PIX transactions, QI Tech has a retry mechanism for PIX transactions, both in synchronous and asynchronous models.
If this scenario occurs, the Indirect Participant will receive an HTTP 202 status, indicating that the transaction has been sent to QI Tech and is pending confirmation from the Central Bank of Brazil.
Once retried, the Indirect Participant will be informed via a webhook about the transaction's completion.