Reading the E-Dinheiro Social ledger: balance, extrato, transfers and Pix interno

Behind one E-Dinheiro Social account sits a pre-paid payment ledger that records far more than a balance: every transfer, internal-Pix movement, boleto, mobile recharge, merchant purchase in the accredited network, and municipal benefit credit lands as a posted line. At Banco Palmas alone the platform reportedly carries around 20,000 digital accounts and over 3,000 accredited merchants, moving close to R$1 million in the local economy during 2025 according to press coverage — and that is one of dozens of community deployments. That ledger is what an integrator wants to read.

The practical way in is an SDK we build and hand over: a small client that speaks the app's own authenticated session, then exposes balance and statement reads as ordinary function calls. Where the institution behind a given community currency takes part in Open Finance Brasil, a regulated consent read sits underneath as the durable layer. Both rest on the same thing — the account holder authorizing the pull.

What the account actually holds

These are the surfaces the app exposes to a logged-in holder, named the way the platform names them where possible.

Authorized ways to reach it

Three routes genuinely apply to this platform. They are not exclusive; a delivered build usually combines them.

Authorized interface integration of the session

We analyse the app and internet-banking traffic of a consenting account and map the login handshake, token and cookie chain, and the calls behind the balance and extrato screens. This reaches every surface in the table above and is what makes the SDK runnable today. Effort is moderate; durability is good as long as we re-check after platform updates, which we fold into maintenance.

Open Finance Brasil consent

Pre-paid payment accounts are in scope for Open Finance Brasil, so where the institution behind a community currency is an authorized participant, a regulated AIS-style consent read is the most durable layer. Coverage depends on that institution's participation, so we treat it as a layer to add rather than the spine.

User-consented credential access

The simplest basis: the account holder authorizes the read directly, and the client operates under that authorization with consent recorded. This is the fallback where neither of the above is set up yet, and it is enough to start delivering data.

For most buyers the session-integration route is the one we would build first, because it reaches the full ledger now and does not wait on an institution's Open Finance onboarding; the regulated layer goes on top where it exists.

What lands in your repo

The headline deliverable is code that runs against this app's surfaces, not a document about it.

• A runnable client library (Python and/or Node.js) that owns the session handshake and exposes balance(), statement() and transfer reads as typed calls, with cursor paging on the extrato baked in.
• Webhook or polling handlers for fresh postings, with idempotent processing so a re-run over the same statement window never writes a transaction twice.
• An automated test suite that exercises login, paging and the rail-tagging logic against recorded fixtures, so a platform change shows up as a red test.
• A normalized record schema mapping E-Dinheiro's mixed ledger into one shape across communities.
• Secondary, and included: an OpenAPI/Swagger description of the mapped surfaces, a protocol and auth-flow write-up (token and cookie chain as it behaves here), interface documentation, and data-retention guidance under LGPD.

How the client reads a statement

Illustrative shape of the delivered Python client; exact paths and field names are confirmed against the live session during the build.

from edinheiro_client import EdinheiroSession   # delivered SDK

# the app's own login handshake, mapped during the build
sess = EdinheiroSession.login(cpf=CPF, pin=PIN)        # -> token + cookie chain

# balance for one community wallet, to the cent
print(sess.balance(wallet_id).amount_cents)

# extrato, paged by cursor for delta sync
page = sess.statement(wallet_id, since="2026-04-01")
for tx in page.entries:
    # rail in: pix_interno | transfer | boleto | recarga | merchant | benefit
    record(tx.id, tx.posted_at, tx.rail, tx.amount_cents,
           tx.counterparty, tx.program)   # program set only on benefit credits

while page.next_cursor:                     # pull only what is new
    page = sess.statement(wallet_id, cursor=page.next_cursor)
    for tx in page.entries:
        record(tx.id, tx.posted_at, tx.rail, tx.amount_cents,
               tx.counterparty, tx.program)

Where this gets used

• A merchant network operator reconciling Pix-interno and benefit credits across several community currencies from one normalized feed.
• A bookkeeping tool pulling a household's extrato so social-rent and food-aid credits are categorized apart from ordinary transfers.
• A municipal program dashboard tracking how a basic-income credit circulates after disbursement, read through the consenting accounts.

Consent and LGPD

This is a Brazilian platform, so the governing privacy regime is the Lei Geral de Proteção de Dados (LGPD), and the supervisory frame for the payment arrangement is Banco Central do Brasil. The dependable legal basis on every build is the account holder's explicit, scoped consent: we record what was consented to, for which wallets, and for how long, and we honour revocation by stopping reads and purging cached records. Where Open Finance Brasil applies, consent expiry and renewal follow that scheme's windows. We minimize what we store — typically statement records and balances, not credentials — and operate under NDA where the engagement calls for it.

Things we handle on this platform

Two specifics shape the build, and we account for both rather than leaving them to you.

• Per-community segregation. The social currencies circulate only within their own territory and each community is effectively its own currency on the shared platform. We key every read on the community and wallet identifier so a multi-community pull keeps balances and statements separate and never sums across territories that do not share a currency.
• A ledger that mixes rails. Internal Pix inside the accredited network, ordinary transfers, boleto, recharge, and municipal benefit credits all post into the same extrato. We tag each entry by rail and preserve the benefit-program label, so reconciliation treats a food-aid credit and a peer transfer as the different things they are.
• Posting lag from offline origins. The platform was designed to work on phones without internet, so some movements originate over SMS or USSD and settle later. We design the sync around that posting delay instead of assuming every transaction is visible the instant it happens.

Access to a consenting account or a sponsor environment is arranged with you during onboarding; the build runs against that consenting account, and the credentials and authorizations are set up together as the first step of the work.

Interface evidence

App screens from the Play listing, for reference during mapping.

Related wallets in the same space

Brazilian social-currency and digital-wallet apps an integrator often maps alongside this one. Several run on the same shared platform, which makes a single normalized feed realistic across them.

• Mumbuca — Maricá's municipal social currency, one-to-one with the real, holding benefit credits and local merchant payments on the same e-dinheiro base.
• Moeda Social Arariboia — Niterói's basic-income currency, carrying program credits and merchant transactions; press reports it has circulated more than R$82 million.
• Caixa Tem — Caixa's government-benefit wallet, holding balances, Pix and benefit disbursements for the underbanked.
• PicPay — a super-app wallet with P2P transfers, a digital account and a transaction history.
• Mercado Pago — payments and digital account from Mercado Libre, holding balances, transfers and merchant records.
• Nubank — a large digital bank with accounts, statements and card ledgers behind login.
• RecargaPay — bill, boleto and recharge payments with a prepaid card and transaction records.
• PagBank — a digital account with balances, transfers and card activity.

Integrator questions

Can the integration ship as a Python or Node.js client instead of raw endpoints?

Yes, and that is the default. We deliver a small client library that owns the E-Dinheiro session handshake, exposes balance and statement reads as typed calls, and pages the extrato by cursor so a delta sync only pulls new postings. You import it, pass the consenting account's credentials, and read records; the auth and paging mechanics stay inside the library.

Does a statement pull keep internal Pix, external transfers and social-benefit credits apart?

It does. The platform mixes Pix interno within the accredited merchant network, ordinary transfers, boleto and recharge payments, and municipal benefit credits in one ledger. We tag each entry by rail and preserve the benefit-program label so reconciliation does not conflate a food-aid credit with a peer transfer.

Where does Open Finance Brasil fit against direct interface integration here?

Pre-paid payment accounts are in scope for Open Finance Brasil, so where the institution behind a given community currency participates, a regulated consent read is the durable layer. In practice the dependable basis is the account holder's own authorization, and authorized interface integration of the app's session reaches the same balance and statement surfaces today. We build on the consent and add the regulated path where it is available.

We run several community currencies on the platform; does one integration cover all of them?

Yes. The currencies are segregated by community and circulate only within their territory, so we key reads on the community and wallet identifier and return one normalized record shape across all of them. Adding another community currency later is a configuration change, not a new build.

Sources checked

Mapped on 31 May 2026 against the operator's own platform material and primary coverage: the E-Dinheiro funcionamento page for the service set (balance, statement, withdrawal, deposit, payments, transfers), the Instituto E-Dinheiro Brasil platform site for the community-currency model, Let's Money for the ~20,000-account and internal-Pix figures, and the Open Finance Brasil participation model for the pre-paid-account scope. Figures are reported by those sources, not independently audited here.

Working with us

A first E-Dinheiro Social statement-sync client typically lands inside one to two weeks. Buy the source outright from $300 and you receive the runnable client, its tests and interface docs, paying only after delivery once it works for you. Prefer nothing upfront? Call our hosted endpoints and pay per call instead. Either model starts the same way: tell us the app name and what you want out of its data, and the access and consent setup is handled with you as part of the work. Start a conversation on the contact page and we will scope it.