Pix payment

Pix payment for Brazilian traffic — instant settlement, one API.

topropay surfaces PIX — the Banco Central do Brasil instant-payment rail — as a first-class method inside the same unified API as cards, wallets and BNPL. Dynamic QR codes, copy-paste keys, merchant-initiated refunds, and one reconciliation feed across BRL traffic.

Book a PIX integration review Read the API docs
topropay.com/checkout/ · PIX

R$ 189,00

Scan with your bank app or copy the key

PIX key (copy-paste) 00020126360014BR.GOV.BCB.PIX0114+551199999999952040000…

Routed through topropay · BCB end-to-end ID captured

Instant
settlement, 24/7/365
BRL
domestic Brazilian rail
QR + key
static & dynamic PIX surface
1 API
with card, wallet, BNPL

Key benefits

Why orchestrated pix payment gateway integration wins on BRL traffic

Four outcomes that show up consistently once PIX sits next to card and wallet on the same orchestration layer rather than in a separate Brazilian console.

  1. 01

    Instant settlement, 24/7/365

    PIX clears in seconds, on weekends, on holidays, at night. A buyer in Recife at 2am gets a confirmed authorisation back inside the same checkout flow, no overnight batch. The merchant sees the receipt in the operator portal in real time, not on the next business morning.

  2. 02

    Lower landed cost than card for BRL traffic

    PIX carries a per-transaction fee from the underlying provider — typically a fraction of card interchange + scheme fees for the same authorisation in BRL. For high-volume merchants selling in Brazil, surfacing PIX next to card is the single biggest landed-cost lever on the checkout.

  3. 03

    Zero chargeback window

    A confirmed PIX authorisation has no representment cycle the way card does — once settled, it's settled. Refunds are merchant-initiated; unilateral chargebacks don't exist on the rail. Operationally that's a different dispute calendar, but on net it removes a class of revenue leakage entirely.

  4. 04

    Same API as card, wallet and BNPL

    A PIX authorisation POSTs to the same /v1/payments endpoint as a Visa charge or an Apple Pay tap. The merchant doesn't pick a different SDK per method; the webhook event model, the vault token, the reconciliation row — all identical.

How it works

From PIX QR to a normalised ledger row in five stages

What happens between rendering the dynamic QR and the row settling into the reconciliation export. Five concrete stages, most of them measured in seconds.

  1. 01

    Render the PIX surface

    topropay renders either a dynamic QR (one per checkout, with the amount embedded) or a copy-paste PIX-key for the buyer's bank app. The merchant's checkout calls one endpoint; the surface is configurable from the dashboard.

  2. 02

    Buyer pays from their bank app

    The buyer scans the QR or pastes the key into Itaú, Nubank, Bradesco, Santander, Caixa, Banco do Brasil or any participating PIX bank. The bank-side flow takes seconds; no card form, no 3DS step-up.

  3. 03

    BCB rails confirm the transfer

    Banco Central's SPI infrastructure clears the transfer in real time. The connected PIX provider watches for the credit and fires a normalised authorised event to topropay.

  4. 04

    Webhook lands on the merchant's URL

    topropay forwards the signed, normalised webhook — the same event model the merchant's stack already handles for card and wallet authorisations. The order ships on receipt, the ledger row writes.

  5. 05

    Reconcile alongside BRL card traffic

    PIX receipts settle to the merchant's BRL settlement account on a configurable cycle. The reconciliation feed shows PIX rows next to BRL card rows under one method-tagged ledger.

Main use cases

Where pix payment earns its keep

Six merchant shapes that route BRL traffic through PIX inside the same orchestration as card and wallet — same platform, different policy mix.

  • DTC BR

    Brazilian DTC brands and e-commerce

    PIX is the dominant Brazilian rail — typically 30-40% of consumer e-commerce checkouts and rising fast. A Dutch or US merchant selling into Brazil leaves measurable conversion on the table without it. The pix payment app surface on the buyer side is universal; the merchant just enables PIX on the same checkout.

  • Cross-border

    Cross-border merchants selling into Brazil

    EU, US or APAC merchants enabling Brazilian PIX via the same pix gateway integration their cards already use — no second integration, no second reconciliation pipeline, no Brazilian-only console. Settlement currency is a policy choice; merchants can hold BRL or convert on receipt.

  • Marketplaces

    Marketplaces with Brazilian buyers

    Per-seller payouts in BRL via PIX (PIX is bidirectional — receive and send) while buyer-side PIX captures the deposit. Split-payment routing preserves the per-seller ledger across rails.

  • Travel

    Travel and ticketing with BR buyers

    High-ticket bookings benefit from PIX's instant clearance — the seat or room is held the moment the buyer's bank confirms, not pending a card-clearing window. Refund flow is merchant-initiated via the same API.

  • B2B

    B2B invoicing into Brazilian counterparties

    Invoices to Brazilian B2B counterparties paid via PIX clear in seconds. The invoice and the PIX receipt share one record in the reconciliation feed; FX exposure compresses because there's no clearing-window gap.

  • Subs

    Subscriptions with PIX first-charge

    Typical pattern: PIX captures the first charge for a Brazilian subscriber; card-on-file (where the merchant chooses to capture one alongside) or PIX-Recorrência handles renewals. Both run through the same recurring engine, with vault tokens identifying the customer.

Rail comparison

PIX vs card for Brazilian-domestic checkouts

Two rails, often surfaced on the same checkout. The comparison below explains where each one earns its place — and why most merchants run both.

Dimension PIX Card (BR domestic)
Settlement timing Seconds, 24/7/365 T+1 to T+30 depending on acquirer and product
Chargeback model No representment cycle; merchant-initiated refunds; MED for genuine fraud Full scheme chargeback cycle (Visa / Mastercard rules)
Per-transaction cost Flat fee per authorisation (typically lower than card on small tickets) Interchange + scheme + acquirer fees (percentage-based)
Buyer surface QR or copy-paste key in the buyer's bank app Card form + selective 3DS / SCA challenge
Recurring PIX-Recorrência where supported; otherwise one-off plus card-on-file Network tokens + scheme account updaters
Integration on topropay Same /v1/payments endpoint, method: pix Same /v1/payments endpoint, method: card

Platform features

Capabilities behind the pix gateway integration

What the platform actually ships for PIX — beyond the general orchestration features shared with card and other methods.

  • Unified pix payment gateway integration

    One REST API call surfaces PIX as a method alongside card, wallet and BNPL — same authorise endpoint, same webhook stream.

  • Dynamic QR codes

    Per-checkout dynamic QR codes with the amount and order ID embedded — generated server-side, rendered as PNG / SVG on the checkout.

  • Copy-paste PIX-key surface

    Alongside the QR, a copy-paste PIX-key field for buyers who prefer to paste into their bank app rather than scan.

  • Refund API

    Merchant-initiated refunds via the same /v1/payments/:id/refund endpoint as card; PIX refunds clear back to the originating bank account in seconds.

  • Webhook event model

    Signed, replay-safe webhook events for authorised / refunded / failed — identical shape to card events.

  • Operator portal for BR

    PIX authorisations, refunds and reconciliation in the same dashboard as the merchant's card traffic, with PIX-specific columns (bank, key, end-to-end ID).

  • BCB end-to-end ID retention

    The BCB SPI end-to-end ID is captured and surfaced on every PIX authorisation row — useful for audit and counter-party reconciliation.

  • Refund-evidence retention

    PIX refund operations log operator identity, reason code and timestamp — surfaceable for audit and dispute response.

  • PIX-Recorrência (where supported)

    Where the connected PIX provider exposes PIX-Recorrência (recurring PIX), the platform surfaces it through the recurring-payment engine alongside card recurring.

  • FX / conversion on receipt

    Optional conversion-on-receipt for non-BRL merchants — incoming BRL converts to the merchant's settlement currency at the rail's quote.

  • Sandbox parity

    Sandbox tenant supports the full PIX flow — dynamic QR generation, simulated bank confirmation, webhook replay, refund testing.

  • Audit log

    Operator actions, refund events and reconciliation exports logged with timestamp and actor identity.

Trust & compliance

Compliance posture for pix payment processing

PIX is delivered through a licensed Brazilian connection; the rest of the posture is inherited from the platform's audited environment.

PIX via licensed connectivity
PIX is delivered through a connected provider with the relevant Brazilian payment-institution licensing; topropay routes and reconciles around it.
BCB SPI alignment
Authorisations carry the BCB end-to-end ID; refund operations follow BCB-aligned timing and audit requirements.
PCI DSS Level 1 (card side)
PCI DSS Level 1 posture covers the card traffic that PIX sits next to; PIX itself does not touch card data.
AML & sanctions screening
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical and BR-specific risk patterns.
Data residency for BR
Brazilian-resident traffic stays in-region by default where the merchant requires it; LGPD-aligned handling for the PIX side.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of rail.

Ready to switch on PIX

PIX next to card on the same checkout, same API.

A 30-minute PIX review covers the connected provider, settlement-currency policy for non-BRL merchants, the QR / copy-paste-key surface and a sandbox to test against before any commercial commitment.

Book a PIX integration review Read the API docs

Frequently asked

Buyer questions about pix payment on topropay

Questions buyers ask before committing — what PIX is, how the integration looks, chargeback semantics, refunds, recurring PIX and sandbox parity.

  1. 01

    What is PIX, exactly?

    PIX is the instant-payment rail operated by the Banco Central do Brasil (BCB) and its SPI clearing infrastructure. Participating banks support real-time transfers 24/7/365 against a PIX-key (CPF/CNPJ, email, phone, random) or a dynamic QR. From a merchant perspective it is the dominant non-card rail in Brazil and continues to grow faster than card e-commerce.

  2. 02

    How does pix payment look from the buyer's perspective?

    The buyer sees a QR (and/or a copy-paste PIX-key) on the merchant's checkout, opens their bank app — Nubank, Itaú, Bradesco, Santander, Caixa, Banco do Brasil or any participating bank — scans or pastes the key, confirms the amount, and approves. The merchant gets a webhook confirmation back inside seconds. No card form, no 3DS step-up, no overnight wait.

  3. 03

    Is there a specific pix payment app I need on the merchant side?

    No — there is no merchant-side pix payment app to install. PIX is exposed through topropay's unified payments API; the merchant's existing checkout or back-end stack calls the same endpoint as for card, with `method: pix` in the request. The buyer-side pix payment app is whichever Brazilian bank app the buyer already uses.

  4. 04

    What is a gateway pix integration on topropay?

    Gateway pix integration on topropay means surfacing PIX through the platform's pix payment gateway behaviour — the connected PIX provider handles the SPI side, topropay handles the routing, the operator portal and the reconciliation. From the merchant's code, it is one REST endpoint with a method field.

  5. 05

    How does the pix gateway compare to a direct Brazilian provider?

    A direct Brazilian provider exposes PIX behind its own API; the merchant integrates against that API alongside whatever card processor it already runs. topropay's pix gateway integration sits one layer above — PIX is one method behind the same unified API that already covers cards, wallets and BNPL. The merchant integrates once and turns PIX on alongside everything else, with one reconciliation feed across all methods.

  6. 06

    What does pix payment gateway behaviour cover in practice?

    Pix payment gateway behaviour on the platform covers the authorise verb (generate the dynamic QR or PIX-key), the listen step (wait for the bank-side confirmation), the refund verb (merchant-initiated refund back to the originating account), and the webhook stream (signed events for every state change). Same shape as card, different rail underneath.

  7. 07

    Is there a chargeback risk on PIX?

    PIX has no card-style chargeback window — confirmed authorisations are final, and refunds are merchant-initiated rather than buyer-disputed. There are still fraud and dispute vectors (social-engineering scams in particular, which Brazilian regulators have addressed through the MED — Mecanismo Especial de Devolução — process for genuine fraud cases), but the everyday chargeback cycle that card carries does not apply.

  8. 08

    How are PIX refunds handled through the API?

    PIX refunds are merchant-initiated via the same refund endpoint as card. The connected provider initiates a return PIX to the originating account on BCB rails — the refund clears in seconds. Partial refunds are supported. Refund operations log the operator identity, reason code and the BCB end-to-end IDs for audit.

  9. 09

    Can a non-Brazilian merchant accept pix payment?

    Yes — a non-Brazilian merchant accepts PIX through topropay's connected provider; the underlying Brazilian payment-institution licence sits with the provider. Settlement currency is a policy choice: hold BRL, or convert on receipt to the merchant's home currency at the rail's quote. Most cross-border merchants pick conversion-on-receipt.

  10. 10

    What about recurring PIX — is that supported?

    PIX-Recorrência (recurring PIX) is supported where the connected PIX provider exposes it. Where it is not, the typical pattern is PIX first-charge plus card-on-file for renewals, or PIX-on-due-date with merchant-side dunning. topropay's recurring-payment engine handles either pattern through the same API.

  11. 11

    How does the pix payment gateway return responses?

    The pix payment gateway response shape mirrors the card response: an authorisation ID, a status (pending_bank_confirmation initially, then authorised on bank credit), an end-to-end ID once the BCB SPI clears it, and a settlement reference once funds land in the merchant's settlement account. Webhooks fire on each state change.

  12. 12

    How long does the buyer take to pay via PIX?

    Median completion time on PIX is in the order of seconds to a minute, depending on the buyer's bank app and the buyer's behaviour. The merchant configures a 'await window' (commonly 5-15 minutes); if the buyer doesn't pay inside that window, the authorisation expires and a new QR is issued on retry.

  13. 13

    What's the typical PIX fee on the platform?

    PIX carries a per-transaction fee from the underlying provider, plus topropay's per-authorisation platform fee — both pass through transparently on the invoice. The combined cost is meaningfully lower than card for the same BRL-denominated authorisation, especially on smaller tickets where flat-fee PIX wins decisively against percentage-based card interchange.

  14. 14

    Are there geographies where PIX is relevant beyond Brazil?

    PIX is a Brazilian domestic rail — the BCB SPI infrastructure does not clear cross-border. Some neighbouring regulators have referenced PIX as a model for their own instant rails (e.g. Mexico's CoDi has similar shape), but PIX itself is BR-only. For cross-border, topropay supports international payouts and FX as separate flows.

  15. 15

    How is pix payment supported in the sandbox?

    The sandbox exposes the full PIX flow: dynamic QR generation, simulated bank-confirmation outcomes (success, pending, expired, failed), webhook replay, refund-flow testing. The error model is identical to production; the merchant can build the full integration against the sandbox before any commercial commitment.

Related

Related on the topropay platform