
PIX for iGaming in Brazil: Step-by-Step Integration Guide 2026
How a licensed Brazilian operator wires PIX end to end: SPA payment rules, choosing a PSP or direct BCB participant, the QR and copy-paste deposit flow, the payout API for instant withdrawals, reconciliation, CPF checks and monitoring, with time and cost per stage.
Wiring PIX into a betting cashier takes a licensed operator 6 to 10 weeks from the first PSP call to the first live deposit, and the bill for a deposit plus payout integration typically lands between USD 15,000 and 40,000 in engineering time, before per-transaction fees. The regulatory side is the slow part, not the code: a PIX charge is a short JSON call, but the payment institution won't onboard you until your SPA authorisation and Brazilian entity check out.
This guide is for operators that hold or are about to receive an SPA authorisation under Law 14,790/2023, and for platform and payments teams building the cashier for them. If you're still deciding whether to enter Brazil at all, start with the Brazil and Latin America market guide and come back here once the licence application is moving. The eight steps below follow the order they happen in practice, each stage gets a time, cost and owner, and the article closes with a checklist and the mistakes that cost operators their first quarter.
Why the Brazilian cashier runs on PIX
The Central Bank of Brazil (BCB) launched PIX on 16 November 2020 as a state-run instant payment rail. It runs on the BCB's own settlement system, the SPI, clears in seconds, works 24/7 including holidays, and is free for individuals. By the BCB's own PIX statistics, the rail closed 2024 at roughly 64 billion transactions for the year and passed 6 billion transactions in a single month during 2025, with well over 150 million individual users (figures approximate; the dashboard has the live numbers).
For betting operators the rail matters for a second reason: since the federal regime went live on 1 January 2025, PIX and other account-to-account transfers are the only deposit method the regulator allows at scale. A card-first cashier isn't a weaker option in Brazil. It's a non-compliant one.
The eight steps
- Confirm your regulatory position under the SPA regime. The Secretaria de Prêmios e Apostas (SPA), part of the Ministry of Finance, issues the federal authorisation under Law 14,790/2023: BRL 30 million for up to three brands, valid five years, granted only to a company incorporated in Brazil with at least 20% Brazilian-held capital, a BRL 5 million financial reserve, and a .bet.br domain. The payment rules sit in SPA Ordinance 615/2024 (April 2024). It requires that bettors fund and withdraw only through electronic transfers between accounts held at institutions authorised by the BCB, in the bettor's own name. PIX and TED transfers qualify; cash, boleto, credit cards, crypto and any third-party payment do not. The same ordinance sets the payout clock: a withdrawal request has to be paid within 120 minutes. Read the current ordinances on the SPA page at gov.br before you sign anything, because the SPA has kept tightening which institutions may sit in the flow. Without the authorisation number, no serious Brazilian payment institution will open a betting account for you.
- Choose the payment institution: PSP, bank, or direct participant. PIX has two kinds of participants. Direct participants (banks and larger payment institutions) hold a settlement account at the BCB and connect to the SPI themselves. Indirect participants route through a direct one. Most betting operators integrate through a PSP that is itself a BCB-authorised payment institution, which is the fastest route: onboarding for a licensed operator takes 2 to 6 weeks, and pricing lands around 0.5 to 1.5% on deposits and a flat BRL 0.50 to 3.00 per payout, plus a platform fee of up to a few thousand reais a month (typical market ranges, all negotiable on volume). A bank relationship is cheaper per transaction and slower to set up. Becoming a direct participant yourself means obtaining BCB authorisation as a payment institution and building a connection to the SPI, a 12-month-plus project that only makes sense at very high volume. Whichever route you take, treat it as the first leg of a payment orchestration setup, not the whole thing: you'll want a second PIX provider before the first one has its first outage.
- Sign, onboard and get the sandbox keys. The underwriting pack for a Brazilian PSP looks like the one described in the high-risk acquiring guide, with two Brazilian additions: the SPA authorisation itself and the CNPJ of the licensed entity. Expect to hand over corporate documents, UBO details, the responsible gambling and AML policies you filed with the SPA, and projected volumes. Ask for the contract clauses on settlement timing (D+0 or D+1 to your account), the rolling reserve if any, and the payout float you're expected to pre-fund. Sandbox credentials arrive with the signed contract and let engineering start before the account is fully live.
- Build the deposit flow around dynamic QR and copy-paste. A deposit is a dynamic PIX charge (cobrança) created through the PSP's API with an amount, an expiry (30 minutes is the usual default) and your own transaction id (txid). The response carries a QR code payload and the same payload as a text string, the "PIX Copia e Cola". On desktop you render the QR; on mobile, where the large majority of Brazilian betting traffic lives, the player can't scan their own screen, so the primary button is "copy PIX code" with an attempt to deep-link into the banking app. Keep the player on your own page rather than redirecting to a hosted PSP page: it converts better and lets you show the confirmation the moment the webhook fires. Pre-set amounts (BRL 20, 50, 100, 200) and remembering the last successful deposit both shorten the flow. One rule that affects acceptance rate more than any UI choice: the BCB's default night limit of BRL 1,000 per PIX transfer between 20:00 and 06:00. Players can raise it in their banking app, but the change takes a day or two to apply, so your decline screen should explain that rather than say "transaction failed".
- Build the payout API and make withdrawals instant. Payouts are the mirror image: your backend calls the PSP's transfer endpoint with the amount and the player's PIX key, and the PSP debits your pre-funded float and pushes the money through the SPI. Because Ordinance 615 gives you 120 minutes, the practical target is well under five minutes for anything below your manual-review threshold. Three implementation details matter. First, resolve the PIX key before paying and reject any key whose CPF doesn't match the account holder; the ordinance forbids paying anyone else. Second, use idempotency keys on every transfer call so a retry after a timeout can't pay twice. Third, alert when the float drops below roughly two days of average withdrawal volume, since running dry is the fastest way to lose a Brazilian player base. If your PSP offers batch transfers, use them once you pass a few thousand payouts a day. For the wider context on how account-to-account payments are replacing cards in regulated markets, the open banking guide covers Europe, which is a useful contrast.
- Reconcile on the end-to-end id and handle disputes without chargebacks. Every settled PIX carries a 32-character end-to-end id (E2EID) assigned by the SPI. Store it with your txid and the payer CPF on every deposit, and store the outbound E2EID on every payout; that's the key you reconcile against the PSP's daily settlement file. There is no consumer chargeback in PIX. What exists instead is the BCB's Special Return Mechanism (MED), which lets a payer's bank claw back a transfer in cases of fraud or operational failure, not because a customer changed their mind. Build a small MED handling procedure: a queue for return requests, evidence packs (KYC file, session logs, bet history) and a 24-hour response owner. Card chargeback ratios are simply not a metric in this flow.
- Wire fraud and CPF checks into both directions. KYC under the SPA rules is CPF-based with facial verification at registration, and the ordinance's own-account rule turns the payment rail into a second KYC check: the CPF on the incoming PIX must equal the CPF on the account, or the deposit is refused and flagged. Run the same match on payouts. Layer velocity rules (deposits per hour, deposit-then-withdraw cycles with no bets) and the SPA's deposit-limit and self-exclusion controls on top, and keep in mind the BCB's own rules for unregistered devices, which since late 2024 cap transfers from a device the bank hasn't seen before at BRL 200 per transaction and BRL 1,000 per day. Those caps generate declines that look like fraud from your side and are nothing of the sort. Suspicious activity reporting to COAF stays with the operator, whatever the PSP contract says.
- Monitor in production and keep a second rail warm. Track four numbers per PSP in real time: charge-to-webhook latency (target under 10 seconds), deposit conversion from QR shown to funds credited, payout time from request to E2EID received, and webhook error rate. Alert on all four. Reconcile automatically every morning and send unmatched E2EIDs to a person the same day. Route a small share of traffic through the backup PSP permanently so the failover path is exercised, not just configured.
Stages, time, cost and owner
| Stage | Time | Cost (typical) | Who |
|---|---|---|---|
| SPA authorisation and Brazilian entity in place | Before day 0 | BRL 30M authorisation fee plus legal | Founders, legal counsel |
| PSP selection and commercial terms | 1-2 weeks | Internal time | Head of payments |
| Underwriting, contract, sandbox keys | 2-6 weeks | Setup fee 0 to USD 5,000 | Payments, compliance |
| Deposit flow (charge, QR, copy-paste, webhooks) | 2-3 weeks | USD 8,000-20,000 engineering | Backend and cashier devs |
| Payout API and float management | 1-2 weeks | USD 5,000-12,000 engineering | Backend, finance |
| Reconciliation, MED procedure, CPF matching | 1-2 weeks | USD 3,000-8,000 engineering | Backend, compliance |
| Monitoring, failover PSP, go-live | 1 week | Second PSP onboarding in parallel | DevOps, payments |
| Running costs | Ongoing | 0.5-1.5% per deposit, BRL 0.50-3.00 per payout | Finance |
Engineering figures assume a platform that already exposes a cashier and wallet API; a turnkey platform with a PIX connector already built cuts the middle three rows to configuration and testing.
Which platforms already ship a PIX connector
Building against a PSP directly is one path. The other is to pick a platform whose cashier already speaks PIX and holds the Brazil credentials. iGamingHub tracks 25 platforms with a Brazil licence in the catalog, and 9 of them list PIX among their integrated payment methods. A few worth shortlisting:
- SOFTSWISS: turnkey, hybrid pricing, Brazil among its licences, PIX integrated, 2 to 12 weeks to launch and about 300 payment methods in total.
- SoftGamings: white-label, fixed fee, PIX in the connector list, Brazil licence, and the shortest quoted launch window in the catalog at 1 to 8 weeks.
- Salsa Technology: a Brazil-native platform whose licence list is simply Brazil and SPA, hybrid model, 8 to 18 weeks, LatAm market focus.
- EvenBet Gaming: turnkey or white-label, MGA and SPA in the licence list, hybrid pricing, 6 to 14 weeks.
- Oryx Gaming and Delasport: both list PIX among payment integrations, though neither documents a Brazilian licence on its card; Oryx quotes 6 to 14 weeks to launch.
Check the provider card for each before relying on it; licence lists in the iGamingHub catalog come from public sources and vendor submissions and are updated as they change.
Launch checklist
- SPA authorisation number and CNPJ on hand before contacting any PSP
- Two PIX providers contracted, one live and one warm, both BCB-authorised
- Dynamic charge with txid, expiry and webhook signature validation in place
- Copy-paste as the primary mobile action, QR on desktop, no redirect off-domain
- Night-limit and unregistered-device declines explained on the decline screen
- CPF match enforced on every deposit and every payout, mismatches logged
- Payout automation below a review threshold, target under five minutes, ceiling 120
- Float alerts at two days of withdrawal volume
- E2EID stored on every movement, daily automated reconciliation, MED queue owned
- Latency, conversion, payout time and webhook error rate on a live dashboard
Common mistakes
Onboarding a PSP before the authorisation exists. Underwriting stalls for weeks, then restarts when the SPA number arrives. Sequence it the other way.
Treating PIX like a card rail. Building chargeback tooling nobody will use, while skipping the MED procedure that will actually be triggered.
Hosted redirect on mobile. Every screen change between "deposit" and "paid" costs conversion, and on a phone the QR is useless anyway.
Skipping CPF matching to reduce friction. It's not optional under Ordinance 615, and a third-party deposit found in an SPA audit is a licence problem, not a payments one.
One PSP, no failover. Payment institutions have outages. A single provider means every one of them is your outage too.
Letting the float run dry on a weekend. Withdrawals stall, players post about it within the hour, and the 120-minute clock keeps running.
Ignoring the night limit. Evening is prime betting time, and a BRL 1,000 cap the player has never heard of reads as "the site is broken".