A project to capture and store credit cards(CC) in a PCI-compliant way to provide quality care
Foresight Mental Health(FMH) is dedicated to leveraging technology to improve mental healthcare and lifestyle. Currently, FMH has over 10k members with recurring revenue. As FMH grows immensely in a few years, meeting security and compliance regulations is inevitable. That got us to start the payment initiative and stabilize the cash flow to provide affordable and quality care.
With Foresight Mental Health’s payment feature, member users can securely upload their valid credit cards and store them in the system. This will streamline the appointment booking process. Operator users can execute the payment with stored credit cards, reducing unnecessary data entry. This will streamline the workforce and optimize cash flow.
.jpg)
The chart shows the milestone steps and the whole process that guided us from discovery to delivery. Even though we went through extensive mappings, there were some hiccups during the whole process. So we needed to do some replanning and went back to mapping exercises.
Constraints
• Time constraints to build 3 features in three different platform for two users (members and operators)
• Technical constraints for the first time Stripe integrations
We had big issues with collecting members' CC info, and that issue affected collecting service fees. These problems must be resolved quickly for us to mitigate any risk to our core business.
1. 100% non-PCI-compliant way of collecting credit card information could lose member’s trust
2. Failing to collect at least 15% of Accounts Receivable(AR) payment transactions because of not validating credit card information
3. Spend average of 10 minutes to figure out double data entry per claim (~1000 claims per day on April 8, 2021)
4. Roughly 40% of the outstanding payer is the result of incorrect claim data
by capturing and storing credit card information in a PCI-compliant way
by improving information accuracy at the point of capture and reducing double data entry
First, I started by shadowing operator users' workflow. That really helped me to understand how the payment process works. While watching and listening to their day-to-day tasks involved a lot of manual work, it was very frustrating to see how inefficient workflow we offered at that time. The following three big problems cover most of the frictions both users(members and operators) face at that moment.
1. Not meeting regulatory compliance
2. No credit card validation
3. Inefficient workflow involved lots of manual steps
.jpg)
• who needs to save a new valid credit card
• who wants to view/edit/remove the credit card
• who needs to save a new valid credit card
• who wants to view/edit/remove the credit card
After learning and gathering insights from operator users, Alan, the PM and I studied the use cases of each user(member and operator) and prioritized the importance.
%20PCI%20Compliance%20MVP%201.jpg)
We found there are two main types of payment that require a member payment today:
1. Member Copay: What the member owes upfront for each provider visit
2. Outstanding balance (i.e. out of pocket, deductible): What the member owes after a claim has been submitted and the insurance determined there is a remaining amount due that is not covered by insurance.
For the purpose of this project, the member copay is the main issue that needs to be addressed since it takes over 80% of the payment method. Therefore, the team decided to leave the outstanding balance separately for future enhancement.
After learning and gathering insights from operator users, Alan, the PM and I studied the use cases of each user(member and operator) and prioritized the importance.
Creating familiarity can be helpful to make users ready when they experience our product for the first time. Knowing where to find key actions, using standardized gestures, and structuring content in a way that is familiar gives users the feeling of control and safety to navigate with confidence and manage issues by themselves.
That's why I started to look at other products on the market to understand how they layer out information and structure their payment page.
Insight #1
Ask for essentials only. Or it could stop users from proceeding or finishing the form.
Insight #2
Tell users what went wrong. When something goes wrong, it's helpful to let users know exactly what happened rather than let them figure it out.
Insight #3
Reinsure users of their security information.When users first skim a credit card form, they often ask themselves, "Is this form secure? Are they just spoofing my card details?"
The new workflow is reorganized in a more intuitive way while meeting the security compliance by offering data sync with Stripe.
Here are three solutions aligning with the business goals:
• Introduce the secure credit card form in the new member booking flow. So we can clear out asking CC information in the consent form to avoid double data entry.
• Utilizing Stripe's validation process in the credit card form. So we can get accurate information at the moment of capture. That eventually allows us to eliminate the frictions between members and operator users.
• With Stripe data integration, we could create an organic structure. That enabled us to remove manual workflow for operator users.
Introduce the credit card payment form for member @new member booing flow
Member booking flow is for new members where they can make an appointment by themselves. The flow itself already exists, but this payment page is new. So I carefully explored where would be the best placement for the credit card form since we are introducing this page for the first time in this particular flow.
After the discussion with the member success team, the following is the reason why we picked the option 3:
• Option 1: it could make sense to group requests as personal information with name and DOB... but it’s too early to ask for the card information since it’s the third step of the whole flow. It could stop users from proceeding or finishing the form
• Option 2: it could make sense to ask for the card information right after explaining the price summary, but members still haven’t got an idea if they can book a session at this stage of the flow
• Option 3: it makes the most sense after everything is set. At this point, a member knows who and when he will have an appointment and how much is.
After concluding the placement, I started rough sketches. UX priorities include:
• Only ask for essentials that required from Stripe to validate the credit card information
• Ensure users of their card security
• Reduce uncertainty about how and when the card will be used
• Make the transition between 3rd party integration and Foresight as smooth as possible
Between different design options, I tried to think what would be the most scannable form while only asking required information. I also considered smaller screen users from an accessibility standpoint.
Member booking flow is for new members where they can make an appointment by themselves. The flow itself already exists, but this payment page is new. So I carefully explored where would be the best placement for the credit card form since we are introducing this page for the first time in this particular flow.
By designing it from the ground up, I’ve brought what’s relevant – security message, real-time feedback, and card validation.
1. Building trust
• By displaying the message clearly of how and when members' credit cards will be used
• By showing a security message to ensure members that their entered payment information will be stored securely
2. Real-time feedback
• Prevent confusion by showing instant feedback about their input. The form automatically detects the card type and displays it while entering.
3. Card validation
Utilizing Stripe's validation process, we can get accurate information at the moment of capture. If users encounter an error, we tell them what triggered the error and visually indicate that.
I also tried to write detailed copy as much as possible to reduce uncertainty. For example like the second image on the screen, if a member enters the American Express with incorrect number of digits, we displayed the error message with “American Express card should contains 15 digits.”
Enriched payment page for member @member portal
The member portal is where members can log in and check their health profile and schedules, send messages to providers or check their account information.
In the Credit Card page, members can add a new card and view or remove the existing card. This new design lets users control their credit card information. Also, I brought clarity to the Call To Action and made the list of multiple credit cards easy to scan. While designing, I also consider if this could be a scalable design. For example, things like what the page would look like when there’s a single card or there are multiple cards.
Before, the page was limited to a single card.
After
• Members can add multiple cards of their choice. So they have a secondary payment option if the default credit card is not available.
• Since members can have multiple cards on the account, they can select a default card for a future payment.
Before, when a member open the Credit Card Page, it opens a single payment form.
After
• With the new design, I added an introduction page with why we collect the card information and how their card will be used to reduce uncertainty
• In the action of adding a new credit card, I implemented the same form that’s designed in the the new member booking flow. So we can streamline the user journey consistently and also speed up the engineering development process.
Before
• The old page with old legacy code didn't have a function to validate the card. So when users tried to save their invalid card, they could store their card anyway, and the form showed a success message.
After
• Utilizing Stripe's validation process, we capture accurate card information.
• On top of that, displaying specific error messages and visual indication by highlighting each input field increase clarity of the form
Payment feature for operators @member profile page
Placed on the member profile page under the operator’s account. The member profile page is where operators can search all information related to each member, including appointment history, insurance information, health profile, and etc.
But before I designed this feature, the team already had a plan to create a whole new page called the Payment page for future enhancement. This feature is more like what needs to be added for the MVP launch, but don’t spend too much time for it. So I came up with a quick fix idea as adding a payment column on the current member profile page.
Initial idea
Adding the Pay button under the Action column. But I had feedback from a user that this placement could confuse operators since other buttons(edit or delete) are related to control appointments.
Iteration
Based on the feedback, I was able to create Payment column next to Action column.
With the idea of where to place the pay button, I was able to create wireframes considering edge cases such as what if there's no credit card on the system or what if there's a Stripe connection error or which screen or message should I display.
• Adding a payment column allows operator users to execute a copay payment against a member inside the Foresight portal
• Operators can easily scan the status of the payment with the button type (pay or view)
• Some of the detail we added here was the pay button is only available on the appointment date or after. So we can keep the promise to members that we only charge after the appointment.
• After payment is made, we display View button instead of Pay button. In this way, operator users know whether the member is charged or needs to be charged. With this new design, they don't have to go through different platforms manually.
• With stripe integration, it's just one click away from each transaction detail or a refund process.
Over
collected within a month of launch on copay alone
Reached
of copay collection rate
Thinking back & looking ahead
#1 Remember the power of data and research
Based on research, we had an idea that we probably need to change the payment vendor for a more robust product for future business. Unfortunately, this project was very time-sensitive and we needed to keep going, so we didn’t pay attention to the research data. Huge mistake. And eventually needed to turn around, and that actually slowed down the process.Learned listening to different voices and data-backed planning is terrific for the success of the project.
#2 Plan to replan
Not every project goes 100% as planned. I'm sure there are always small or big curveballs throughout the project. Especially, the payments are connected with hundreds of micro-services and on top of old legacy code that could easily have taken weeks to understand the logic. One of the biggest learnings was the ability to quickly act and replan in case we face a wall.
#3 Design systematically
Introducing new features doesn't mean simply adding a line or an icon to the UI. All products are expected to grow and evolve over time. That's why the questions like, "What's next after this," or "How can I design scalable product”, helped me to decide from different design options and prioritize what was relevant for users.
