Saved credit cards - An improved checkout experience

Amilia serves 3.3 million unique end users who rely on our platform to manage their purchases, memberships and enrollments. However, we were missing a vital part of any shopping and account management system; the ability to save and authorize a credit card.

The inability to save a credit card affected both the users and administrators. Users who frequently made purchases had no way of reusing their card, nor could they tell administrators to simply “charge it to my account”. The same pain was felt by administrators, who to solve this problem, began writing credit card numbers onto sticky notes or saving the card number in the account notes.

As an extension of this issue, there was no way for a credit card to be charged a monthly amount on a continuous basis.

Understanding the problem

While I knew at a high-level what the pain points were through internal teams, I wanted to hear it from the administrators themselves. I began by conducting 20 user interviews with administrators and scouring our Help Center to see if there were credit card requests or suggestions we were unaware of. I pulled statistics from our quarterly administrator survey to find that 28% of product requests were checkout and billing improvements, and finally, I sat with internal stakeholders to learn about onboarding and sales objections related to payment methods.

After compiling the above, I was able to build 3 lean user personas. The personas were:

1. Parents
2. Small organisation administrators
3. Large scale federation administrators

Parent Persona

Initial challenges

Prior to development, we knew ahead of time some of the technical challenges, while others were discovered along the way. Our largest obstacles included:

1. Credit card sensitivity. During each release we carefully monitored usage as to catch and limit any unexpected bugs or errors.
2. API integration. Substantial effort was made to securely integrate each payment processor.
3. Sales commitments. There was a hard deadline that had to be met.
4. Technical debt. Due to legacy technology and time constraints, we injected React into Backbone and BS2 pages.

Getting started

We strategically decided to focus on users for the first few iterations as a way to empower them to save and authorize their own information during checkout. I wanted to find a friendly way of presenting them the option to save and authorize, while also adhering to checkout form best practices. I built the first flow using Moqups and tested the journey internally prior to development.

Federation Persona
Federation Persona
Federation Persona
Whiteboard Sketches Whiteboard Sketches iPhone Mocks


For 3 months we exposed 15% of our users to the new checkout form while tracking and documenting user behaviour. I used NewRelic and Hotjar to create recordings, funnels, and heat maps to better understand how our new checkout was impacting users.

Design revisions

In the beginning, NewRelic showed us that only 6% of users were saving their credit card, with even fewer users authorizing those cards. Considering Amilia processes over 800 transactions a day, 6% seemed too low for me. I reviewed the Hotjar recordings and found that users almost always missed the option to save their card to their account.

In the end we discovered that the billing information form was not required to save a card, so I removed the drawer and auto-checked the checkbox which states “Add this card to my account”.

We saw saved credit cards rise to 16% and authorized cards to 9% in less than a week.

Other changes include rewording our checkbox, and combining the option to save and authorize a card into a single checkbox. Presently, roughly 60% of users both save and authorize their credit cards.

Design Revisions

Lessons learned

This was the first Epic where we catered to solely the user for the first few iterations, and it was very exciting to be capturing large amounts of data very quickly. However, there are always lessons to be learned.

Make the time to test with real users beforehand.

Testing with internal teams is not enough to understand the true behaviour of users. Due to time constraints, we couldn’t implement the design in an effort to collect feedback, and it wasn’t until our first release that we started capturing real data.

Know what you need to track beforehand.

Be prepared to capture all necessary information prior to release. I wanted to gather demographics based on the users who passed through the new checkout, however we had not formatted Kibana to track such information in the beginning phases.

What's next?

The new checkout form is currently available to all users and is the new default. We followed up with administrators and found they are happy with the new ability to charge authorized cards, and are taking fewer calls related to payment methods and failed payments. Next steps are to add more flexibility such as continuous monthly payments, notifying administrators when user cards are about to expire, and allowing users to add more than 1 card to their account.