Pulling balances, Pix and card data out of RecargaPay

RecargaPay carries a conformity certificate in Open Finance Brasil, registered as RecargaPay Instituição de Pagamento Ltda — the route into its account data starts there, not with the app binary. It runs as a payment institution under Banco Central do Brasil, with a Direct Credit Company licence it picked up in 2021 and, per Brazilian fintech reporting, an authorization to operate as a finance company (financeira) published in the Official Gazette in late 2024. The app describes more than 13 million users. For an integrator, the useful consequence of all that is simple: a regulated, consented path to the same balances, Pix movements and statements a RecargaPay customer sees in the app.

So for this one the cleaner way in is the regulated one. RecargaPay already sits inside Open Finance Brasil, which means consented access through the standardized accounts, credit-card and investment data sets returns balances, Pix history and CDB positions without anyone reverse-engineering the client. Where you need something that sits outside those standardized categories — say the Tap-to-Pay receivable breakdown or the referral-cashback ledger — we add authorized analysis of the app's own traffic under your mandate. The rest of this brief is which surfaces hold what, how each route behaves, and what we hand over.

Consent under Open Finance Brasil and the LGPD

Open Finance Brasil is the Banco Central scheme that lets a customer share their financial data with a third party they choose. Access is gated by an explicit consent: a consent record is created, the customer authorizes it, and only the data categories they ticked become readable. Consents carry a defined validity and can be revoked by the customer at any time, which the integration has to respect rather than cache around. We keep a consent and access log on our side, store nothing outside the agreed scope, and work under an NDA where the engagement calls for one.

Personal data sits under the LGPD, Brazil's general data-protection law, so purpose limitation and data minimization are part of the design and not an afterthought. The dependable legal basis here is the customer's own authorization — the consent they grant through Open Finance, or, on the traffic-analysis route, the mandate the account holder gives you. We build to that basis and document it alongside the code.

What RecargaPay holds behind the login

These are the surfaces worth integrating, named the way the app names them. Granularity below reflects what is realistically reachable through consented access or authorized analysis.

Getting to the data: the regulated route and the authorized one

Consented Open Finance Brasil access

This is the route we recommend for RecargaPay, because the participation is already in place. You reach the standardized accounts, credit-card, loans and investments data sets over the scheme's FAPI security profile, which is OAuth 2.0 and OpenID Connect with mutual-TLS and signed requests on top. What is reachable is exactly the consented categories; durability is high because the APIs are versioned and regulated rather than scraped. The directory registration and client certificates are work we set up with you during onboarding — or we run the build against a consenting account or sandbox while that completes.

Authorized analysis of the app's own traffic

The second route covers what the standardized data sets leave out — Tap-to-Pay receivable detail, the referral-cashback ledger, top-up and transport-recharge history exactly as the app presents it. Here we capture and document the client-server protocol, including the token and session chain, under the account holder's authorization, and build a client against it. Reach is broad; durability is lower, since a front-end change can shift a payload. When that happens we re-capture and update the parsers — keeping the integration current is part of the engagement, not a separate project. As a low-effort supplement, the app's own in-app statements (extratos and comprovantes) can be ingested where a one-off historical backfill is all that's needed.

A consent-then-fetch call, sketched

Shape of a balance read on the regulated route — consent first, then a FAPI-secured fetch carrying the consent reference in scope. Field names follow the Open Finance Brasil data model; values are illustrative and confirmed against live responses during the build.

# 1) Create a consent for the categories you actually need
POST /open-banking/consents/v3/consents
Authorization: Bearer <client_credentials_token>   # mTLS client cert required
x-fapi-interaction-id: 2b9e...c1
{
  "data": {
    "permissions": ["ACCOUNTS_READ", "ACCOUNTS_BALANCES_READ",
                    "CREDIT_CARDS_ACCOUNTS_READ", "RESOURCES_READ"],
    "expirationDateTime": "2026-09-11T00:00:00Z"
  }
}
# -> { "data": { "consentId": "urn:recargapay:c-3f9...", "status": "AWAITING_AUTHORISATION" } }

# 2) Customer authorises (redirect / OIDC). Token now carries the consent scope:
#    scope = "openid accounts credit-cards-accounts consent:urn:recargapay:c-3f9..."

# 3) Read balances once status == "AUTHORISED"
GET /open-banking/accounts/v2/accounts/{accountId}/balances
Authorization: Bearer <access_token_with_consent_scope>
x-fapi-interaction-id: 2b9e...c1

# 200 OK
{ "data": {
    "availableAmount":      { "amount": "1843.55", "currency": "BRL" },
    "blockedAmount":        { "amount": "0.00",    "currency": "BRL" },
    "automaticallyInvestedAmount": { "amount": "512.00", "currency": "BRL" } } }

# Error to handle explicitly: consent revoked or lapsed
# 403 { "errors": [ { "code": "STATUS_RESOURCE_CONSENT_MISMATCH" } ] }  -> re-consent flow
      

What lands in your repo

The deliverable is the working integration, not a report about one. For RecargaPay that means:

• An OpenAPI / Swagger spec covering the endpoints you actually need — balances, transactions, card statements, investment positions, payment records.
• A protocol and auth-flow write-up: the FAPI consent dance and token scoping for the regulated route, or the captured token/session chain for the traffic route.
• Runnable source for the key endpoints in Python or Node.js — consent creation, token refresh, the account and transaction clients, with retry and the revoked-consent path wired in.
• A normalized data model so a RecargaPay balance, a card line and a CDB position land in the same shape as any other source you aggregate.
• Automated tests against recorded fixtures, plus interface documentation and data-retention guidance keyed to the LGPD basis the access runs on.

Notes we carry into a RecargaPay build

Two things shape this integration more than the generic pattern would suggest, and we account for both up front.

First, the consent window. Open Finance consents expire and can be pulled by the customer, so a sync that assumes a standing connection will quietly go dark. We design around the consent-refresh cycle — tracking expiry, prompting re-consent before it lapses, and treating a revocation as a first-class state rather than an error to swallow. Transaction reads are paged and date-bounded by the scheme, so the client pages to completion instead of trusting a single response to be the whole history.

Second, CPF versus CNPJ. RecargaPay runs a personal account and a free PJ account with different product surfaces — only the business side carries Tap-to-Pay receivables and merchant sales balances. We scope the consent and the data model per account type, so a business customer's settlement data and a personal customer's wallet yield are each mapped correctly rather than forced into one schema. Access for either is arranged with you during onboarding; the build runs against a consenting account or a sandbox.

Where this gets used

• A personal-finance app folding a user's RecargaPay wallet, Pix and card spend in beside their other Brazilian accounts, all through one consented Open Finance connection.
• An accounting or ERP sync pulling a PJ account's Tap-to-Pay receivables and boleto payments straight into the books, so reconciliation stops being manual.
• A lender reading consented balance and cash-flow history to underwrite — the same Open Finance signal RecargaPay itself uses to build credit scores, pointed the other way.

Screens we worked from

Store screenshots used to read the app's surfaces. Tap any to enlarge.

Other Brazilian wallets in the same integration picture

Teams reaching RecargaPay data usually want the neighbouring accounts mapped to one schema too. The names below come up in the same category, each with the data it holds.

• Nubank — account balances, card statements, Pix history and investment positions, all behind a single login.
• Mercado Pago — wallet balances, P2P and Pix transfers, merchant receivables and QR-code payment records tied to Mercado Libre accounts.
• PicPay — P2P transfers, digital-account balances, and card and bill-payment records across a large consumer base.
• PagBank — personal and merchant accounts with card-acquiring receivables, balances and Pix flows, from its PagSeguro roots.
• C6 Bank — full-service account data: balances, statements, card limits, investments and Pix keys.
• Banco Inter — banking, card, investment and marketplace records consolidated in one account.
• iFood Pay — wallet balances and payment records tied to the iFood delivery ecosystem.
• iugu — payments-infrastructure accounts holding merchant transaction, invoice and payout records.

Questions integrators ask about RecargaPay

Does RecargaPay's Open Finance participation cover business (PJ) accounts as well as personal (CPF) ones?

RecargaPay runs both a personal account and a free PJ (business) account, and its Open Finance Brasil registration is at the institution level, so consented access can be set up for either CPF or CNPJ holders. The product sets differ — a PJ account carries Tap-to-Pay receivables and merchant balances a personal wallet does not — so we scope the consent and the data model per account type rather than assuming one shape fits both.

How far back does RecargaPay transaction history reach through consented access?

Open Finance Brasil bounds how much history a transactions call returns and pages the rest, so a first pull gives a recent window and older records arrive through follow-up requests. The exact window depends on the data category and the participant's implementation, which we confirm against the live response during the build rather than stating a fixed number here.

Can the integration capture Pix-with-credit-card and CDB investment positions, not just the wallet balance?

Yes. Balances and Pix movements come through the accounts and payments data sets, card activity including installment and cashback detail through the credit-card data set, and CDB holdings through the investments data set. Where a surface sits outside the standardized Open Finance categories — the referral-cashback ledger, for instance — we capture it through authorized analysis of the app's own traffic under your mandate.

If standing up Open Finance directory certificates is not practical for us, is there another route into RecargaPay?

There is. We can integrate through documented analysis of the app's own client-server traffic against a consenting account, which reaches whatever the app shows its user and does not depend on directory onboarding. The certificate and onboarding work for the regulated route is something we arrange with you when that path is the better fit; you are not expected to have it ready first.

Sources and how this was put together

Checked in June 2026 against RecargaPay's own Open Finance regulation and consent page, the Open Finance Brasil participant directory, Brazilian fintech reporting on its Banco Central authorizations, and the FAPI security profile that governs the scheme's data APIs.

• RecargaPay — Open Finance regulation & consent
• Open Finance Brasil — participant directory
• Finsiders — RecargaPay authorized by Banco Central to become a financeira
• Open Banking Brasil — Financial-grade API (FAPI) security profile

Mapped by the OpenBanking Studio integration desk, June 2026.

Working with us

A RecargaPay build typically runs one to two weeks once we agree the data scope. You can have it as runnable source — the OpenAPI spec, the consent and token-refresh code, the account, card and investment clients, the tests and the interface docs — from $300, paid only after delivery once you are satisfied. Or skip the code and call our hosted endpoints instead, paying per call with nothing upfront. You give us the app name and what you want out of its data; the access, certificates and compliance paperwork are arranged with you as part of the work. Start at /contact.html.