Pix built into your system

Who it's for

For companies that take Pix payments and still confirm each one by checking the bank statement.

What it solves

• The customer pays, but the order is only released once someone checks the statement.
• Every charge uses the same Pix key, so it is hard to tell who paid for what.
• A lost webhook leaves the payment unrecorded in the system.
• Refunds are made by hand, outside the system, and nobody knows where they stand.

What we do

Charges with dynamic QR codes

Each charge has its own identifier, amount and due date, tied to the order.

Webhook confirmation

A confirmed payment updates the order; a repeated notice never records the payment twice.

Status check when a notice fails

If a webhook does not arrive, the system queries the charge at the PSP and updates its status.

Refunds

Full or partial refunds requested by the system itself, with the reason recorded.

Sandbox testing

Every flow tested in the PSP's test environment before going live.

Credentials kept out of the code

Access keys and the mutual TLS connection the PSP requires, stored in a dedicated vault.

What you get

• Integration with your PSP's Pix API, in production
• A record of every charge, payment and refund
• An alert when a payment is not confirmed
• Automated tests for the charge and refund flows
• Documentation for your team to run and extend the integration

How we do it

1. Mapping

   How an order starts, who charges and where the payment must show up.

2. PSP review

   We check what your bank's or institution's API offers.

3. Development

   Charge, webhook, status check and refund, tested in the sandbox.

4. Go-live

   A supervised switch to production, with a way back.

5. Follow-up

   Alerts, checking the first days of payments and adjustments.

Technology examples

• API Pix
• OpenAPI
• mTLS
• Webhooks
• PostgreSQL
• RabbitMQ

In Brazil, we handle

Pix

The Central Bank of Brazil's instant payment system.