Every Grab vertical had built its own checkout. I led the design of a shared payment framework that keeps checkout consistent where it matters and flexible where products differ.
My role
Led the end-to-end design: workshops, design direction, UX exploration and UI for PaySDK Prebuilt, Components and P2M integration.
Team
Payments team, with product, engineering and designers across verticals.
Impact
Aims to improve checkout consistency, payment completion and integration speed across Grab.
The challenge
GrabFood, GrabMart, Dine-in, Transport and Grab Unlimited each had their own checkout flow, online and offline.
Where we started
We had already started improving payment experiences, prioritizing the most visible and frequently encountered issues, such as error handling and payment method lists.
One error framework so every Grab service explains failed payments the same way and suggests a fix.
View the case study
A clearer list of payment methods so users can pick and switch methods with confidence.
Establishing a unified framework to guide different payment flows and scenarios across Grab.
Vision
Meanwhile, Engineering was starting to unify the PaySDK infrastructure, creating an opportunity for Design to address the bigger problem and establish a scalable payment design framework.
Ensuring a smooth and unified payment experience for all Grab users and partners, enabling easy payments and transfers across channels.
I collaborated with fellow designers to define the PaySDK integration approaches and align on a shared design foundation.
Fully optimised checkout flow for your app or website, with seamless payments and minimal front-end effort.
Flexible checkout components that embed directly into your product while using GFin's capabilities.
Lets a business build a fully customised payment flow by working directly with PaySDK backend APIs.
A scalable in-person solution with UX and tech support for card tap and QR payments.
Principles
The main challenge was that different products needed different payment features, but we still wanted to provide a simple and consistent checkout experience.
So I used three principles to guide my design decisions: simplicity, consistency, and flexibility.
Help users complete payments quickly and confidently.
Keep familiar payment patterns across products.
Support different features and business needs.
The key question was: what should remain consistent across every checkout, and what could be flexible depending on the product's needs?
To answer that question, I started by comparing existing payment flows to identify which elements were essential across different experiences.
Deep dive
Of the four integration approaches, the rest of this case study focuses on Prebuilt: a fully optimised checkout flow that product teams can drop into their app or website with minimal front-end effort. It is where the shared design foundation is applied most directly.
Information architecture
I reviewed existing checkout experiences and compared their information requirements.
I identified three common elements around the payment decision, while other information varied depending on the use case. This helped establish what needed to remain stable.
Example of simplicity
I prioritized the amount users need to pay, while keeping detailed breakdowns accessible when needed.
Visa 1345
Add offersVisa 13451 offer applied
Pay in 4 instalmentsS$112.50/month · No feeAdd offersPayment details get complex depending on the use case: offers, rewards, instalments and more. Showing everything upfront would overwhelm users, so I decided to show only the most important number, what they need to pay today. The full breakdown lives on a details page for anyone who wants to understand more.
User testing
I tested two layouts with users. Option 1 placed the final amount near the payment action. Option 2 emphasised the amount at the top of the checkout.
Option 1 won. It gave us a more familiar and scalable checkout layout:
Final design
The client page starts checkout, the Prebuilt SDK handles payment, and the result goes back to the client.
The same structure adapts to different payment needs.
Flexible by use case: Additional payment features
Applied Prebuilt to P2M, leading the collaboration with the Lending team to address complex payment scenarios.
Flexible by use case: Product-specific information
Added a product details component to help users review their subscription before payment, while preserving the core checkout structure.
Alignment
Worked with engineering to clarify dependencies, timelines and implementation trade-offs.
Defined the guideline structure and coordinated contributions across designers.
Worked across teams to align research planning and share findings.
Impact
What we achieved
Established a reusable checkout framework.
Aligned teams on shared payment principles.
My reflection
What I learned from this project is that designing at scale isn't just about creating reusable components.
Different products have different needs, so I had to think carefully about what should stay consistent and what could be flexible.
And because many teams were involved, alignment was just as important as the design itself.