Why Meta Pay failed, and how we unlocked payments in global markets
Meta had built native payments into Messenger for Southeast Asia — and it had nearly no users. I joined to understand why and define the path forward. What started as a product rescue became the foundation for Meta's global messaging payments infrastructure.
Our pilot unlocked the key to scaling global payments across regions and product experiences via a proven strategy of partnership, trust, and meeting users behaviors and needs.
My role
Staff Product Designer
Time
November 2024 - July 2025
Team
I worked alongside 1 PM, 1 junior designer, 16 engineers, and 8 XFN partners across legal, partnerships, and compliance.
Partners
The problem
MetaPay, a traditional structured checkout experience, failed. MetaPay was trying to retrofit structured e-commerce standards into a fluid system.
Many buyers relied on alternative digital payments. Most didn't trust Meta with payment credentials.
5%
engagement rate on Meta Pay at launch
<$100k
weekly TPV — less than 1% of target for 2023
The traditional buyer journey
Traditional e-commerce checkout journey follows a familiar and linear path.
The conversational commerce journey
Messaging commerce is un-linear and requires back and forth between seller and buyer, making the point of payment cumbersome.
From owning payments to coordinating them
Paired with local insights and partnerships, we developed a working hypothesis: rather than ask buyers to adopt a new payment method inside Meta, we should meet them where they already pay — by detecting payment moments in chat and routing them into the apps they already trust.
Meet users where they pay
Enable alternative payments to cards
Make their natural payments habits faster and deeply familiar
Testing the hypothesis, 2 weeks
Rather than iterate remotely, I partnered with our local team to organize a rapid two-week research sprint in Bangkok to validate comprehension, trust, and interest in the app-switch model with real buyers.
Bank account detection
When a seller shares a bank account number in chat, we detect it and automatically trigger a payment to Thai bank app with information pre-filled.
QR code detection
Similar, to bank account detection but triggered via the send of a QR image.
Additional entrypoints
We tested 4 variations of entry points to open the bank app. 3 variations tested neutral to negative. People found variation B more actionable and familiar.
Launching a pilot experience
In research, participants consistently struggled with QR, since QR in physical retail is common, but using a QR for direct payments in chat was a genuinely new mental model
Partnering with PM, we made the call to launch account number detection first. The research insight was unambiguous: matching their natural payment habits mattered.
June 2024: one bank, one country, one bet
We launched with a single bank partner covering 30% of Thailand's transactions — a deliberate scope constraint that let us prove the model cleanly before scaling. This launch validated the model and spearheaded our shift toward a hybrid payment approach across countries.
8x
transaction growth in 6 months — 137k to 1.1M monthly
+18%
month-over-month growth
+19%
seller conversion improvement
Scaling payments at rapid pace, caused growing pains
Expanding to 26+ markets with 50+ payment methods revealed that the product had no consistent design language and became costly to partner with each payment partner.
Following our pilot success, over 6 months we scaled to 50+ payment methods and 26+ markets, working with 20+ global partners spanning hundreds of teams.
Fragmented UI across markets
Payment experiences varied country to country with no recognizable shared pattern — undermining the familiarity that made Thailand work.
Per-country engineering overhead
Engineers were building custom assets at every bank or wallet launch. Design was being consumed by execution rather than direction.
No repeatable partner onboarding
PMs were scrambling to build new decks before every partner meeting. The same vision was being communicated inconsistently, costing trust and time.
Two frameworks that improved how we shipped and worked
Payments design system
A flexible, consistent payment component built on existing Messenger design system primitives — requiring minimal changes to ship — that worked across all payment types and markets. Informed by how APAC payment apps actually look: richer, denser, and more visually distinctive than Western defaults.
Partner integration framework
A structured framework I developed — mapping integration cost to user experience benefit, helping local partners understand where they fit in the broader payments vision. Replaced ad-hoc decks with a repeatable, scalable conversation tool.
The payments design system
Key principles across global markets
Synthesizing both western and local trends in these markets, key insights and principles emerged.
Trust embedded in known brands
Trust is leveraged through the payment brands themselves
Prominent visual language in payments
Payments across the key messaging payment markets is highly visual and contextual
Scaling across payments
While we scaled hybrid payments across new markets, we were also building out new features that demanded careful design consideration.
Flexible
The pattern needed to be more flexible than anticipated, since every region held different information, constraints and regulation
Aligned to Messenger & Instagram style
Components would need to scale based on MDS/IGDS system implementation & customization
The system pattern
The outcome was a scalable system component rolled out to countries around the world across payment features reinforcing trust and brand positioning, while giving the payments feature greater clarity across Messenger and Instagram.
Depending on if receiving or sending, optional fields are available.
Future considerations for scale
As we scale to new countries and use cases, I explored alternate use cases to get ahead of the expanding system
Contextual tags to provide clarity and trust
Multi-payment method support
The partner integration framework
Helping internal teams and external companies, build with us
This framework is continuously used for discussion, it dives into depth around time to market, level of engineering required, and overall risk.
This graduation path focuses on increasing levels of work to build, risk to ship, and overall backend integration. With greater features enabled and deeper the integration, the further right on the x-axis a product will become.
The level of market maturity helps partners and internal teams determine investment
By creating a strategic feature offering, we are able to pitch and discuss with partners payment features to build together, depending on the growth and maturity of the market.
For example, smaller markets have simpler, more lightweight payments, while in mature markets we pitch deeper, more seamless experiences to partners for buyers and sellers.
A framework used across markets and emerging bets
Across new strategic monetization experiences, we’ve leveraged this framework to pitch both internal and external partners to build peer payments on Messenger, cross-border remittances on WhatsApp, and bill payments in Thailand.
Project impact and what I'd do differently
Results
4.5M
monthly transactions by end of 2025
20M
monthly transactions projected for 2026
26+
markets on platform
+7%
conversion improvement from UI pattern roll out
50+
payment methods accepted
12+
payment features shipped
Reflection
Looking back at this project, I built the partner and design system framework reactively — after the scaling problems were already visible.
Designing for scale — across markets, platforms, product teams, and external payment partners — was a learning experience I likely won't be able to replicate elsewhere. For that, I'm grateful.