Reaching Wero's account-to-account payment data

Around 40 million people had registered for Wero by early 2026, according to industry coverage, and every one of those accounts is a phone number or alias bolted onto a real bank account. That is the thing worth integrating. Wero, run by the European Payments Initiative and launched in July 2024 (per Wikipedia), is not a stored-value wallet — it moves money directly between bank accounts over SEPA Instant Credit Transfer in seconds. So the data you would want to read sits in two places at once: in the linked bank account, and in Wero's own session. We build the connection that reads both and reconciles them.

The bottom line: most of the money movement is reachable through a regulated Account Information Service connection to the underlying bank account, where Wero transfers appear as instant credit transfers. The Wero-specific context — which request a payment answered, who the counterparty was, whether a QR code or phone alias triggered it — comes from reading the app's authorized traffic. We would run the AIS connection for the ledger and protocol analysis for the labelling, then reconcile the two into one feed. The rest of this page is how that gets built and what lands in your repository.

What Wero holds, and where each piece lives

These are the surfaces the app actually exposes to a logged-in user. The granularity column is what an integrator can realistically expect to read per object.

Three authorized ways into Wero's data

1 · Regulated AIS open-banking consent

Because Wero rides on the user's bank account, a PSD2 Account Information Service connection to that bank reads the instant transfers as they settle. This is the most durable path — it is a standardized regulated interface (Berlin Group NextGenPSD2 in most participating markets), it does not break when the app's front end changes, and the consent is the account holder's own. What it does not give you is the Wero-native framing: the bank sees an instant credit transfer, not "request #X answered by Y". We arrange the AISP role and the consent flow with you as part of the build.

2 · Documented protocol analysis of the Wero app

Reading the app's authorized traffic recovers the objects the bank ledger never sees — request states, QR references, alias resolution, the expiry clock. Effort is higher than the AIS path and durability is lower, since it tracks the app's own endpoints and may need a re-validation pass when the client updates. We run this against a consenting account under your authorization, and document the auth chain and each object as we map it.

3 · User-consented in-session access

Where a person will authenticate to their own Wero account, a consent-scoped session can read their history and linked accounts directly for them. This fits per-user features — a personal finance view, a one-off export — more than always-on aggregation.

For most projects we would lead with route 1 for the money movement and layer route 2 on top to recover the Wero-specific labels, because a transfer feed without the request-and-counterparty context is just anonymous SEPA Instant traffic. Route 3 is the one we reach for when the feature is built around a single consenting user rather than a fleet of accounts. Which mix is right depends on whether you need labelled per-counterparty Wero activity or just the cash movement, and we settle that in the first scoping call.

What you get back

Each deliverable is tied to a real Wero surface, not a generic template:

• OpenAPI / Swagger specification covering the endpoints we expose to you — transfers, requests, linked accounts, history — with the field shapes seen above.
• Protocol & auth-flow report: the redirect/consent chain on the AIS side and the token and session handling observed on the app side, written so your team can maintain it.
• Runnable source for the key calls in Python or Node.js — consent setup, transaction pull, request lookup, the SEPA-Instant-to-Wero matcher — not pseudo-code stubs.
• Automated tests against recorded fixtures so a Wero or bank-side change surfaces as a failing test, not a silent gap.
• Interface documentation and data-retention guidance aligned to GDPR and the consent scope you operate under.

A consent-to-transactions call, sketched

Illustrative shape of the AIS read on the bank account behind a Wero alias, in the NextGenPSD2 idiom. Exact paths and headers are confirmed per participating bank during the build.

# 1) Read accounts the consent covers
GET /v1/accounts
Authorization: Bearer {access_token}
Consent-ID: {consent_id}
PSU-IP-Address: 203.0.113.10

# 2) Pull instant transfers — Wero transfers settle here as SCT Inst
GET /v1/accounts/{resourceId}/transactions?bookingStatus=booked&dateFrom=2026-05-01
-> 200 {
     "transactions": { "booked": [
       { "transactionId": "...", "amount": { "currency": "EUR", "amount": "-24.50" },
         "bookingDate": "2026-05-30", "remittanceInformationUnstructured": "Wero ref 8F2A" }
     ]}}

# 3) Label it: match the ledger line to its Wero object
match = wero.resolve(reference="8F2A")   # request state, counterparty alias, QR/phone origin
record = { **txn, "wero_request": match.request_id,
           "counterparty": match.alias, "origin": match.channel }

# On expiry / SCA renewal, re-consent before the window lapses
if consent.expires_within(days=5): consent.renew()
      

Consent, PSD2 and the EU rules in play

The account side runs under PSD2 access by a licensed or partnered Account Information Service Provider, with consent expressed through the Berlin Group NextGenPSD2 model that most participating banks implement. GDPR governs the personal data throughout — the counterparty aliases, the contact directory, the history. We scope each consent to exactly the data a project needs, record it, and minimise what is stored. PSD2 access consents lapse on a renewal cycle and require strong customer authentication to refresh; we treat that as a scheduled event rather than a surprise. PSD3 and the proposed FIDA (Financial Data Access) framework are where European data access is heading, but the dependable legal basis today is the account holder's own consent, and that is what the integration is built on. Where the work touches a bank's systems or non-public interface detail, we operate under NDA.

What we plan around when building this

Two things about Wero specifically shape the engineering, and we handle both:

• Two data sources, one truth. A Wero transfer is a SEPA Instant line in the bank ledger and a request-or-QR object in the app at the same time. We build the matcher that ties them together by reference and alias, so a raw instant-transfer feed becomes Wero-labelled activity instead of anonymous credits. Without that step the two halves never line up.
• Rollout is in waves. Wero went live in Germany, France and Belgium first and is extending into the Netherlands and Luxembourg, with banks joining over time. We scope the build per participating bank and market because the redirect auth and the object set differ by issuer, and we design the sync around the PSD2 consent-refresh window so it does not silently expire mid-rollout.
• Front-end drift. The app-side reads track Wero's own endpoints, so we wire a re-validation pass into maintenance for when the client updates, keeping the labelling layer honest after a release.

Access — a consenting account, the AISP arrangement, a participating-bank sandbox where one exists — is set up with you during onboarding. It is part of the project, not something you have to bring before we start.

Where teams put Wero data to work

• A merchant back office that reconciles Wero settlements against orders the moment money arrives, instead of waiting on a daily bank statement.
• A treasury dashboard that folds Wero A2A flows into the same cash view as cards and direct debits, labelled by counterparty.
• A personal finance app that, with the user's consent, shows their Wero requests and transfers next to the rest of their account activity.
• An accounting integration that tags inbound Wero credits to invoices via the remittance reference and closes them automatically.

Working with us, and what it costs

A typical Wero build is a consent-driven AIS client plus a normalized transaction store and the SEPA-Instant-to-Wero matcher, and it runs in one to two weeks. You can take that as source-code delivery from $300 — you get the runnable source, the spec, the tests and the docs, and you pay after delivery once you are satisfied with it. Or you can skip hosting it yourself and use our pay-per-call hosted API, where you call our endpoints and pay only for the calls you make, with no upfront fee. Tell us the app and what you want out of its data, and we handle the route, the access and the compliance side. Start the conversation on the contact page.

Screens from the app

Store screenshots, for reference on the surfaces described above.

Other European wallets in the same integration picture

Wero overlaps and competes with national instant-payment wallets across Europe; several were the schemes it replaced. Naming them widens the picture of what a unified A2A integration spans.

• Twint — Switzerland's account-linked mobile wallet for P2P and merchant payments.
• Bizum — Spain's bank-backed phone-number payment service, widely used P2P and in e-commerce.
• Swish — Sweden's real-time payment app tied to bank accounts.
• MobilePay — Denmark's mobile payment app for transfers and purchases.
• Vipps — Norway's phone-number payment and transfer service.
• Blik — Poland's code-based mobile payment scheme linked to bank accounts.
• Bancomat Pay — Italy's account-to-account mobile payment service.
• MB WAY — Portugal's mobile wallet for transfers, QR and card-linked payments.
• iDEAL — the Netherlands' bank-redirect payment standard Wero is set to absorb.
• Payconiq — the Belgian/Luxembourg scheme folded into Wero's account-to-account service.

Questions integrators ask about Wero

Does Wero expose the same data my bank shows, or something different?

Both, and that split drives the build. The money movement behind a Wero transfer settles over SEPA Instant and lands in the linked bank account, so an AIS connection sees it as a normal A2A credit or debit. The Wero-native objects — the payment request, its 30-day expiry, the QR reference, the contact you paid — live in the app's own session, so we read those by analysing the app's authorized traffic and stitch the two together.

Wero payments are not card transactions, so how do you label them in a feed?

Raw bank-account lines arrive as instant credit transfers with a remittance reference, not a tidy merchant name. We build a matcher that ties each ledger line back to its Wero payment request or QR reference and resolves the counterparty by the phone number or alias used, so what reaches you is Wero-labelled activity rather than anonymous SEPA Instant traffic.

Which EU rule covers pulling Wero-linked account data?

For the bank-account side it is PSD2 access by a licensed or partnered Account Information Service Provider, with consent under the Berlin Group NextGenPSD2 model and GDPR governing the personal data. PSD3 and the proposed FIDA framework are where this is heading, but the dependable basis today is the account holder's own consent, which we record and scope to exactly the data the project needs.

Wero is not live in my country yet — can you still build against it?

Yes. Wero rolled out first in Germany, France and Belgium and is extending into the Netherlands and Luxembourg, with banks joining in waves. We scope the integration per participating bank and market because the redirect auth and the available object set differ by issuer, and we build against a consenting account in a live market so the client works the day a new bank goes live.

How this mapping was put together

Reviewed in June 2026 against Wero's own description, its Play Store listing, the EPI's published rollout, and payment-processor integration docs that describe the Wero flow. Primary sources opened:

• Wero (payment) — Wikipedia
• Wero integration guide — Nuvei documentation
• Wero — PPRO developer hub
• Wero — Google Play listing

OpenBanking Studio integration desk · mapping reviewed June 2026.