Pulling balance and transaction history out of a Satispay account

Satispay runs its own PSD2 access-to-account interface — a consent-negotiation flow and an account-information flow, published as an OpenAPI file at openbanking.satispay.com. That is the spine of any integration here. Underneath the wallet sits a virtual account with its own IBAN, a spendable balance topped up from the user's bank, and a dated record of every payment, transfer, and reward. Over 6,000,000 people use it, per Satispay's Play listing. The data a third party usually wants — current balance, transaction history, the Satispay Invest holdings — is reachable through a route that is already regulated, which is unusual and makes this a clean job.

Reaching a Satispay account through access-to-account

Satispay Europe is a CSSF-regulated electronic money institution, per the regulatory note in its own store listing, which means it has to expose an XS2A (access-to-account) interface under PSD2. We treat that as the primary route. Two routes apply in practice; a third is a fallback.

1. Regulated AIS over XS2A

The interface follows the Berlin Group NextGenPSD2 model: a TPP negotiates an account-information consent, then reads the list of accounts, the balance, and transaction history. Reachable: account identifier and IBAN, current and available balance, booked and pending transactions with timestamps and counterparties. Effort is moderate and the durability is high — it is a maintained, standards-based surface, not a screen we have to chase. What we set up: the AISP authorization and the eIDAS QWAC/QSEAL certificates the interface requires, arranged on our side, plus the sandbox account Satispay provides for the build.

2. Consented protocol analysis of the app session

For surfaces the AIS scope does not carry — Satispay Points, Money Box goals, Pay-in-3 schedules, the per-fund Satispay Invest view — we map the app's own authenticated traffic against a consenting account. Reachable: anything the user sees in-app. Effort is higher and it needs a re-validation pass when the front end shifts, but it reaches data the regulated scope was never meant to expose.

3. In-app receipts and downloads

Satispay lets a user download transaction receipts from the profile. That is a thin fallback for one-off reconciliation, not a feed, and we only reach for it when a live connection is not wanted.

For most teams the first route carries the work: it is the durable, regulated path to balance and statement data. We add the second only when the brief needs loyalty or investment detail that the AIS scope leaves out.

What sits behind a Satispay login

The figures above — the store count, the user count — come from Satispay's own marketing copy and are quoted, not independently audited.

What lands in your repo

The handover is built around the surfaces above, not a generic kit.

• An OpenAPI/Swagger spec for the endpoints we wire — accounts, balance, transactions on the AIS side, plus any session calls mapped for the loyalty or investment view.
• A protocol and auth-flow report: the consent negotiation, the SCA redirect, token lifetime, and the QWAC/QSEAL handshake as they behave against a live Satispay account.
• Runnable source for the key endpoints in Python and Node.js, with a normalized record so balance and transactions come out in one shape regardless of route.
• Automated tests against the sandbox and a consenting account, covering consent expiry and the Italy-only rails.
• Interface documentation and data-retention guidance keyed to the CSSF/PSD2 posture below.

A consent-then-read call sequence

Illustrative, in the Berlin Group shape the interface follows; field names are confirmed against the live flow during the build.

# 1. Negotiate an account-information consent (mutual TLS with the eIDAS QWAC)
POST /v1/consents
  TPP-Redirect-URI: https://app.example/cb
  {
    "access": { "balances": [], "transactions": [] },
    "recurringIndicator": true,
    "validUntil": "2026-12-04",
    "frequencyPerDay": 4
  }
-> 201 { "consentId": "c-7f3a...", "_links": { "scaRedirect": "https://auth.satispay..." } }

# 2. User authenticates (SCA); consent moves to "valid"

# 3. Read the accounts, then balance + transactions
GET /v1/accounts                       Consent-ID: c-7f3a...
GET /v1/accounts/{id}/balances         Consent-ID: c-7f3a...
GET /v1/accounts/{id}/transactions?bookingStatus=both&dateFrom=2026-01-01

# Refresh path: re-trigger SCA before the consent window lapses,
# rather than letting an always-on feed go silently stale.
      

Consent scope, the CSSF, and how revocation behaves

Satispay's payment side is regulated by the CSSF in Luxembourg and its investment arm, Satispay Invest, is a separately authorized investment firm — both stated in the app's own regulatory footnote. The dependable basis for access is the account holder's PSD2 consent: it names the data categories, carries a validity window, and the user can revoke it from their side at any time, which immediately ends our read. The EBA technical standards require periodic re-authentication of that consent, so a standing feed is designed around the refresh, not assumed to be permanent. We run access authorized and logged: consent records retained, data minimized to the fields a project actually needs, and an NDA in place where the work touches anything sensitive. Where the second route is used, it runs against a consenting account, not an unconsented one.

Things we account for on a Satispay build

• Two licensed entities, two surfaces. The wallet ledger sits under Satispay Europe and the fund holdings under Satispay Invest. We model them as separate sources and join on the account, so a portfolio view and a statement view stay consistent instead of being forced into one feed.
• Italy-only rails. Road tax, MAV bills, and pagoPA notices are flagged Italy-only in the listing. We tag those transaction types explicitly so the parser does not assume them and degrades cleanly for accounts that never produce them.
• Consent refresh, not consent decay. Because the AIS consent re-authenticates on a window, we build the refresh into the sync schedule and surface a clear state when a user needs to re-confirm — the feed never expires quietly.
• Front-end drift on the session route. When we map app traffic for loyalty or investment detail, we wire a re-validation step into maintenance so a layout change is caught and patched rather than silently dropping fields.

Access, the sandbox, and the certificates are arranged with you as part of the engagement — nothing here is a gate you clear before we begin.

Where this plugs in

• A budgeting or PFM product that wants a user's Satispay balance and transactions alongside their bank accounts in one aggregated view.
• An accounting tool reconciling a merchant's or freelancer's Satispay receipts against invoices.
• A wealth dashboard pulling Satispay Invest contributions and fund positions into a household portfolio.

Screens we mapped

Store screenshots used while scoping the surfaces above. Tap to enlarge.

What we checked, and when

Scoped on 2026-06-04 against Satispay's own open-banking documentation and store listing, plus the Berlin Group framework its interface follows. Sources we opened: Satispay Open Banking — getting started, Berlin Group XS2A framework, the Google Play listing, and Satispay's "how it works" page. Mapped by the OpenBanking Studio integration desk, June 2026.

Other wallets in the same data neighbourhood

Useful when a project needs Satispay alongside its peers under one schema. Listed for context, not ranked.

• Revolut — multi-currency accounts, cards, and investment holdings behind an authenticated app; a frequent aggregation target in Italy.
• BANCOMAT Pay — account-to-account payments tied directly to a user's bank account.
• PostePay — Poste Italiane's prepaid and wallet app, with balance and transaction records.
• Hype — an Italian payment account with its own IBAN, transfers, and card spend.
• Tinaba — current account, prepaid card, and investments run with Banca Profilo.
• N26 — a licensed mobile bank exposing balances, statements, and spaces.
• Nexi Pay — links cards for contactless and installment payments, holding transaction data.
• PayPal — wallet balance, transfers, and transaction history behind a login.

Questions integrators ask about Satispay

Can you separate Satispay's wallet ledger from the Satispay Invest holdings?

Yes. Payments run under Satispay Europe S.A. and investing under Satispay Invest S.A., two licensed entities per the app's own regulatory note, so the spendable balance and the fund holdings come from different surfaces. We model them as two sources and join them on the account, then hand you a normalized record.

Does the access-to-account consent cover transaction history, or only the live balance?

A PSD2 account-information consent can carry both: the list of accounts, the current balance, and dated transaction history. The standards require periodic re-authentication of that consent, so for an always-on feed we build the consent refresh into the sync rather than letting it lapse.

Will pagoPA and road-tax payments show up for a non-Italian account?

No. Road tax, MAV bills, and pagoPA notices are flagged Italy-only in Satispay's own listing, so they appear only on Italian accounts. Our transaction parser tags those rails explicitly and degrades cleanly for accounts that never see them.

Do we need our own AISP licence to use a Satispay feed?

No — that is arranged on our side. The build runs as a licensed AISP or under a sponsor's licence, with the eIDAS certificates set up during the engagement; you give us the app name and what you want from its data. Start at /contact.html.

Source-code delivery starts at $300, billed only after the Satispay integration is in your hands and working as described; the alternative is our hosted endpoints, where you call the API and pay per call with nothing upfront. Either build runs in one to two weeks. Tell us the app and what you need from its data at /contact.html.