Why Meta Pay failed, and what we did about it, from $100k weekly to 4.5M monthly transactions
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.
Team
I worked alongside 1 PM, 1 junior designer, 16 engineers, and 8 XFN partners across legal, partnerships, and compliance.
My role
Staff Product Designer
Time
November 2024 - July 2025
The Problem
The deeper issue wasn't the interface — it was that the product had been designed for a Western mental model of payments in markets where the entire financial infrastructure works differently. Many buyers were unbanked. Most didn't trust Meta with payment credentials. Cash on delivery was the default for a reason.
Sellers: Onboarding required long KYC for sellers, with minimal ROI.
Buyers: Many folks do not trust Meta to store payment info, may be unbanked, or prefer alternative payment methods (wallets).
5%
engagement rate on Meta Pay at launch
<$100k
weekly TPV — against a $814M 2030 iRev target for SEA
$11B
global conversational commerce market in 2025
The hypothesis : From owning payments to coordinating them
Working with product, user research, and our Southeast Asia partnerships team in Singapore, I 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.
If Messenger could detect when a seller shared a bank account number or QR code, auto-fill the buyer's existing bank app, and make the handoff seamless — we wouldn't need to replace existing payment behavior. We'd just remove the friction from it.
This was a significant strategic reframe. It moved Meta from trying to own the payment layer to positioning Messenger as the coordination surface — the place where the intent to pay happens, not necessarily where the payment itself lives. That had implications for the product model, the partner strategy, and what we asked engineering to build.
Two weeks to validate. One trip to get it right.
Rather than iterate remotely, I advocated for and organized a rapid two-week research sprint in Bangkok — our primary test market — to validate comprehension, trust, and interest in the app-switch model with real buyers.
We tested two payment detection patterns in market: bank account number detection and QR code detection, across multiple entry point and content variations.
What we tested
We tested two payment detection patterns in market: bank account number detection and QR code detection, across multiple entry point and content variations.
Bank account detection — 4 entry points, 3 content variations
When a seller shares a bank account number in chat, Messenger detects it and triggers a pre-filled deep link into K PLUS (Thailand's dominant bank app), eliminating manual entry entirely.
QR code detection — 3 entry points, 2 content variations
When a seller sends a QR code image, Messenger detects it and initiates a similar pre-fill flow. Theoretically faster, but behaviorally unfamiliar for digital payments in this market.
Alternative entrypoints
We tested 4 variations of entry points to open the bank app. 3 variations tested neutral to negative. People found that was more clearly actionable and familiar to most participants, of which some remarked it was professional and familiar.
QR codes failed in research
In research, participants consistently struggled. The pattern was familiar from physical retail, but using a QR code sent in a chat message to trigger a bank transfer was a genuinely new mental model. Participants saw the value but couldn't reliably complete the flow.
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. The principle was: get one thing right, then move fast.
8x
transaction growth in 6 months — 137k to 1.1M monthly
+18%
month-over-month growth throughout H2 2024
+19%
seller conversion improvement, validated with Data Science
Partnering with PM, We made the call to launch account number detection first. This wasn't the path of least resistance — account number parsing required more complex infrastructure. But the research was unambiguous: familiarity and completion mattered more than elegance at this stage. QR code would follow once buyers had the mental model for in-chat payments at all.
Scaling at rapid pace
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.
The approach that worked at one market was breaking at ten
Expanding to 26+ markets with 50+ payment methods revealed that the product had no consistent design language. Each new country required custom UI. Each partner meeting required a bespoke pitch deck. The team was scaling effort, not infrastructure.
Over the course of the following 6 months we scaled to over 50+ payment methods and 26+ markets, working with 20+ global partners spanning hundreds of teams
audited the full product portfolio, spoke with internal and external partners, and identified that both the design system and the partner model needed to be rebuilt as infrastructure — not treated as per-project deliverables.
Analyzed and compared industry standards in foreign markets
Partner integration framework
A structured framework I developed and personally used in partner meetings across Southeast Asia — 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.
Payments system
Payments system pattern
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.
Two frameworks that changed how the team operates
Future considerations
As we scale to new countries and use cases, I explored alternate use cases to get ahead of the expanding system
Tags to show it is an auto generated payment
Multi-payment method support
Seller-side bubbles
Flexible statuses
Partner integration framework
Thailand as blueprint. Our top markets as proof.
The partner framework mapped each market to its payments maturity, unique characteristics, and current investment level — allowing the right conversation at each stage rather than pitching the same vision everywhere.
What we built, what it became, 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. In retrospect, the moment we validated the Thailand pilot was the right moment to design for scale.
The framework would have been stronger with more partner team input earlier, rather than being reverse-engineered from friction I'd already observed at market ten.