WhatsApp Brazil
Payment Requests
In Brazil, businesses sell through WhatsApp chats and get paid through Pix, the country’s instant payment system. A request with the amount attached is what native and one-tap bank payments in WhatsApp will build on, and the first version, which required an amount on every request, cut Pix sends by 20 to 25%. The required field was the obvious suspect, so before changing it, I designed a four-variant experiment to find which part of the flow had actually failed. The cause turned out to be the full-screen sheet, and the half-sheet version that shipped to every SMB merchant in Brazil lost no transactions, while merchants sent 4.8% more Pix requests.
No structure, and no amount
For many Brazilian businesses, the shopfront is a WhatsApp thread. Someone asks a baker for a cake, a seamstress for an alteration, a shop for a delivery. The order, the haggling, and the payment all remain in the same conversation. Money moves through Pix, the central bank’s instant payment system, which settles in seconds and identifies an account through a short key rather than full bank details.
Originally, payment requests lacked a consistent framework. The merchant would send their Pix key, followed by the customer copying it, pasting it in their bank app along with the amount owed, and paying directly there. With the onus on the customer to reliably provide the amount, confusion, inconvenience, and even fraud were common. To remediate this, a first attempt at structuring payment requests required an amount on every request.
Merchants sent 20 to 25% fewer Pix requests, and the team paused the experiment. Dropping the amount wasn’t an option, because native and one-tap bank payments depend on knowing it, so the team needed to find out which part of the flow had caused the drop.
The key arrivesin the thread
the amount is manually noted
in a bank app
Isolating the cause through four variants
When it came to translating hypotheses to designs, we could not afford to be simplistic and miss the underlying reason altogether. The drop in transactions may have derived from the mandatory field, from where the field sat, from the interaction it demanded, or simply from the shock of a new pattern replacing a familiar one.
To address this ambiguity, I designed four variants, each testing a different hypothesis about the cause of V1 failing. After aligning component usage with the core WhatsApp design team, I partnered with engineering in launching a live experiment that ran each variant at 2%, then the two strongest at 10%, then the winner at 50% and 100%. I prototyped all four variants using Claude Code first to lend substance to each treatment and provide interactive grounding for the team’s discussions.
V1 · original
Amount required
The original design. Pulled at about −20%.
V2 · shipped · +4.8%
Optional, half sheet
Shipped. Lost no transactions, and merchants sent 4.8% more Pix requests.
V3
Adding an amount helps customers pay the correct price.
Send requestRequired, explained
Tested whether explaining the amount would rescue a required field. Pulled at about −20%.
V4
Optional, full screen
Tested whether making the amount optional was enough. Lost 21% in a full-screen sheet.
Across the variants, I followed two principles shaped by the likely reasons V1 had lost merchants:
Balancing levels of explaining a new paradigm
While working on the variants, I bumped against a recurring question: how much education does a new payment paradigm require? Only V3 added one line beside the field, and it lost as much as V1, so explaining the field didn’t help.
It took iteration and exploration to reach a consensus. I first attempted to fold visual education into the Payment Request screen but found it too crowded, so I compromised with a bottom sheet layered on top, set to appear three times before permanent dismissal and to stop for good once a merchant sent a request. I ended up dropping this variant after discussions with my content design partner and collectively deciding that it front-loads explanation before the merchant has seen the field it describes. Research and partners further pointed out that people do not read bulleted explainer sheets, especially in Brazil where visual language is the top method of communication.
Two entry points, one destination
Merchants can initiate a payment request from two places: the attachment tray inside a chat, and Payments Home. The tempting move was to build each native to its own surface, which would have produced disparate experiences. Instead, I purposefully routed both to the same destination. Whichever door a merchant enters, they land on functionally the same payment request flow, with one important caveat. From Payments Home, where there is no conversational context, the merchant selects a contact from whom to request, while in a chat already conversing with a buyer, the request is pre-filled with that same buyer.
Both scenarios also fold in Pix key onboarding first, in the case where a merchant has not added one yet, so they never have to exit the current flow to complete onboarding elsewhere. Designing the two in parallel is what kept the work consistent, since every variant had to hold up for two entry points across both new and returning merchants.
from the attachment tray
from Payments Home
A 20% loss, turned around
2% per variant → 10% → 50% → 100% · about 104K users per condition
Shipped 100% of SMB merchants, May 14, 2026
The results pointed away from the obvious suspect. V4 made the amount optional and still cut transactions by 21%, about as much as the versions that required it. Every variant in a full-screen sheet lost around 20%, whether or not the field was required and whether or not we explained it, and only V2, the half sheet that kept the chat in view, didn’t lose transactions. Customers paid as often as before, merchants sent 4.8% more Pix requests, and V2 shipped to every SMB merchant in Brazil on May 14, 2026.
That left a tradeoff. V4 got an amount on 56% of requests and V2 on only 13%, and we chose V2, because a request with an amount only matters if someone pays it. Had we fixed the obvious suspect first, we would have shipped V4 and lost a fifth of transactions a second time.