Universal Payment Request
A modular payment request experience that helps businesses on WhatsApp get paid in 50+ countries.
My role & impact
Owned end-to-end design as the only designer, covering sellers and buyers across the WhatsApp Business App, Business API, and WhatsApp (consumer), on both iOS and Android.
Set the design direction. Replaced one-off country builds with reusable payment types that each market turns on through configuration, bringing launches down from 6 to 12 months to weeks.
Designed a payment bubble that scales. Built it from modular parts that handle 25+ combinations of payment method, account count, amount, order details, and status, shared by small sellers and enterprise merchants, and now components in the WhatsApp design system.
Unblocked the Business AI launch. Designed a payment request experience that works in any market, giving the Business AI team what it needed to launch in 50+ markets with AI agents sending payment requests for businesses in chat.
Documented the components for cross-functional teams. Wrote documentation pages for payment components in the WhatsApp business messaging design system. They cover bubble anatomy, payment methods for small sellers and enterprise merchants, payment states, and how each payment bubble shows up by country and use case. PMs, engineers, and designers now use them as the source of truth for payment experiences.
Background
Example of seller sharing payment info in chat in Indonesia
Across the world, millions of small businesses run entirely on WhatsApp. The catalog is a camera roll. Customer service is a chat thread. The storefront is a phone number.
However, getting paid is still manual. Sellers type out bank account numbers, wallet IDs, and phone numbers by hand in chat after chat, and buyers copy those details into a separate banking app one character at a time. There's no structure and no clear sign that a request is legitimate, and one wrong digit means a failed payment.
WhatsApp had solved this in Brazil and India; each had deep, purpose-built payment platforms, and each took large teams and 6 to 12 months of bespoke engineering, legal, and design work to launch. With the business planning to expand payments to 50+ countries, building market by market was never going to get there, and the Business AI team couldn't offer payments in chat without a structured way to request them.
Example of seller sharing payment info via image in Mexico
Existing experience of seller sharing Pix key in Brazil
Existing experience of API merchants sending payment link in India
Design the payment type, configure the market
While studying how sellers get paid in different countries, I noticed their behavior was nearly the same everywhere. A seller shares their details and asks to be paid. What changed from country to country was the payment infrastructure underneath. Mexico runs on bank transfers, Indonesia runs on banks and digital wallets, and much of Africa runs on mobile money tied to a phone number.
So I designed around payment types instead of countries. Small sellers can share bank accounts, digital wallets, and mobile money numbers, and enterprise merchants can also send payment links and cash vouchers. Each type is a self-contained module that engineering builds once and turns on per market through configuration. This also makes local regulation easier to handle. If one country restricts a payment method, it gets switched off there while every other market keeps running.
One product constraint shaped the whole experience. WhatsApp shares the payment details, and the money moves between the buyer's and seller's own banking or wallet apps. That kept the product clear of payment licensing in each country, and it made "copy and pay" the starting experience everywhere.
One bubble for every payment
For sellers
Set up once, request in one tap
For buyers
Pay with confidence
The biggest tradeoff
Launch everywhere first
Built to grow
Tradeoff
Copying details into another app is less seamless than paying inside the chat. I accepted that because it let us launch in weeks, and I designed the starting experience so richer ones could be added later without starting over.
Everything comes together in the payment bubble. Every bubble has the same core pieces: the business name with a clear "Payment request" label, the amount in local currency, icons for the available payment methods, the merchant's message, and a button. Order details, product images, and multiple accounts show up only when a request needs them.
The button changes with the request. A single bank account shows "Copy account number." Several accounts show "View payment options." A payment link opens checkout, and a cash voucher opens a barcode. The same bubble works for a seller tapping in the Business App and for an enterprise sending requests through the API, so every improvement reaches both. The bubble and its payment options are now components in the WhatsApp design system.
Tradeoff
Brazil and India used provider logos like Pix, UPI, and Visa. Those are familiar locally, but they mean nothing in most other markets, and each one needs licensing. I switched to generic icons for bank, wallet, card, and barcode. We gave up instant brand recognition, and in return the same icon set works in every market with no local artwork.
Sellers start from the attachment tray they already use in chat. They search for their bank, wallet, or mobile money provider, and enter their details once. After that, a payment request takes one tap, with an optional amount.
Onboarding had to work with thousands of providers, each with its own rules. The flow adjusts to each one. If a market supports only one account type, that step is skipped. If a bank lets sellers use either an account number or a phone number, an "Add account by" choice appears, and otherwise the form goes straight to the one field that applies. Bank accounts, wallets, and mobile money all follow the same logic, and sellers can save up to 10 accounts across all three.
Seller NUX
Add a new payment account
Seller PUX
Send in one step (Single account)
Buyer copy account number (single payment option)
Seller PUX
Send in one step (Multiple accounts)
Tradeoff
A single adaptive flow means some providers get a more generic form than a custom-built one would offer. In return, one flow covers every provider in every market, and new providers are added through configuration.
Buyers had been receiving raw text with no sign that it was legitimate. The "Payment request" label makes it clear they're being asked to pay, and the business name shows who's asking. Copy buttons replace manually selecting account numbers, which was the biggest source of friction and failed payments.
When a merchant offers several options, the buyer sees them grouped by type, each with its own copy button. Payment links open a familiar checkout page. Cash vouchers show a barcode, amount, and expiration date that buyers present at a convenience store counter, which brings in customers who don't use banks or prefer cash.
Buyer copy account details (multiple payment options)
The largest decision was about scope. Market-specific designs would have felt more at home in each country, but they would have brought back the slow, one-country-at-a-time pace we were trying to leave behind. Timing made the choice clearer. The Business AI team was launching in these same markets and needed payment requests ready so AI agents could send them for businesses.
I pushed for one design that works in every market and worked closely with engineering to keep every decision buildable once and configurable everywhere. We planned to go deeper in the markets where adoption or business investment justified it. Being available everywhere came first, and refinement came next.
Merchants integrate once, and buyers get a better experience as the platform adds features, with no extra work from the merchant. Today a buyer copies an account number. Next, the same request can open the buyer's banking app with everything filled in. After that, payment can be confirmed right in the chat. Payment status was the first of these steps to ship, and it fit into the existing bubble.
Reflection
I came in wanting a design that would feel right in every market. What I shipped is a strong starting point rather than the most tailored experience any one country could have, and the modular parts are what made that acceptable. On a product going from 0 to 1, the "1" doesn't need to be complete. It needs to cover most of what people do and be able to grow into the rest.
Money changes how people behave, and a buyer who feels unsure simply stops. That pushed me toward restraint. Where we couldn't guarantee a safe transaction or protect someone's personal information, we kept the payment out of the chat and let people finish in the app they already trust. Trust in a payment product is earned slowly, and a product that oversteps early spends credibility it hasn't earned.
I started this project intending to invent a new component and went fairly blue sky with it. The WhatsApp design team pushed back hard, since familiarity is part of what makes people trust a product, and every new pattern makes the system harder to hold together. What worked was building on what was already there. I took the existing patterns and extended them into something more flexible that could carry every payment case we needed, so buyers still recognize what they're looking at even though it isn't what the library had before. Those components are now part of the system. If I did this again, I'd bring the design system designer in from the start, so we're shaping that together instead of negotiating it late.