Introduction to PIX Transactions
The Indirect Participant (Alias) client can request various functionalities related to PIX transactions. Among them are:
Pix Transfer Types (pix_transfer_type)
| Enumerator | Description |
|---|---|
| manual | Pix using destination account data. Required to send target_account |
| key | Pix using a pix key. Required to send target_pix_key. Recommended to send end_to_end_id from the pix key query if it has been performed |
| static_qr_code | Pix using a static QR code. Required to send the end_to_end_id returned in the QR code decoding |
| dynamic_qr_code | Pix using a dynamic QR code. Required to send the end_to_end_id returned in the QR code decoding |
| reversal | PIX reversal |
Among these functionalities, there is the type of transaction 'synchronicity' that an Indirect Participant can choose to use, according to their needs.
Everything described in this introduction section is also detailed, including how the Indirect Participant should handle it via API, in the following sections.
End to end ID
Every pix transaction has a unique identifier in the central bank. End to End ID is the end-to-end identifier of a pix transfer. It is used for rate-limiting control in the Central Bank.
Each individual or legal entity registration has a bucket with the Central Bank. PIX key query requests consume tokens from this bucket, which are recovered when 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 time established by the Central Bank of Brazil.
Our team will configure the synchronicity regime to be used as agreed with the client.
The endpoints, methods, payloads and other request components are identical for the synchronous and asynchronous regime. The difference would only be that for the asynchronous regime, the response will always be a pix_transfer with pending status if it has been approved in the initial validations. Subsequently a webhook will be sent informing the final status of the transaction (sent or rejected).
Transaction Retry
Due to possible delays in the Central Bank of Brazil's messaging system regarding PIX transactions, QITech has a retry mechanism for PIX transactions, both for the synchronous and asynchronous model.
If this scenario occurs, the Indirect Participant will receive an HTTP 202 status, indicating that the transaction was sent to QITech and is pending confirmation from the Central Bank of Brazil. Once this is retried, the Indirect Participant will be informed via webhook about the transaction completion.