PIX, Open Finance and your ERP: technical integration checklist for 2026

PIX (Brazil's instant payment system) became a commodity. Open Finance is ramping up. But the real technical integration of these services with your custom ERP or business system is still grey area: fragmented documentation, libraries varied in quality, regulation changing.

This is a technical guide for architects, devs and CTOs who will integrate PIX and/or Open Finance into business systems in 2026. Covers architecture, security, anti-fraud, stack choices and common pitfalls. No fluff, with real references.

Current status in 2026: what changed after Open Banking → Open Finance

To understand architecture decisions, we need current regulatory context. Summary of what's in force in May 2026:

• PIX: now 8 years live, processed 60 billion transactions in 2025. Fully mature, with Central Bank SLA of 99.99%.
• Automatic PIX (recurring debit): launched June 2025. Allows customer-authorized recurring debit. Reduces need for recurring invoice.
• International PIX: pilot with 3 countries (Argentina, Uruguay, Portugal) in 2026. Not yet general production.
• Open Finance phase 4: sharing of investment, exchange, pension data. Phase 5 (insurance) in homologation.
• DREX (digital real currency): Central Bank pilot running, still no production for third parties.

For business systems, practical focus is on PIX (charging and payment) and Open Finance phases 1-3 (registration and transactional data). DREX and advanced Open Finance still don't justify technical prioritization in 2026 for SMB.

PIX integration paths: direct with Central Bank vs gateway

You have two architectural choices to integrate PIX in your system. Decision has implications for cost, complexity and control.

Direct integration with Central Bank

Your company becomes PSP (Payment Service Provider) or partner financial institution. You consume Central Bank APIs directly (DICT, SPI). Total control, near-zero transaction cost. But:

• Requirement: be Central Bank authorized institution (rare for SMB)
• Very high complexity: specific digital certification, regulated environment, audit
• Investment: USD 100k+ development + USD 10k+/month infra/compliance
• When worth it: marketplaces with huge volume (1M+ transactions/month), fintechs

Gateway integration (recommended for 99% of cases)

You use intermediary (Stark Bank, Gerencianet, Asaas, Iugu, MercadoPago, Pagar.me, or bank PSPs) that has the relationship with Central Bank. You consume their APIs (simple REST/HTTP).

• Setup: integration development, quoted per project
• Cost: USD 0.06 to USD 0.30 per transaction (varies a lot)
• Complexity: low (REST API + webhooks)
• Implementation time: depends on the ERP, the gateway and the scope; set in the proposal

Criteria to choose gateway: transaction cost at your volume, documentation quality, API latency, technical support, fiscal compliance (if responsible for split e-invoicing), and chargeback/dispute policy (the most neglected point).

Technical security you can't ignore

PIX integrations have non-negotiable security requirements. Fail these and you have real loss and regulatory process.

mTLS (mutual TLS): authenticated communication

All communication with PIX APIs uses mutual TLS: in addition to server presenting certificate, your client also presents. Implementation:

• Generate key pair and CSR (Certificate Signing Request)
• Send CSR to gateway/PSP for signing
• Configure HTTP client with certificate + private key (Guzzle/PHP, Axios/Node, requests/Python)
• Rotate certificates every 1-2 years (configure alert before expiry)

Signed webhooks (JWS)

When gateway notifies you of received payment, notification comes digitally signed (JWS - JSON Web Signature). Verifying signature is mandatory: without that, anyone can send fake webhook to your endpoint and mark order as paid.

• Webhook endpoint must be HTTPS, without basic auth (shared key isn't enough)
• Validate JWS with gateway's public key before processing
• Implement idempotency: webhook can arrive 2-3x for same event
• Always confirm final status via GET after processing webhook (defense in depth)

Idempotency on all operations

Every PIX charging or payment operation must have idempotency key (UUID v4 for example). Without it, slow client retry can generate duplicate payment. PHP implementation: generate UUID in session, persist before calling API, use as X-Idempotency-Key header.

Complete audit log

Every PIX API call must generate log with: timestamp, payload (no sensitive data), response, response time, user_id, IP. Keep for at least 5 years (fiscal requirement). Use SIEM or equivalent tool.

Anti-fraud: where operation can break

PIX is instant and irreversible. Unlike card, no automatic chargeback. PIX fraud is real pain:

• Smishing/Phishing: customer falls for scam, pays PIX to fraudster, then complains to you. Mitigation: education + multi-factor authentication at checkout.
• Cloned PIX key: fraudster swaps recipient key on QR Code. Mitigation: use PIX Cobrança (not loose key) with BR Code that validates ID.
• Duplicate payment: customer pays 2x by mistake. Mitigation: idempotency + clear confirmation.
• Fraudulent refund: customer requests refund after receiving product. Mitigation: clear refund policy, delivery record.

Central Bank's mechanism for this is MED (Special Refund Mechanism): fraud victim customer can request refund within 80 days. Recipient's bank (you or your client) can have value reversed even without fault. Reserving provision for this is prudence.

Automatic PIX for recurring billing: what your system needs

Automatic PIX (Pix Automático) has been live since June 16, 2025. The customer authorizes the recurring charge once, in their own bank app, and may set a maximum amount per payment; from then on each charge is scheduled and settled on the due date without the customer opening the app every month. The rules provide four authorization journeys: a request sent by the company to the customer's bank, confirmed in the app (journey 1); scanning a QR Code with only the recurrence data (journey 2); a QR Code that combines authorization with the first immediate payment (journey 3); or a recurrence offer after paying or scheduling a charge through a QR Code (journey 4).

The difference from traditional direct debit (débito automático) is reach: direct debit depends on an agreement with each bank, while every PIX participant that offers transaction accounts must make Automatic PIX available to paying customers, and charging the payer a fee is forbidden. Compared with the boleto (Brazilian bank slip), the customer no longer pays month by month: their bank schedules the debit and notifies them in advance. The payer stays in control and can cancel the authorization at any time and cancel a scheduled payment until 11:59 pm the day before.

Rules that affect your system

• Scheduling: the payment instruction reaches the customer's bank between 2 and 10 calendar days before the settlement date, so the customer is notified before the debit.
• Retries: if balance or limit is short, the payer's bank tries again the same day (6 pm to 9 pm window). After the due date, the company may resend the charge on up to 3 dates within 7 calendar days, as long as the authorization allows retries.
• Cancellation: the payer can cancel a payment until 11:59 pm the day before; the company can cancel a charge until 10 pm the day before. After that, the company cannot cancel even a retry.
• Maximum amount and limit: if the charge exceeds the maximum amount set by the customer, it is not scheduled. Automatic PIX has its own daily limit, separate from the regular PIX limit.

What your ERP needs

• Integration with the PIX API of the receiving PSP or bank to create the recurrence, generate the journey QR Codes and send the recurring charges.
• Linking the txid to the receivable: each charge carries a transaction identifier (txid). Storing that txid on the installment in accounts receivable is what allows automatic settlement without anyone checking bank statements.
• Sending calendar: a job that sends each charge inside the 2 to 10 day window and controls the retries the authorization allows.
• Automatic settlement and reconciliation: PSP webhook on every settlement, plus a check job for when the webhook fails (the same care described in the security section).
• Authorization states: an authorization refused, expired or cancelled by the customer must show up in the customer record and trigger an alternative billing method (boleto or one-off PIX).

The Central Bank adjustments in 2026

In September 2026 the Central Bank announced versions 2.10.0 of the PIX Initiation Standards Manual (MPI) and of the PIX API, with technical improvements to Automatic PIX recurrence management and wording adjustments for clarity, based on what the Central Bank observed in the product's first year. MPI 2.10.0 was issued by Normative Instruction BCB 769, published in the Official Gazette on August 20, 2026 and already in force. In practice: ask your PSP which PIX API version it runs and whether the recurrence endpoints your system uses have changed.

Open Finance: when is it worth it today

Open Finance is Open Banking expanded: investment, exchange, pension data, soon insurance. For business, real use cases today:

Case 1: Accelerated registration validation

Instead of asking client for income proof (PDF, scan, paper), connects directly with their bank via Open Finance, receives validated statements. Reduces document fraud and accelerates onboarding.

Case 2: Automatic bank reconciliation

Integration with company bank via OF brings real-time statements for accounting reconciliation. Reduces financial data entry hours.

Case 3: Pre-approved credit for customers

B2C case: customer authorizes OF, your company assesses their payment capacity in real time, offers custom installments/credit.

When NOT worth: if you don't have clear use case generating measurable ROI. Open Finance has development cost and compliance cost. Implementing without purpose is money pit.

Stack: production-tested libraries

Lists of libraries working well in production in 2026, separated by language.

PHP

• guzzlehttp/guzzle: standard HTTP client, supports mTLS via context options
• firebase/php-jwt: JWT/JWS verification from webhooks
• gerencianet/gn-api-sdk-php: official Gerencianet SDK (solid for PIX charging)
• starkbank/sdk-php: Stark Bank SDK (excellent DX if you use them as gateway)
• ramsey/uuid: idempotency key generation

Node.js

• axios + https.Agent: mTLS via agent option
• jose: robust JWS verification
• starkbank-sdk: Stark Bank Node
• iugu-node: Iugu SDK
• uuid: idempotency keys

Python

• requests + cert tuple: native mTLS
• PyJWT: JWS validation
• starkbank: Stark Bank Python SDK (quality reference)
• cryptography: certificate manipulation

"PIX integration in custom ERP isn't the hard part: the API is simple. The hard part is what nobody tells you: idempotency, periodic reconciliation, duplicate webhook handling, MED provision policy, and clear error flow for the user. 70% of problems I see in PIX integrations are because someone ignored one of these 5 items."

Final implementation checklist

Before going to production, ensure each of these items:

• ✓ mTLS configured with valid certificate (and renewal alert configured)
• ✓ Webhooks validating JWS signature before processing
• ✓ Idempotency implemented in all payment/charging operations
• ✓ Reconciliation job running every 1-5min for open charges
• ✓ Audit logs with 5+ year retention
• ✓ Error handling with friendly message to user (don't display technical trace)
• ✓ MED provision policy registered with accounting
• ✓ Sandbox tests of each gateway before homologating production
• ✓ Internal technical documentation so another dev can maintain
• ✓ Fallback plan if primary gateway goes down (multi-gateway recommended at high volumes)

Conclusion

PIX in 2026 is technically mature and operationally robust. Who hasn't integrated yet in business system is literally letting money slip through default and invoice friction. Open Finance is still more niche: worth for specific cases.

Integration success depends less on gateway choice and more on technical discipline: idempotency, security, reconciliation, observability. Who treats this as serious project has solid operation. Who treats as "ah, just a REST API" discovers problems in production, with angry customer.

Frequently asked questions

Can I integrate PIX without touching company's bank?

Yes, via third-party gateway (Stark Bank, Asaas, Iugu, MercadoPago, etc.). You receive values in their account, then transfer to your bank account. No need to open new account at specific bank. Cost: USD 0.06 to USD 0.30 per transaction, depending on volume.

Which gateway is best?

Depends on case. Stark Bank has best dev DX and clean API; Gerencianet has competitive cost in Brazil; Asaas is strong in recurrence; MercadoPago for who already sells there. To decide, do 1-week PoC in 2-3 and measure: latency, documentation quality, real technical support.

Is Automatic PIX already available for business?

Yes since June 2025. But implementation is still restricted: not all gateways support, and UX in client app varies by bank. We recommend validating first with 1-2 banks where your base concentrates, before promising "all automatic" commercially.

What does the integration timeline depend on?

On how much your current ERP allows integration (does it have an API, an accessible database, available source code?), on the chosen gateway and on the scope: just creating charges and receiving webhooks is far less work than reconciliation, MED, multiple gateways and monitoring. The timeline comes from analyzing your system and is put in writing in the proposal. Be wary of anyone promising a short timeline without looking at the ERP: they usually skip security items.

Is Open Finance safe for my customers?

Yes, within Central Bank standards. Customer always explicitly authorizes sharing, with defined and revocable deadline at any moment. Risk is if you implement your part badly (not ciphering data, leaking tokens). Serious implementation with independent security audit is mandatory.

How does Automatic PIX authorization work, and can the customer cancel?

The customer authorizes once in their bank app, through a request sent by the company or by scanning a QR Code, and may set a maximum amount per payment. Each charge is scheduled 2 to 10 days before the date and the bank notifies the customer. They can cancel the authorization at any time and cancel a specific payment until 11:59 pm the day before, and the bank cannot charge them a fee. For the company, what matters is that the system handles the cancellation and falls back to another billing method.