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: USD 1k-5k development
• Cost: USD 0.06 to USD 0.30 per transaction (varies a lot)
• Complexity: low (REST API + webhooks)
• Implementation time: 2 to 6 weeks

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.

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 (USD 6k-20k) 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's the real integration time?

Basic implementation (create PIX charge + receive webhook + mark paid) in existing ERP: 2-3 weeks. Complete implementation with reconciliation, MED, multi-gateway, observability: 6-10 weeks. Who promises 1 week probably will 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.