Before we had
An Embedded Flow
A flow that does not allow re-using methods and does
not follow consistent design language
We made
smallcase Checkout
An integrated payment flow that can seamlessly be
used by all use cases on smallcase
Context
Why do we need a Custom Checkout?
For introduction of new products which require multiple gateways, owing to their requirements.
To allow users to save and utilise their preferred methods across the platform.
To improve messaging of essential contextual information related to the payment.
To provide a payment experience consistent with our design language.
Understanding the problem
User Research
Actually...
Here, I will go over specific design problems I had to solve while working on this project. Since payment checkouts are a very common type of user journey, users often have concrete mental models for them.
Header & Payment Details
Payment details needed to be customisable to accommodate different payment use cases
The user should be able to find answers to the following questions when they look for payment details:
🤔
How much do I have to pay?
🤔
How was this amount decided?
🤔
Is this a recurring or one time payment?
STEP 1
Designing the component for the primary use case
Final design
Version 1
Version 2
Version 3
Default collapsed view
Expanded view
Simplified amount in he header
Type of payment and the use case for which which it is being made.
Simplified by collapsing details and showing the main data point: Total amount
On expanding, the necessary product details can be seen in a simple manner
STEP 2
Scaling the component to multiple use cases
The expanded Product Details section shows the amount to pay and the rationale behind it’s calculation.
While some use cases (like the one shown above) have conditional rationale attached to the pricing, others have a more arithmetic breakup. To cater to this, I came up with 2 variants of the component:
List format
To be used when the breakdown is conditional. This requires more text-based information using natural-language copy
Example: Subscribing to smallcase
D = (For A, set amount for B) - C
D
Amount to pay
C
Savings from offers
B
Duration of plan
A
Selected smallcase
Table format
Suitable where the amount is calculated based on addition or subtraction of components
Example: Repaying unpaid interest on loan
D = A+B+C
D
C
B
A
Additional Information bar
People dropped off because they didn’t know how Autopay Mandates work. We created an info bar to educate them.
As per security guidelines in India, users are required create Autopay mandates to allow recurring debits.
Each mandates has a maximum limit per debit set as per the full subscription amount.
An issue occurs when the user applies a one-time-only offer coupon on their subscription. Let’s see how:
How Auto-Debits work with Offers
Auto-debit 1
One-time ₹500 offer applied, discounted amount
- ₹ 1000
Auto-debit 2
Offer exhausted, reverted to original plan amount
- ₹ 1500
A user’s journey through subscribing with an offer
Wuhu!
You saved
₹500
Set up
autopay for
₹1500
₹ 1000 was debited by smallcase
🙂
“I’ll go for the ₹1500 plan for this smallcase”
🤩
“Oh wow, I got a ₹500 discount"
😰
“Wait what?! Where did my savings go?”
😮💨
“Oh okay, they only debited ₹1000”
31% users dropped off here
Solving this problem through explicit communication
Final design
Initial ideas
By giving this information it’s own space, we can call out the mismatch before it causes any confusion later.
This bottomsheet explains how once the offer runs out, the user will be charged the full amount, and thus the set limit of the autopay.
Fun fact!
Originally, the company providing the tech for this flow did not have this component readily available. After specially developing it for us, they saw value in it and have started advising other clients to use it for recurring debits 😄
Payment Option Selection
One-click payments are fast but they also lead to more errors. Positive friction is needed.
While designing the payment flows, my basic assumption was “Lesser the clicks, easier the workflow.” Therefore, I initially designed single-click flows for online methods like UPI (Indian version of Zelle).
Version 1
However, we found out that this leads to a significant decrease in success rates as people end up clicking on these options by mistake. So I adjusted the design as follows:
Version 2
This reduces the risk for error as the person selecting the option gets to a second to review their selected option, in turn reducing the need to cancel the transaction to go back.
Preferred Payment
70% payment methods were saved, but were not available to reuse before. Returning UX became very important.
Users could save multiple payment methods, which could increase the decision making time due to increased options on the screen (Hick’s Law).
To tackle this, we have the Preferred Payment section that prioritizes the saved method based on relevance for faster selection.
I went with a card format, to add emphasis on these methods using color and size.
If you decide to save more than 2 methods, the lesser relevant ones are shown as part of the category they belong to.
Payment flows
People are comfortable with existing payment flows. So, we kept it simple and didn’t reinvent the wheel.
Check out (pun intended :P) the full prototype of the entire payment experience in the prototype below:
Results
Payment success rates increased by 21%
This raise can be attributed to the extension of functionality in the payment flow along with a simplified UX. Along with this, it was noted that 36% payments were happening through a saved payment method.