Când un portofel digital „funcționează peste tot”, discursul public se oprește de obicei la o singură victorie: plata e acceptată. Poți plăti la magazin, online sau peste graniță. Însă, pe măsură ce portofelele se transformă în platforme multi-serviciu — cu carduri, transferuri, documente și preferințe — apare o întrebare mai grea: ce context ar trebui să urmeze utilizatorul dintr-o aplicație în alta și, la fel de important, ce date trebuie să rămână în afara acestui strat.

Întrebarea nu e teoretică. În septembrie 2026, Mastercard a anunțat Wallet Pay, un portofoliu menit să accelereze interoperabilitatea portofelelor pe NFC, QR și plăți online, împreună cu parteneri precum ecosistemul Alipay+ (AlipayHK, GCash, KakaoPay, TrueMoney și altele), dar și Axian, CRED, DaviPlata, Mercado Pago, MTN sau TenPay Global. Compania vorbește despre peste 4,3 miliarde de utilizatori de portofele digitale în prezent și despre o țintă de peste 6 miliarde până în 2030. RoAdevăr a acoperit deja anunțul: Mastercard lansează Wallet Pay pentru conectarea portofelelor digitale la nivel global.

Wallet Pay răspunde, în esență, la problema „acceptării”: să poți plăti unde există rețeaua Mastercard, să emiți carduri din portofel, să muți bani între carduri, portofele și conturi. Este interoperabilitate de plată. Nu rezolvă singură interoperabilitatea de identitate-context: ce știe aplicația B despre tine după ce ai folosit aplicația A, fără să te forțeze să-ți recreezi de fiecare dată profilul, istoricul sau preferințele.

Două tipuri de interoperabilitate care se confundă ușor

În industrie, cuvântul „interoperabilitate” acoperă lucruri foarte diferite. Primul tip e comercial și tehnic: un portofel din Filipine să poată plăti într-un magazin din Europa; un comerciant să accepte atât carduri, cât și portofele; transferurile cross-border să nu se blocheze în silozuri. Aici intră Wallet Pay, colaborări precum Mastercard–TerraPay (acceptare wallet la zeci de milioane de puncte Mastercard) și gateway-urile regionale de tip Alipay+.

Al doilea tip e despre continuitatea sesiunii sociale și a drepturilor digitale: vârsta confirmată o singură dată, preferințele de confidențialitate, un identificator pe care îl controlezi tu, un istoric de recompense în ecosistemul în care alegi să participi, sau un atestat că „ești același utilizator” fără să expui CNP-ul, adresa sau cheile private. Aici conversația se mută spre W3C Digital Credentials API, spre profiluri de interoperabilitate pentru credențiale (OID4VCI / OID4VP) și spre portofelele de identitate digitală europene (EUDI), pe care statele membre trebuie să le pună la dispoziție până la finalul lui 2026.

Confuzia dintre cele două e periculoasă. Dacă „ce ține portofelul între aplicații” înseamnă, în practică, un profil publicitar complet, un jurnal de locații sau o copie a datelor bancare duplicate în fiecare app, atunci interoperabilitatea nu e un câștig pentru utilizator — e o scurtătură pentru supraveghere și lock-in.

Ce ar putea „urma” utilizatorul în mod legitim

O listă realistă, construită pe principiul minimizării datelor, ar începe cu lucruri pe care utilizatorul alege explicit să le prezinte, pe sesiune sau pe relație:

  • Atestate selective — de exemplu „am peste 18 ani”, fără data nașterii completă; „am un cont verificat la emitentul X”, fără dump-ul KYC.
  • Identificatori controlați de utilizator — un handle sau un DID pe care îl poți roti, revoca sau separa pe contexte (muncă / personal / anonim).
  • Preferințe de interfață și consimțământ — limba, tipul de autentificare acceptat (passkey vs. parolă), opțiuni de marketing opt-in.
  • Context de loialitate în interiorul unui ecosistem asumat — puncte, niveluri, quest-uri, doar unde utilizatorul a intrat conștient într-un program de tip club.
  • Dovezi de plată deja făcute — o chitanță sau un status „plătit”, nu cheia cardului.

Toate acestea au un numitor comun: consimțământ pe cerere, vizibilitate asupra atributelor cerute și posibilitatea de a refuza fără a bloca total viața digitală. Exact pe această logică insistă specificațiile EUDI: utilizatorul trebuie informat ce atribute sunt solicitate; părțile care se bazează pe portofel trebuie înregistrate pentru scopuri declarate; minimizarea datelor e cerință, nu slogan.

Ce trebuie să rămână în afară — linia roșie

Indiferent de marketing, există categorii pe care un „strat de context” nu ar trebui să le transporte automat între aplicații:

  • Materialul criptografic brut — seed phrases, chei private, secrete de semnare. Portofelul semnează local; aplicația primește rezultatul, nu cheia.
  • Datele complete de identificare legală, dacă nu sunt strict necesare scopului (și, în Europa, dacă partea solicitantă nu e autorizată / înregistrată corespunzător).
  • Biometria brută — șabloanele rămân pe dispozitiv; se transmite doar verdictul autentificării, unde e cazul.
  • Jurnale de navigare și locație cross-app fără consimțământ granular — „context” nu e sinonim cu „profilare continuă”.
  • Credențiale bancare sau de plată reglementate care ar transforma stratul într-un custodian sau PSP fără licență.

W3C, în discuțiile despre Digital Credentials API, subliniază rolul browserului / agentului utilizatorului ca mediator: să contextualizeze cererea, să prevină expunerea imediată către orice „wallet” și să mențină controlul utilizatorului asupra identităților multiple — inclusiv efemere sau anonime. Cu alte cuvinte: interoperabilitatea nu trebuie să însemne o singură identitate totală, permanentă, pentru tot internetul.

De la plăți la „context”: unde se încadrează experimentele Web3

În paralel cu infrastructura cardurilor și a portofelelor reglementate, există proiecte care încearcă să lege „conectarea portofelului” de un profil persistent în ecosistemul lor. Un astfel de exemplu — propus redacției ca studiu de caz tehnic, nu ca produs reglementat de plăți în România — este MARCO din Melega Ecosystem.

Conform documentației publice a proiectului, MARCO Connect înlocuiește un simplu buton de conectare a portofelului Web3 cu un strat care creează sau recunoaște un Passport: o identitate de ecosistem legată de portofelul controlat de utilizator, cu opțiuni ulterioare de email/passkey ca metode alternative de acces (nu ca creator al unui Passport nou). MARCO Passport e descris ca anonim în mod implicit, cu username opțional pentru transferuri interne de M-Credits. MARCO Pay permite plăți în tokenul MARCO către un wallet de încasare al comerciantului, cu un model de recompense în M-Credits pe care proiectul îl precizează explicit ca nefiind bani și neconvertibili / nerecuperabili în numerar.

Propunerea trimisă redacției insistă pe o delimitare importantă — pe care o păstrăm aici ca limită editorială, nu ca certificare: Connect și Passport nu sunt prezentate ca identitate legală, KYC, serviciu bancar, custodie sau infrastructură de plăți reglementată, și nu există o afirmație de adopție pe piața din România. Sunt, așadar, un laborator util pentru a discuta arhitectura „contextului reutilizabil”, nu un substitut pentru EUDI Wallet sau pentru un PSP autorizat.

Lecția utilă din acest tip de design e dublă. Pe de o parte, arată de ce dezvoltatorii vor un buton unic: fără el, fiecare dApp reînvată zero despre utilizator. Pe de altă parte, arată riscul: dacă „Passport-ul” adună prea multe semnale (discover, quests, rewards, plăți) fără separare clară de scopuri, utilizatorul poate confunda un club de ecosistem cu o identitate oficială. Transparența limitelor — ce e și ce nu e — e parte din produs, nu un disclaimer de subsol.

Ce ar trebui să ceară utilizatorii și redacțiile de la orice strat de context

Indiferent dacă vorbim despre Wallet Pay, EUDI sau un Connect Web3, câteva criterii practice merită puse pe listă înainte de entuziasm:

  1. Scop declarat pe ecran — „de ce îmi cereți acest atribut acum?”
  2. Minimizare — se poate rezolva cu un da/nu (majorat) în loc de documentul întreg?
  3. Revocare — pot tăia accesul aplicației B fără să-mi șterg viața din aplicația A?
  4. Separarea rolurilor — plată ≠ identitate legală ≠ marketing ≠ loialitate.
  5. Jurnal pentru utilizator — ce s-a partajat, cu cine, când (cerință discutată intens și în ecosystemul EUDI).
  6. Fără lock-in silențios — pot exporta sau recrea relațiile esențiale în altă parte?

Fără aceste garanții, „portofelul care ține minte totul între aplicații” riscă să fie doar o formulă elegantă pentru un dosar digital pe care nu-l mai controlezi.

Concluzie

Mastercard Wallet Pay împinge industria spre un portofel care plătește aproape oriunde. Următoarea bătălie — deja vizibilă în standardele W3C și în calendarul EUDI — e despre un portofel care prezintă doar ce trebuie, când trebuie, cu consimțământ. Contextul reutilizabil are sens: nimeni nu vrea să-și reînvețe identitatea de fiecare dată. Dar granița e totul. Un strat care mută dovezi selective și preferințe alese e progres. Un strat care mută pe tăcute profiluri, chei și date de reglementare e un alt produs — și merită tratat ca atare, inclusiv în România, unde adopția oficială a portofelelor de identitate europeană și a serviciilor de plată reglementate are cu totul alt cadru decât experimentele de ecosistem Web3.

Pentru cititorul care vrea să meargă mai departe: documentația publică MARCO (Connect / Passport / Pay) e un bun exercițiu de citit „printre rânduri” — ce promite, ce exclude și ce rămâne pe seama consimțământului. Iar pentru industria plăților, Wallet Pay arată că interoperabilitatea comercială accelerează. Rămâne de văzut dacă interoperabilitatea de context va ține pasul cu aceleași standarde de confidențialitate pe care Europa le cere deja portofelelor de identitate.

Mastercard — Wallet Pay (comunicat) · FinTech Global — analiza Wallet Pay · W3C — Digital Credentials API · Comisia Europeană — EUDI · MARCO / Melega — documentație · MARCO / Melega — site