Wero: Europe’s Attempt to Replace Cards and Why It’s Harder Than iDEAL
Post #5 in the European Payments Series · Wero Payments · GCP Architecture
Every iDEAL merchant in the Netherlands is currently sitting on a ticking migration clock, and most of them don’t know that the transaction ID format is changing in a way that will silently break their reconciliation systems. By end of 2027, iDEAL one of the most successful domestic payment rails in Europe is dead. This post is about what you build as the Acceptor PSP connecting merchants to its replacement: Wero. The issuing bank side is a different post that comes next. Here we’re focused on the infrastructure between the merchant and EPI Central Services: the webhook pipeline, the state machine, the fraud gate, and the migration traps hiding in plain sight.
1. Brief History: From Fragmentation to Sovereignty
The story of Wero starts not with success, but with failure. In 2020, a consortium of 20 European banks launched what was internally called PEPSI the Pan-European Payments System Initiative. The ambition was bold: a unified card alternative to Visa and Mastercard. By late 2021, 20 banks from Poland, Spain, Germany, and Finland had withdrawn, spooked by the scope and the cost. The remaining 13 banks pivoted hard. Instead of replacing cards, they’d build a digital wallet on top of the infrastructure that already worked: SEPA Instant Credit Transfer (SCT Inst).
The European Payments Initiative (EPI) was reconstituted around this wallet-first strategy, and in October 2023, EPI made a defining acquisition it bought Currence iDEAL BV (the operator of iDEAL) and Payconiq International. In one move, they absorbed the Netherlands’ dominant online payment method and Belgium’s mobile payment network. The name “Wero” was announced in September 2023. The system went live in Germany on 2 July 2024, France in September, Belgium in November.
The non-obvious historical fact most engineers miss: EPI operates on a one-bank-one-vote governance model. This is deliberate it prevents Deutsche Bank or BNP Paribas from steamrolling smaller members. It also means scheme rule changes are slower to ship than at Visa or Mastercard. Plan your EPI integration with that governance cadence in mind.
2. What Problem Does It Solve?
Before Wero existed, paying online as a European consumer was a patchwork of national fiefdoms. A Dutch consumer buying from a German webshop couldn’t use iDEAL as it only works in the Netherlands. A French consumer couldn’t use Paylib cross-border. The result: European merchants defaulted to Visa and Mastercard for any cross-border transaction, handing roughly €7 trillion in annual European payment volume to two American companies. According to industry data, Visa and Mastercard together hold around 61% of euro area card transactions.
The business problem is European payment sovereignty or the lack of it. Every cross-border transaction that routes through a US card network carries an interchange fee (up to 2% for credit cards, capped at 0.3% for debit under EU regulation but still present), and more fundamentally, the settlement infrastructure is owned and governed outside the EU.
The technical problem is that the existing national rails were islands. iDEAL has no P2P capability. Giropay (Germany) was shut down in 2024 because it failed to gain merchant adoption. Paylib (France) was purely P2P with no e-commerce flow. None of them interoperated.
Wero’s answer is to run everything on SCT Inst, already a pan-European standard and put a wallet-and-scheme layer (EPI Central Services) on top that provides alias resolution (phone number → IBAN), unified authentication, and a common merchant API. As of early 2026, Wero has passed 50 million registered users with over 100 million P2P transactions valued at more than €5 billion completed.
3. How to Build It on GCP
a) Architecture Overview
Wero has three layers. Mixing them up is where designs go wrong.
You need to model these separately. If you don’t, your assumptions bleed across layers and break under load.
Scheme Layer - EPI Central Services
Alias resolution (phone → IBAN)
Authentication routing (wallet, bank app)
Payment orchestration via Wero APIs
This is where the user flow and orchestration logic live.
Settlement Layer - SCT Inst
Instant settlement via EBA CLEARING RT1 or TARGET Instant Payment Settlement
<10 second finality, 24/7
This is where money actually moves. Different guarantees, different failure modes.
PSP Layer - Your system
Accept merchant requests
Call EPI APIs
Handle webhooks
Update state and notify merchants
This is where you are accountable.
b) GCP Architecture
🏦 Nominal Wero flow: PSP initiates payment → consumer authenticates via Wero → webhook confirms → funds settle via SCT Inst (RT1/TIPS) → PSP updates merchant.
🔴 Failure flow: PSP initiates → consumer/auth/infra failure or webhook loss → status remains non-terminal or mismatched → recovery via idempotent retries, webhook reprocessing, and status polling with reconciliation.
c) Wero Payments PSP Interactive architecture (recommended)
Explore the interactive Wero architecture, click each component (EPI APIs, webhook handler, settlement layer) to see how it behaves under real-world conditions and why it exists in production:
👉 View Interactive Wero Payments PSP Architecture
4. Cloud Comparison: GCP vs AWS vs Azure
5. Payment State Machine - Wero (PSP perspective)
5. Implementation Steps a Fintech Would Actually Follow
The Only Implementation Path That Doesn’t Blow Up Later
Teams try to compress this into one phase. That’s how you get production issues you can’t explain.
Phase 1 — EPI onboarding & basic integration (Weeks 1–4)
Scope:
EPI access (direct or via providers like Worldline, Nuvei, Axepta)
Payment initiation API
Webhook handler
Important:
AUTHENTICATION_PENDING ≠ success
Outcome:
End-to-end flow works in sandbox
Phase 2 — State machine & idempotency (Weeks 5–8)
Scope:
Payment state machine
Idempotency (write-before-call)
Webhook pipeline (Pub/Sub + DLQ + alerting)
Risk:
Duplicate payments or missing state without strict idempotency
Outcome:
System survives retries, duplicates, and partial failures
Phase 3 — Fraud & reconciliation (Weeks 9–14)
Scope:
Fraud scoring (e.g. Vertex AI)
Reconciliation: EPI settlement ↔ DB ↔ SCT Inst
Risk:
Silent break if you assume iDEAL transaction ID format
Outcome:
Financial correctness (not just “API works”)
Phase 4 — Production hardening & SLOs (Weeks 15–20)
Scope:
SLOs (latency, webhook processing, reconciliation gap)
Monitoring + alerting
Failure testing
Test for:
EPI latency
Pub/Sub delay
DB failover
Outcome:
System holds under real-world failure, not just happy path
6. What You Must Not Cut Corners On
a) Idempotency keys
Break: Calling EPI before persisting the idempotency key → network timeout loses the response.
Impact: Payment exists at EPI but not in your system → duplicate or orphaned payments on retry.
Fix: Write idempotency key to DB before EPI call; on retry, query status instead of creating a new payment.
b) Webhook signature verification
Break: Processing webhooks without verifying EPI signature.
Impact: Fake or tampered events enter your system → potential fraud or state corruption.
Fix: Verify signature first; failed verification → security alert, not DLQ.
c) Transaction ID assumptions (iDEAL → Wero)
Break: Systems assume iDEAL ID format (e.g. fixed numeric pattern).
Impact: Silent failures in reconciliation, reporting, and fraud when Wero IDs arrive.
Fix: Remove format assumptions; audit every system touching transaction IDs before migration.
7. Failure Scenarios in Production
a) Webhook delivery stops
Break: EPI retries webhooks for a limited window; non-200 responses eventually stop retries.
Impact: Payment settles on SCT Inst but remains stuck in AUTHENTICATION_PENDING in your system.
Fix: Poll EPI status API for payments >2 minutes old without terminal state.
b) Duplicate fulfillment via Pub/Sub
Break: Webhooks and Pub/Sub are both at-least-once → duplicate events are inevitable.
Impact: Same payment processed twice → double fulfillment.
Fix: Enforce idempotent state transitions (UPDATE ... WHERE status != ‘COMPLETED’).
c) SCT Inst timeout ambiguity
Break: EPI reports FAILED when SCT Inst times out, but the underlying transfer may still settle.
Impact: Customer is debited while merchant sees a failed payment.
Fix: Treat as reconciliation exception; never retry without issuing bank confirmation.
d) AlloyDB failover
Break: Database failover blocks idempotency writes → requests fail → clients retry aggressively.
Impact: Retry storm on recovery + duplicate payment attempts.
Fix: Circuit breaker + exponential backoff + temporary Redis idempotency cache.
e) Fraud model drift (iDEAL → Wero)
Break: Fraud model trained on iDEAL data doesn’t generalize to Wero transaction patterns.
Impact: False positives (and/or fraud leakage) spike during migration.
Fix: Retrain on Wero data; monitor precision/recall weekly.
f) mTLS certificate expiry
Break: Client certificate expires → all EPI API calls fail.
Impact: Complete payment outage (initiation, status, webhooks).
Fix: Automate certificate rotation with pre-expiry alerting.
8. The One Thing Most Teams Get Wrong
a) Most PSPs assume iDEAL → Wero is a drop-in swap. It isn’t.
Yes, iDEAL 2.0 and Wero both support multiple auth channels (redirect, QR, push).
That’s not where the risk is.
The break happens deeper:
Different settlement model: EPI files vs iDEAL Hub reports
Different transaction identifiers: breaks any format assumptions
Mixed traffic: Wero blends P2P and e-commerce flows
Different fraud signals: iDEAL-trained models don’t generalise
Nothing fails at launch. The damage shows up later:
reconciliation mismatches
fraud model degradation
reporting inconsistencies
b) What good PSPs do
Treat Wero as a new scheme, not an upgrade
Add payment_scheme explicitly (don’t infer)
Audit all transaction ID dependencies
Validate EPI settlement ingestion before scale
Retrain fraud models on Wero-native data
c) What happens if you don’t
Six months later:
recon breaks
finance numbers don’t match
fraud blocks legitimate payments
Not because Wero failed because you assumed it was iDEAL.
9. Coming Next in This Series
This post covered what you build as the PSP sitting between the merchant and EPI. But there’s an entire other side of every Wero transaction you didn’t see here: the issuing bank. That’s the system that receives the authentication request from EPI Central Services, delegates SCA to the Wero wallet, runs the real-time fraud and balance check inside a 4-second window, fires the SCT Inst instruction, and reports to DNB. It’s architecturally more constrained than the PSP side and in some ways more interesting to build.
That’s Post #6: Wero from the issuing bank perspective, on GCP.
PSD2 and Open Banking follow after that.
Already published in this series:
