Stored Payment Methods

Get paid on time, on your terms

 
 
 

Opportunity 💡

For years, HubSpot’s Commerce Hub users had been requesting the ability to store payment methods, a feature commonly referred to as “payment method on file” or “vaulted payment methods.” Based on our competitive research, we knew this was a table stakes feature and was described as a blocker to adoption by our commerce support specialists. As we approached 2024, leadership decided to make it the product line’s top priority for the year. I was assigned as the UX and product DRI for the project.

 

Approach 🧪

Step 1: Secondary Research Analysis

While it was clear that Commerce Hub needed to support stored payment methods, I wanted to get clear on the main use cases our customers wanted stored payment methods to support. The first thing I did was I went through 12 months worth of customer feedback and tagged the primary themes.

 

Step 2: Customer interviews

From there, I validated the primary use cases through user interviews, capturing more qualitative data to fill out the entire picture.

 

Step 3: Analyze data

After these interviews, I went back through the transcripts and tagged the primary themes of the calls, triangulating my insights across the interviews and previous customer feedback.

 

Step 4: Pitch solution to leadership

Once this data was assembled, I drafted some high level mocks and proposed to leadership both an MVP solution and several milestones we would need to support shortly after our first release.

The MVP was approved so I moved on to refining the designs

Step 5: Design Exploration and refinement

My solution spanned across 5 different teams. So my design exploration process involved working with several other designers, to better understand context of their domain and discuss the benefits and tradeoffs of various approaches. Eventually, we were able to develop a few different options for the experience we could test with users.

Step 6: User testing

I ended up testing two different prototypes with customers. A few things we learned were:

  • Having visibility into who at their company initiated a charge was essential, and if those charges failed, they wanted a merchant facing email notification with a decline reason. This would help them understand if they needed to retry a charge or reach out to the buyer for a new payment method.

  • Customers do consider storing payment methods to be a general policy, but they do need a way to waive that requirement. This meant that we needed both a global setting and a way to opt a customer out of that feature.

  • We also learned that while merchants do need to comply with cardholder requirements in order to use stored payment methods, many of them expect to do so outside of the Commerce Hub experience. This allowed us to be less restrictive with the feature.

  • Some customers were surprised that checkbox consent was required at checkout in our prototypes.

Step 7: Kickoff and milestones

Equipped with these findings, I adjusted the designs to reflect the new settings, worked with legal and our knowledge base article team to adjust our terms and payment method consent, so that the feature was less restrictive. Lastly I re-scoped the milestones based on customer feedback and engineering LOE estimates.

Conclusion 🧐

 

6 months after its release, stored payment methods ended up with a 50% adoption rate in Commerce Hub and had generated 3.1 million dollars in revenue. The only other feature that received a comparable adoption rate in the past two years in Commerce Hub was the release of invoices.

Below is a recording of merchant-initiated charges in production today!