ShopeePay Scan & Pay

Designing a scalable payment experience across Southeast Asia

ShopeePay Scan & Pay phone mockups

Overview

ShopeePay and AirPay were operating as separate products across six countries. I led the end-to-end design of a unified Scan & Pay experience that could scale across all markets while accommodating local requirements and business priorities.

My Role

Sole Product Designer

Scope

End-to-end (Research → UX Strategy → System Design → Delivery)

Impact

  • Unified payment experience across 6 markets
  • Reduced complexity in multi-payment scenarios
  • Enabled faster rollout of new payment methods and promotions

The Challenge

ShopeePay operated across six Southeast Asian markets — each with its own payment infrastructure, compliance requirements, and user expectations. The existing designs were fragmented and difficult to maintain.

  1. 1. Market Fragmentation — SG, ID, MY, PH, TH, and VN each had distinct flows, inconsistent UI patterns, and separate codebases.
  2. 2. Promotion Complexity — Vouchers, cashback, and loyalty points had to display and calculate differently per market, creating confusing checkout experiences.
  3. 3. System & Compliance Constraints — Back-end systems and regulatory requirements differed significantly, limiting how much the UX could be unified without engineering rework.
Challenge: original designs across SG, ID, MY, PH, TH, VN markets

Competitor Analysis

I conducted a thorough competitor analysis across all six markets — examining how local and regional payment apps handle scan-to-pay flows, amount entry, confirmation steps, and promotion display. This helped identify patterns worth adopting and pitfalls to avoid.

Competitor analysis: payment apps across ID, TH, VN, PH, SG, MY

Key insight

The level of payment complexity directly shapes the UX structure in various countries. This insight informed how we structured flexibility in our design.

Similar check out flow

Similar checkout flow: Scan → Input/Show Amount → Confirm Payment → Payment Result

Differences

  • The order of features
  • Payment method
  • Discount
  • Design patterns
  • Compliance

The combination of these differences will affect the final design of an app.

For example:
Wechat Pay have several payment methods, so it better separate input and payment methods in different steps.
Grab Pay just support 1 payment method here, so it can contain all features in same page.

WeChat Pay and Grab payment flow comparison

User Research & Testing

Prototype Testing

We created two design variations and tested them with 10 users from diverse backgrounds.

  • Goals:
    • Compare usability across different flow structures
    • Identify friction points in payment decision-making

* The links are not publicly available due to privacy restrictions

Prototype testing sessions

Offline Field Research

We conducted in-store testing in shopping malls and interviewed both users and merchants.

Key learnings:

  • Users struggle with combining vouchers, balance, and payment methods
  • The motivation of using ShopeePay is rewards.

After receiving feedback, I discovered that the current design issues require better integration of voucher, top up, and password-free payments into payment.

Offline field research in shopping malls

Additional Feedback Channels

Beyond direct user research, insights were gathered from multiple stakeholder channels to triangulate findings and align on design priorities.

Key Insight

Feedback from app store reviews, local operations teams, and regional PMs often pointed to the same core usability pain points — validating the research findings.

Design Implication

Stakeholder input was used to prioritize which market-specific adaptations were essential vs. optional, helping define the flexible-core model for the design system.

Feedback channels diagram: app store reviews, local PM proposals, regional PM proposals

Real-World Constraints

In large-scale systems, design decisions are deeply constrained by reality. Instead of designing for the ideal case, we designed for adaptability under constraints

Design Strategy

Based on research and constraints, we defined a key principle: Standardize the flow, but allow flexibility in configuration

The back-end system is incompatible

  • When the amount of development projects is huge, they will choose to modify the design plan to compromise.

Admin system has insufficient functions.

  • Generally, we will communicate with the local in time to upgrade the admin system.

Compatible with access requirements of different services

  • Different countries will have access to different services, such as payment methods and different financial services.
  • Different countries have different compliance content

Business Priorities

  • Frequent changes in promotions and payment methods

Solution: A Scalable Payment System

The final design establishes a unified Scan & Pay architecture that supports both scan modes — Customer Scan Merchant and Merchant Scan Customer — across all six markets.

Standard Flow

  • Consistent scan entry point across all markets
  • Standardized amount input and confirmation screens
  • Unified payment result and error states

Flexible Adaptation

  • Promotion and voucher display adapts per market rules
  • Multi-wallet and payment method selection configurable
  • Compliance copy and disclaimers injected per region
  • Cross-border payment scenarios handled as optional layer
Solution: Customer Scan Merchant and Merchant Scan Customer flows across markets

Impact

  • Unified Scan & Pay experience deployed across 6 Southeast Asian markets
  • Reduced design and engineering complexity in multi-payment scenarios
  • Enabled faster rollout of new payment methods and promotional features
  • Established a scalable design system reusable for future payment flows

Key Learnings

  • Designing for scale requires separating the universal core from market-specific layers early — trying to reconcile them later is far more costly.
  • Stakeholder alignment across local and regional teams is as important as user research; without it, even well-validated designs can stall at implementation.
  • Real-world constraints — system architecture, compliance, business priorities — are not obstacles to good design but inputs that shape a more durable solution.

Thank You

ShopeePay thank you illustration

See More Works