EPI Company (sample)

A2A overlay (Wero / EPI)

Pan-Europeanv1.0currentPublisher docs ↗

Retail A2A overlay (sample: Wero). Wallet UX (P2P, P2Pro, checkout) sits above ASPSPs and an instant rail such as SCT Inst. Not an XS2A API itself — it orchestrates intent, proxy lookup and instant settlement. Same split as Bizum, Payconiq, iDEAL, BLIK, Swish, Vipps MobilePay, TWINT.

Security profile

Client authentication
Scheme participant credentials; merchant integrations via PSPs.
Message signing
Scheme-level; underlying bank rails use existing PSD2 / SCT Inst security.
Tokens
Wallet session / consent inside the Wero app; bank SCA when required by the ASPSP.
Certificates
Participant onboarding via EPI; ASPSP side remains eIDAS where PSD2 applies.

SCA approaches

In-app authenticationASPSP SCA when required

What bites integrators

  • A2A overlays settle on SCT Inst (or national instant where applicable) — clearing timeouts and pacs.002 semantics still apply.
  • Proxy resolution is not Confirmation of Payee; still run VoP where the Instant Payments Regulation requires it.
  • Cancellation after settlement is a recall/return path, not a wallet undo.

APIs and endpoints

A2A overlay wallet / merchant (Wero sample)

Scheme

Initiate A2A overlay payment, resolve proxy (phone/email), confirm and settle via SCT Inst (Wero-shaped API).

  • POST/wero/v1/paymentsCreate a Wero payment intent
  • GET/wero/v1/payments/{id}Read payment status
  • POST/wero/v1/proxy/resolveResolve alias to IBAN
  • POST/wero/v1/payments/{id}/cancelCancel before settlement

Flows using this standard

Sample payloads