When sending or receiving transactions, one might ask oneself how Trio manages to offer a fully secure closed loop, without any hiccuping or missing transactions/refunds whilst also providing protection against frauds.

For this sort of control, we offer plentiful parameterization aligned with compliance rules when making any movement, so you know exactly what happened throughout your operation.

PayIns

Regarding money coming in, we apply some compliance rules that decide whether money from a single transaction will be received or not.

Whenever a compliance rule is being infringed in a transaction, we take it upon ourselves to receive the money and automatically refund it back to the sender's account, without notifying you at all of both settlement and refund events. We call this process an automatic refund.

This is acted upon strictly as a business rule and a facilitator, so you do not have to worry about a transaction that should not be considered on your end at all. Therefore, when receiving notifications, all webhooks you receive will be from settled payments.

Here you can see the PayIn-related compliance rules that are enabled for a virtual account:

Default	Compliance rule	Editable?	Possible situation
Not allowed	Unidentified deposits	Yes	When a payment is done via the bank account directly or via the bank account's pix key, we block the payment so you can know exactly who the money came from.
Not allowed	Deposits from duplicated QR code payments	Yes	When a payment is done twice to the same QRCode, we block the payment so each payment can be received separately in order to avoid confusion.
Not allowed	Deposits with value different from dynamic QR code	Yes	When a payment is done with an amount different from the initially stated in the QRCode. Useful for controlling the exact amount of transactions, and avoiding the need to create two QRCodes for the same transaction. We tend to recommend clients to always leave this parameter on.
Not allowed	Deposits with tax number different from dynamic QR code	Yes	When a payment is done by an individual with a tax number different from the tax number initially set in the QRCode creation. Useful for correlating QRCodes created with payments received.
Not allowed	Deposits from legal entities	No	When a payment is not done by an individual with a natural person tax number (CPF in Brasil), but from a legal entity with a legal tax number (CNPJ in Brasil).
Not allowed	Underage individuals	No	When a payment is being done by an individual who is not 18 years old, we are obliged to not allow such payment to be completed.
Not allowed	Transactions with tax number of a deceased individual	No	When a payment is being done by an individual who is deceased, we are obliged to not allow such payment to be completed.
Not allowed	Transactions with an invalid tax number	No	When a payment is being done by an individual utilizing an invalid tax number, we are obliged to not allow such payment to be completed.
Not allowed	Transactions that exceed the operational limit	No	When a payment is being done by an individual who is deceased, we are obliged to not allow such payment to be completed.
Not allowed	Transactions made by PEPs (politically exposed individuals)	No	When a payment is being done by an individual who is a publicly known individual, we are obliged to not allow such payment to be completed.
Not allowed	Transactions from individuals listed in the UN sanction list	No	When a payment is being done by an individual sanctioned by an UN sanction list, we are obliged to not allow such payment to be completed.
Not allowed	Transactions from individuals listed in the EU sanction list	No	When a payment is being done by an individual sanctioned by an EU sanction list, we are obliged to not allow such payment to be completed.
Not allowed	Transactions from individuals listed in the OFAC sanction list	No	When a payment is being done by an individual sanctioned by an OFAC sanction list, we are obliged to not allow such payment to be completed.

Let's elucidate this with a real-life example to show how this feature can be fully taken advantage of.

Automatic Refunds

Transactions made by a tax number different from dynamic QR code

Assuming we already have credentials, we should first create a dynamic QRCode (step-by-step here).

We will create a dynamic QRCode by making a POST to /banking/cashin/pix/qrcodes with the tax number 70004764005:

{
  "virtual_account_id": "018af380-cedc-3a53-29c0-e329bf0e109b",
  "counterparty": {
    "tax_number": "70004764005",
    "name": "Jhon Doe"
  },
  "amount": 1200,
  "external_id": "01HBSXY7GN8V6NHJ51Z0NX8QK9",
  "description": "Pay in Sandbox",
  "expiration_date": "2024-03-29T00:15:00",
  "options": {
    "allow_change_the_amount_on_payment": false,
    "show_qrcode_image": false
  }
}

This will return a 200 response containing a body:

{
  "data": {
    "allow_change_the_amount_on_payment": false,
    "amount": {
      "amount": 1,
      "currency": "BRL"
    },
    "bank_account_id": "018af380-ced7-436a-b118-1cf3bd54243f",
    "counterparty_id": "018af3e0-63b4-d4fc-9c84-459314081895",
    "description": "Pay in Sandbox",
    "entity_id": "018af380-789f-4c52-fb8a-8160ad66182a",
		"expiration_datetime": "2024-03-27T16:31:41.753423Z",
    "external_id": "01HBSXY7GN8V6NHJ51Z0NX8QK9",
    "hash": "00020101021126640014br.gov.bcb.pix0114041715452853610224018afba3-4924-6ed6-7847-520400005303986540412.05802BR5907Capstan6008Curitiba61088025010462070503***63043277",
    "id": "018afba3-491b-4fd2-e8e2-edee87faab18",
    "pix_key_id": "018af380-eb7e-93a9-4b9f-c08af1d7772f",
    "origin_id": "018e5caf-98c8-016a-d411-82cfbd670714",
	  "origin_type": "api_client",
    "status": "created",
    "timestamp": "2023-10-04T17:01:36.923773Z",
    "virtual_account_id": "018af380-cedc-3a53-29c0-e329bf0e109b"
  }
}

You will not receive any webhooks if a transaction was automatically refunded.

In some cases, you might desire to confirm the status of the QRCode you created. To do so, you should wait for the expiration_date you set for the QRCode to be reached, and then verify whether the QRCode has been used or not by making a GET to /banking/cashin/pix/qrcodes/:id.

In this case, we will query /banking/cashin/pix/qrcodes/018afba3-491b-4fd2-e8e2-edee87faab18, containing the ID we created above:

You will receive a 200 response akin to this:

{
  "allow_change_the_amount_on_payment": false,
  "amount": {
    "amount": 1,
    "currency": "BRL"
  },
  "bank_account_id": "018e5bd1-067d-ee46-4825-402685959bc7",
  "collecting_document": {
    "amount": {
      "amount": 1,
      "currency": "BRL"
    },
    "id": "018e5cb5-7530-afc7-8c77-7d59849bad06",
    "marked_for_automatic_refund": true,
    "status": "refunded",
    "transaction_date": "2024-03-20T16:32:59.696910Z"
  },
  "bank_account_id": "018af380-ced7-436a-b118-1cf3bd54243f",
  "counterparty_id": "018af3e0-63b4-d4fc-9c84-459314081895",
  "description": "Pay in Sandbox",
  "entity_id": "018af380-789f-4c52-fb8a-8160ad66182a",
	"expiration_datetime": "2024-03-27T16:31:41.753423Z",
  "external_id": "01HBSXY7GN8V6NHJ51Z0NX8QK9",
  "hash": "00020101021126640014br.gov.bcb.pix0114041715452853610224018afba3-4924-6ed6-7847-520400005303986540412.05802BR5907Capstan6008Curitiba61088025010462070503***63043277",
  "id": "018afba3-491b-4fd2-e8e2-edee87faab18",
  "pix_key_id": "018af380-eb7e-93a9-4b9f-c08af1d7772f",
  "origin_id": "018e5caf-98c8-016a-d411-82cfbd670714",
  "origin_type": "api_client",
  "status": "used",
  "timestamp": "2023-10-04T17:01:36.923773Z",
  "virtual_account_id": "018af380-cedc-3a53-29c0-e329bf0e109b",
  "stages": [
    {
      "id": "018e5cb4-44c3-ca45-85d8-9ab513a5cd29",
      "tax_number": null,
      "timestamp": "2024-03-20T16:31:41.763535Z",
      "type": "created"
    }
  ],
}

Pay attention to the fact that there is a key called collecting_document, containing summarized data for the document representing the money that was received and then automatically refunded.

Interesting information to take note is:

The key marked_for_automatic_refund is set to true, meaning it took part in an automatic refund process.
The key status states that the document was refunded successfully.
The key id can be used to consult the full collecting document data through GET /banking/cashin/documents/:id .

This is just for means of consultation, and of course will not have any effect on the overall balance of your virtual account, since it is fully received and refunded per our responsibility.

PayOuts

Regarding money going out, we also apply some compliance rules and control cash out processes that decide whether a payment will be transferred, only as a form of protecting our client base.

Here you can see the PayIn-related compliance rules that are enabled for a virtual account:

Default	Compliance rule	Editable?	Possible situation
Allowed	Block payouts to legal entities	No	When attempting to make a payment to an account that belongs to a legal entity represented by a legal tax number (CNPJ in Brasil).

As for controlling the transaction regarding the tax number involved, we offer two possible methods to enable a verification of the tax number involved before a PayOut:

Pix V1

When utilizing this method, the responsibility of verifying whether the tax number of the QRCode/Pix key selected is the same as the tax number desired relies on our clients. It is returned in the first step of the Pix V1 process, in the Check process.

Pix V2 (Recommended)

When utilizing this method, the responsibility of verifying whether the tax number of the QRCode/Pix Key is the same relies on Trio itself. This method is the recommended because it relies on advanced internal algorithms that regulate the whole process, making it only necessary for you to send the reference_tax_number field, such as in the example below:

{
    "virtual_account_id": "{{virtual_account_id}}",
    "type": "key",
    "reference": "37926790869",
    "reference_tax_number": "37926790869",
    "external_id": "01HKMFH87F4J8KV2MBVKZ05XF4",
    "amount": 1,
    "description": "Payment Cashout V2"
}

When receiving webhooks for this payment, you will receive a failed status:

{
  "category": "payment_document",
  "company_id": "0189b5ad-8076-6b61-e299-9920d819a3f8",
  "data": {
    "amount": {
      "amount": 30000,
      "currency": "BRL"
    },
    "bank_account_id": "0189b787-efb6-2650-7baa-00ba98c4daf1",
    "company_id": "0189b5ad-8076-6b61-e299-9920d819a3f8",
    "counterparty": {
      "company_id": "0189b5ad-8076-6b61-e299-9920d819a3f8",
      "external_id": null,
      "id": "018d1e1c-a729-6400-2394-c0357f172c90",
      "inserted_at": "2024-01-18T19:46:50.793890Z",
      "ledger_type": "customer",
      "legal_name": null,
      "maximum_amount": null,
      "maximum_transactions": null,
      "name": "ADRIANA ALVES MONTEIRO",
      "tax_number": "75204843191",
      "updated_at": "2024-01-18T19:46:50.793890Z"
    },
    "counterparty_bank_account": {
      "account_digit": "8",
      "account_number": "102832833",
      "account_type": "payment",
      "bank_ispb": "22896431",
      "bank_number": "380",
      "branch": "0001",
      "id": "018de55d-08b6-caef-ed1f-faf059888a5f",
      "inserted_at": "2024-02-26T12:21:36.054258Z",
      "updated_at": "2024-02-26T12:21:36.054258Z"
    },
    "counterparty_bank_account_id": "018de55d-08b6-caef-ed1f-faf059888a5f",
    "counterparty_id": "018d1e1c-a729-6400-2394-c0357f172c90",
    "description": null,
    "end_to_end_id": null,
    "entity_id": "0189b5b4-ea58-a3a8-7c40-f0de1d0cb0af",
    "error_code": "DICT_KEY_DIFFERENT_TAX_NUMBER",
    "error_message": "Tax number da chave é diferente do tax number enviado como referência",
    "external_id": "3293bf68-8e03-40a3-8d72-fb66ac65fdf6",
    "id": "018de55c-f8bf-c145-f9b6-b177a3d82267",
    "origin_id": "018c4685-200e-f7ac-761f-ebb6449bb5e5",
    "origin_type": "api_client",
    "payment_date": null,
    "pix_key": "+5562993308087",
    "receipt_url": null,
    "reconciliation_id": "018de55c-f8bf-18ef-41b6-7b978420d86b",
    "ref_id": "018de55d-08b7-d770-7147-c6ef3e8ce0c6",
    "ref_type": "pix_key",
    "status": "waiting_analysis",
    "transaction_date": "2024-02-26T12:21:31.967284Z",
    "type": "pix",
    "virtual_account_id": "0189b787-efc8-b0f5-8171-781814fac2a6",
    "without_fee_and_tax": false
  },
  "ref_id": "018de55c-f8bf-c145-f9b6-b177a3d82267",
  "timestamp": "2024-02-26T12:21:36.335699Z",
  "type": "failed"
}

Take note of the error_code DICT_KEY_DIFFERENT_TAX_NUMBER, and the error message Tax number da chave é diferente do tax number enviado como referência state that the tax number of the individual that holds the pix Key is different than the one sent in the reference_tax_number field. The payment document will then have a status of failed if you make a request to /banking/cashout/documents/:id.