Before CrossRamp India, Tylt's payment infrastructure was built for crypto-native users. Merchants could accept cryptocurrency — but Indian customers expected UPI. The result: merchants on Tylt couldn't reach the country's largest payment audience, and every failed transaction was revenue they couldn't recover.
Customer must hold crypto to pay. Merchants locked out of India's largest payment channel.
Customer pays UPI. Merchant receives USDT. Neither side ever touches the other's world.
CrossRamp India had to work for five completely different users — each with different data, different responsibilities, and different definitions of “done.” Designing the customer flow without understanding the cashier's constraints would have broken the system. I mapped all five journeys before touching a single screen.
UPI transactions don't carry information about what they're paying for. A cashier handling ten concurrent payments has no way to match an incoming transfer to the right order — unless the system forces it.
Early in testing, we saw the failure mode clearly: customers submitting old payment screenshots, claiming payments they hadn't made, or simply not paying and hoping the system would release anyway.
The fix: UTR as the single source of truth. Every UPI transaction generates a unique UTR number. Customers enter it after paying. Cashiers verify it before releasing. One requirement eliminated the entire screenshot fraud vector.
Five states. Each one explicit. No payment could move forward without the previous step confirmed.
Required customers to navigate away from the merchant's app, creating a context break before they'd even initiated payment.
The Tylt interface opens as an overlay. Customers never leave the merchant's environment. Zero onboarding friction.
Easily faked with old images. Created a manual review queue, added 10–15 minutes to every disputed transaction.
UTR is unique per transaction, issued by the customer's bank, impossible to fake. Instant, reliable, scalable.
Introduced irreversible risk. A single fraudulent release meant a merchant loss with no recovery path.
Crypto held in escrow from initiation. Releases only after cashier verifies UTR. The merchant bears zero risk from a failed customer payment.
End-to-end: deposit request → escrow created → UPI paid → UTR verified → USDT released. The entire flow designed around two principles: no step moves forward without the previous one confirmed, and the cashier always has exactly two options — RELEASE or DISPUTE.
Customer-facing flow — deposit to USDT release. Each screen removes ambiguity at the highest-friction moment.
Cashier panel — RELEASE or DISPUTE. The binary is intentional: forces a decision, creates an audit trail.
Dispute panel — full chat, UTR, and transaction history. Support resolves without engineering escalation.
Nine merchants went live on CrossRamp India. The escrow model held. UTR verification scaled. When it came time to build Brazil (PIX → USDT) and Europe (Open Banking → USDT/USDC), the core patterns were already established. We didn't start from scratch — we adapted.
“The escrow mechanic, introduced purely as fraud prevention, became the primary trust signal merchants cited when choosing to use the product. We built it to protect the system. It turned out to protect the relationship.”
After CrossRamp India shipped, I took on the cashier role myself — working trades in real time, verifying UTRs, hitting RELEASE and DISPUTE under time pressure. The cashier panel made sense on a Figma canvas. In operation, under pressure with multiple concurrent trades open, you reach for certainty fast. I went back and tightened the information hierarchy. That iteration wouldn't have happened without being in the seat.
The broader lesson: for high-stakes operational tools, the designer should use the product — not in a test environment, but in production, with real consequences. That's the only way to feel what the interface is actually doing.
Metrics and outcomes shown are directional. Specific figures reflect overall trends, not audited data.
