Merchants on Tylt couldn't reach India's largest payment audience. Every customer without crypto was a lost sale. Every lost sale was a merchant considering other platforms.
The brief was blunt: reuse the existing P2P trading infrastructure rather than build new backend. That turned this from an engineering problem into a design problem — the system already existed, it just had to speak a new language, in a flow where the customer pays UPI and the merchant receives USDT without either side touching the other's world.
Once UTR became the single source of truth for matching a payment to its trade, cashiers could verify with certainty — even when two or more trades had identical amounts. It didn't end fraud outright; customers could still submit an old or incorrect UTR, which is why the cashier keeps a dispute option. But it closed the specific gap that let customers confirm a payment without ever making one.
“The escrow mechanic, introduced purely as fraud prevention, became the primary trust signal merchants cited when choosing to use the product.”
The business goal was blunt: open India's largest payment channel without a backend rebuild, and without opening a new fraud vector. The design goal was harder — five roles, each with different data, different pressure, and a different definition of done, all running through one payment flow.
The customer taps deposit inside the merchant's app, which opens Tylt CrossRamp as an overlay. The platform starts the trade, holds the crypto in escrow, and waits for the customer to pay via UPI and confirm.
Both internal test runs and early live trades surfaced the same friction points:
Amount to pay, UPI ID, and a scannable QR moved up front. A new UTR field was introduced — the unique 12-digit number every UPI transaction generates, issued by the customer's bank. Customers can only submit a trade once they provide it, which directly closed the fraud-submission gap and gave cashiers an exact reference to match against.
Even with UTR required, some customers submitted an incorrect or outdated number. The cashier checks the UTR against the actual payment received on their UPI app or linked bank account, then decides in real time: RELEASE to confirm receipt, or DISPUTE to reject it. It held up even in cases where two or more trades had identical amounts.
The mobile cashier view required a lot of back-and-forth across concurrent trades. The desktop version puts new offers, active trades, and the RELEASE/DISPUTE decision on one dashboard — built for a cashier running several trades at once under a countdown.
A disputed trade goes to support, who open a chat with both customer and cashier, request proof of payment, and check it against the submitted UTR. Depending on what surfaces, they reverse the escrow back to the cashier or settle it toward the merchant.
Once escrow and UTR-matching proved out in India, the underlying model — customer pays local fiat, merchant settles in crypto — carried into Brazil and Europe. What had to be rebuilt each time wasn't the model, it was the local rail: Pix in Brazil, KYC-gated Open Banking in Europe. Neither market uses escrow the way India does — the design language and state-management patterns are what carried, not the mechanic itself.
After launch, I took on the cashier role myself for a period and made a hierarchy fix based on what felt wrong under pressure — but I didn't document the specific change well enough to speak to it with precision today. Next time, I'd log what changed, not just that something changed.
The UTR result is directional, not measured — fewer disputed trades, fewer “wrong transaction” mismatches, but no clean before/after baseline was ever captured. If I were doing this again, I'd push for that baseline before shipping, so the result didn't have to rest on a qualitative read.
Metrics and outcomes shown are directional. Specific figures reflect overall trends, not audited data.