When a digital wallet “works everywhere”, public debate usually stops at one victory: the payment is accepted. You can pay in-store, online or across borders. Yet as wallets become multi-service platforms — with cards, transfers, documents and preferences — a harder question appears: what context should follow the user from one app to another, and equally important, what data must stay outside that layer.

The question is not theoretical. In September 2026 Mastercard announced Wallet Pay, a portfolio meant to accelerate wallet interoperability across NFC, QR and online payments, with partners including the Alipay+ ecosystem (AlipayHK, GCash, KakaoPay, TrueMoney and others), plus Axian, CRED, DaviPlata, Mercado Pago, MTN and TenPay Global. The company cites more than 4.3 billion digital-wallet users today and a path toward more than 6 billion by 2030. RoAdevăr already covered the announcement: Mastercard launches Wallet Pay to connect digital wallets globally.

Wallet Pay essentially answers the acceptance problem: pay wherever Mastercard rails reach, issue cards from a wallet, move money between cards, wallets and accounts. That is payment interoperability. It does not by itself solve identity-context interoperability: what app B should know about you after you used app A, without forcing you to rebuild profile, history or preferences every time.

Two kinds of interoperability that are easy to confuse

In industry language, “interoperability” covers very different things. The first kind is commercial and technical: a wallet in the Philippines paying in a European shop; a merchant accepting both cards and wallets; cross-border transfers escaping silos. This is where Wallet Pay, collaborations such as Mastercard–TerraPay, and regional gateways like Alipay+ sit.

The second kind is about continuity of digital rights and session context: age confirmed once, privacy preferences, an identifier you control, loyalty history inside an ecosystem you chose to join, or a proof that “you are the same user” without dumping national ID numbers, addresses or private keys. Here the conversation moves to the W3C Digital Credentials API, credential interop profiles (OID4VCI / OID4VP) and European Digital Identity (EUDI) wallets, which Member States must make available by the end of 2026.

Mixing the two is dangerous. If “what the wallet remembers between apps” means, in practice, a full advertising profile, a location journal or bank data duplicated into every app, then interoperability is not a user win — it is a shortcut to surveillance and lock-in.

What could legitimately “follow” the user

A realistic list, built on data minimisation, starts with things the user explicitly chooses to present, per session or per relationship:

  • Selective attestations — for example “over 18”, without a full date of birth; “verified account at issuer X”, without a KYC dump.
  • User-controlled identifiers — a handle or DID you can rotate, revoke or separate by context (work / personal / anonymous).
  • UI and consent preferences — language, accepted authentication type (passkey vs password), marketing opt-ins.
  • Loyalty context inside an opted-in ecosystem — points, tiers, quests, only where the user knowingly joined a club-like programme.
  • Proofs of payments already made — a receipt or “paid” status, not the card secret.

The common denominator is consent on request, visibility of requested attributes, and the ability to refuse without shutting down digital life entirely. EUDI specifications insist on the same logic: users must be told which attributes are requested; relying parties should register declared purposes; data minimisation is a requirement, not a slogan.

What must stay out — the red line

Regardless of marketing, there are categories a “context layer” should not automatically ferry between apps:

  • Raw cryptographic material — seed phrases, private keys, signing secrets. The wallet signs locally; the app receives the result, not the key.
  • Full legal identity data unless strictly necessary for the purpose (and, in Europe, unless the requesting party is appropriately authorised / registered).
  • Raw biometrics — templates stay on device; only an authentication verdict is shared where needed.
  • Cross-app browsing and location journals without granular consent — “context” is not a synonym for continuous profiling.
  • Regulated banking or payment credentials that would turn the layer into an unlicensed custodian or payment service provider.

W3C discussions around the Digital Credentials API stress the browser / user agent as mediator: contextualise the request, prevent immediate exposure to any wallet, and preserve user control over multiple identities — including ephemeral or anonymous ones. In other words: interoperability must not mean one total, permanent identity for the entire internet.

From payments to “context”: where Web3 experiments fit

Alongside card rails and regulated wallets, some projects try to bind “connect wallet” to a persistent profile inside their own ecosystem. One example — pitched to the newsroom as a technical case study, not as a regulated payments product in Romania — is MARCO in the Melega Ecosystem.

According to the project’s public documentation, MARCO Connect replaces a generic Web3 wallet button with a layer that creates or recognises a Passport: an ecosystem identity tied to a user-controlled wallet, with later email/passkey options as alternative access methods (not as creators of a new Passport). MARCO Passport is described as anonymous by default, with an optional username for internal M-Credits transfers. MARCO Pay lets merchants receive MARCO token payments to a registered receiving wallet, with an M-Credits rewards model that the project explicitly states is not money and cannot be converted, redeemed or withdrawn as cash.

The submission to the newsroom insists on an important boundary — which we keep here as an editorial limit, not as a certification: Connect and Passport are not presented as legal identity, KYC, banking, custody or regulated payment infrastructure, and there is no claim of adoption on the Romanian market. They are therefore a useful lab for discussing “reusable context” architecture, not a substitute for an EUDI Wallet or a licensed PSP.

The useful lesson from this kind of design is twofold. On one hand, it shows why developers want a single button: without it, every dApp relearns zero about the user. On the other, it shows the risk: if a “Passport” accumulates too many signals (discover, quests, rewards, payments) without clear purpose separation, users may confuse an ecosystem club with an official identity. Transparency about limits — what it is and is not — is part of the product, not a footnote.

What users and newsrooms should demand from any context layer

Whether the subject is Wallet Pay, EUDI or a Web3 Connect, a few practical criteria deserve a checklist before enthusiasm:

  1. Purpose on screen — “why are you asking for this attribute now?”
  2. Minimisation — can a yes/no (over 18) replace the full document?
  3. Revocation — can I cut app B’s access without deleting my life in app A?
  4. Role separation — payment ≠ legal identity ≠ marketing ≠ loyalty.
  5. User-facing log — what was shared, with whom, when (also debated intensively in the EUDI ecosystem).
  6. No silent lock-in — can I export or recreate essential relationships elsewhere?

Without those guarantees, “the wallet that remembers everything between apps” risks becoming an elegant phrase for a digital file you no longer control.

Conclusion

Mastercard Wallet Pay pushes the industry toward a wallet that pays almost anywhere. The next battle — already visible in W3C standards and the EUDI timeline — is about a wallet that presents only what is needed, when needed, with consent. Reusable context makes sense: nobody wants to relearn their identity every time. But the boundary is everything. A layer that moves selective proofs and chosen preferences is progress. A layer that quietly moves profiles, keys and regulated data is a different product — and should be treated as such, including in Romania, where official European identity wallets and licensed payment services sit in a completely different frame from Web3 ecosystem experiments.

For readers who want to go further: MARCO’s public docs (Connect / Passport / Pay) are a good exercise in reading between the lines — what is promised, what is excluded, and what remains a matter of consent. For the payments industry, Wallet Pay shows commercial interoperability is accelerating. Whether context interoperability will keep the same privacy standards Europe already demands of identity wallets remains an open test.

Mastercard — Wallet Pay (press release) · FinTech Global — Wallet Pay analysis · W3C — Digital Credentials API · European Commission — EUDI · MARCO / Melega — documentation · MARCO / Melega — site