Pulling balances, settlements and payouts out of Mollie

A Mollie business account splits every balance into a pending amount and an available amount, and an integrator almost always needs both kept apart. Money marked paid is not yet money you can pay out. That single distinction shapes how a clean feed off Mollie has to be built — and it is the first thing a generic connector gets wrong.

The records sit behind an authenticated session: a merchant logs in, sees per-currency balances, a transaction ledger, settlements landing in their external bank account, payment links, and a financing area. Reaching that data for a third party is a consent-and-interface problem with a clear regulatory frame around it, because Mollie B.V. is a supervised Dutch payment institution. This brief sets out what is there, the authorized way in, and what we hand back.

The records behind a Mollie business account

Mapped to how the app itself names things, the surfaces worth integrating are these.

PSD2, DNB, and consented access to Mollie data

Mollie B.V. appears on the De Nederlandsche Bank public register as a payment and electronic-money institution, with the AFM as conduct authority. The relevant open-banking instrument is PSD2, the EU Revised Payment Services Directive. Where the Mollie account is in scope of account information services, a consented read is a regulated path: the account holder authenticates, grants scope, and the access is logged.

Two regulatory details drive the engineering. Account information access expires and requires strong customer authentication again on a fixed interval — 90 days under the original rule, which the EBA extended to 180 days for account information services. And consent is scoped and revocable, so a sync must hold a consent record, honour revocation, and pull only the domains the account holder agreed to. We treat compliance as how we operate: authorized or user-consented access only, request and consent logging, data minimization to the fields you actually need, and an NDA where the work touches your environment. None of that is something you have to clear before we start — it is arranged with you as the project runs.

Getting to the data: the routes that fit Mollie

Authorized interface integration on a consenting account

The broadest coverage of Mollie's own objects — the two-part balance, the typed transaction ledger, settlements with their covered batch — comes from working the app's authenticated traffic under the account owner's authorization. Effort is moderate; durability is good with light upkeep, since the data model is stable even when the front end shifts. We set up the consenting account and access with you during onboarding.

PSD2 account-information consent

Where account information services apply, a regulated consent read is the most durable path and the cleanest on audit. It is consent-scoped and subject to the reauthentication window above, so coverage is narrower than the interface route but the access story is the strongest. We handle the consent flow setup as part of the build.

Native export as a fallback

Mollie's dashboard produces a balance report you can export. It is lower fidelity and not real time, useful as a reconciliation cross-check or a stopgap, not as the spine of a live feed.

For most teams we would build on the interface route for breadth and add the PSD2-consent path where the regulated, long-lived access record matters to your compliance side. The export stays in as a verification check, not the primary source.

A balance-transaction pull, in practice

Illustrative shape of the work; exact field names are confirmed against the live session during the build.

# Authorized interface integration - consenting Mollie account
session = mollie_session(consenting_account)     # PSD2 AIS consent or owner-authorized login

for b in session.get("/balances"):               # one entry per currency
    cur   = b["currency"]                         # e.g. "EUR" - one of 25+ link currencies
    avail = b["availableAmount"]["value"]         # settled, payable out
    pend  = b["pendingAmount"]["value"]           # marked paid, not yet on the balance

    tx = session.get(f"/balances/{b['id']}/transactions", params={"limit": 250})
    for t in tx["items"]:
        # t["type"] in {payment, refund, chargeback, settlement, capital, ...}
        emit({
          "currency":  cur,
          "type":      t["type"],
          "result":    t["resultAmount"]["value"],          # signed effect on the balance
          "ref":       t.get("context", {}).get("paymentId"),
          "booked_at": t["createdAt"],                       # ISO 8601
        })

# settlement -> the batch it covers, for bank-statement reconciliation
for s in session.get("/settlements"):
    reconcile(s["reference"], s["amount"], s["settledAt"],
              session.get(s["_links"]["transactions"]))

# re-prompt before the PSD2 reauthentication window closes
on_consent_expiry(lambda: trigger_sca_reconsent())

What lands in your repo

Each deliverable is tied to a real Mollie surface, not a generic checklist.

• An OpenAPI/Swagger specification covering the balance, transaction, settlement and payment-link reads as we model them.
• A protocol and auth-flow report: the session and token chain, the PSD2 consent and reauthentication handling, and how revocation is detected.
• Runnable source for the key endpoints in Python and Node.js — the balance split, the typed transaction ledger, settlement-to-batch mapping.
• Automated tests, including the pending-versus-available case and the settlement reconciliation path.
• A normalized schema keyed by organization and currency, so multi-entity setups stay attributed.
• Interface documentation plus data-retention and consent-record guidance matched to PSD2.

What we account for on a Mollie build

These are the things this specific app makes you get right, and we handle them as method, not as homework for you.

• The two-stage balance. Pending and available are different money. We model them as separate fields per currency so a downstream ledger never books funds that are marked paid but not yet settled.
• Multi-currency by design. Payment links span 25+ currencies and balances are per currency. We key the schema by currency and carry FX at settlement, not at capture, so converted figures stay truthful.
• The reauthentication window. We design the sync around the PSD2 SCA interval and surface a re-consent prompt ahead of expiry, so a long-running feed does not lapse without warning.
• Settlement reconciliation. Each settlement maps to the exact batch of transactions it covers, so it lines up with the receiving bank statement rather than landing as one opaque lump.
• Drift monitoring. A standing check flags when the session flow or response shape moves, and we refresh the adapter as part of upkeep — access for that is arranged with you, never a precondition you have to satisfy first.

Where teams point a Mollie integration

• An accounting or ERP feed: balance transactions and settlements pushed into the bookkeeping system so reconciliation stops being manual.
• A treasury view: real-time multi-currency cash position across Mollie balances and the bank accounts they settle to.
• A platform or marketplace: balances, payouts and transactions aggregated across many onboarded Mollie organizations, each kept distinct.
• Underwriting context: settlement history and turnover used as input to a credit or cash-flow model.

Screens we worked from

Public store screenshots used while mapping the surfaces. Select to enlarge.

Peer platforms in the same integration space

Same-category products an integrator commonly evaluates alongside Mollie, listed for ecosystem context rather than ranking. Adyen is another Dutch payment platform, holding online, point-of-sale and marketplace settlement data at large scale. Stripe carries payments, balances, payouts and subscription records across a wide country footprint. GoCardless centres on bank-debit and recurring collection data with strong open-banking ties. Unzer, a German provider, holds online, terminal, pay-by-link and instalment records. Viva Wallet, based in Greece, holds card-acceptance and account data across European merchants. Quickpay, from Denmark, holds card, wallet and pay-by-link transactions through CMS integrations. PayPal holds balances, transfers and transaction history for business accounts. Noda holds account-to-account and open-banking payment data for e-commerce. A unified integration over several of these normalizes their transaction and settlement records into one schema, which is the same problem this Mollie work solves on one platform.

How this brief was put together

Compiled in May 2026 from Mollie's own store listing and product pages, the De Nederlandsche Bank public register and its PSD2 and account-information guidance, and current EBA/regulator material on the SCA reauthentication window. Primary sources opened:

• De Nederlandsche Bank public register — Mollie B.V.
• De Nederlandsche Bank — PSD2 overview
• De Nederlandsche Bank — what an account information service is
• Mollie — Google Play listing

Mapped by the OpenBanking Studio integration desk, May 2026.

Questions integrators ask about Mollie

Can you keep Mollie's pending and available balance separate in the feed?

Yes. A Mollie balance carries a pending amount (payments marked paid but not yet on the balance) and an available amount (settled, payable out). We model them as distinct fields per currency so a downstream ledger never books the same money twice.

How does PSD2 reauthentication affect a long-running Mollie data sync?

Account information access under PSD2 expires and needs strong customer authentication again on a fixed interval — 90 days, which the EBA extended to 180 days for account information services. We build the sync to detect that window and trigger a re-consent prompt before it lapses, so the feed does not silently go stale.

Do Mollie settlements line up with what hits our external bank account?

A settlement is one transfer of balance funds to your bank account, and it carries the batch of balance transactions it covers — payments, refunds, chargebacks. We map each settlement to that batch so it reconciles against the bank statement line for line.

Can one integration cover several connected Mollie organizations?

Yes. Where you operate a platform or marketplace with multiple onboarded Mollie organizations, we key the normalized schema by organization and currency so balances, settlements and transactions stay attributed per entity rather than merged.

Working with us

Source for the Mollie surfaces you need — the balance split, the typed ledger, settlement mapping — ships in one to two weeks. You can take it as delivered source code from $300, paid after delivery once it runs against your own data and you are satisfied; or call our hosted endpoints and pay per call, with no upfront fee. You give us the app name and what you want out of it; the consenting account, access and compliance side is arranged with you as the work runs. Start the conversation at our contact page.