Case Study: Third-Party Payment Terms in Checkout

Enable B2B buyers to "buy now, pay later" through a third party, boosting sales.

Summary

Over 3.5 months, I expanded the design of an existing payment term solution to integrate a third-party payment term company. Through proactive communication with stakeholders in both companies, identification of personas, and thorough charting of user flows, I produced a prototype of over three dozen affected screens which were successfully implemented about six weeks after design completion.

Background

Businesses often make larger purchases than individuals and may not always have immediate funds. In a B2B setting, payments are routinely split into installments or delayed using payment terms. A company who advances payments for a fee based on the order total is called a factoring company, and when the factoring company purchases a buyer's invoice from a seller to take ownership, that step is called invoice factoring.

I was the lead designer for our platform's original payment term solution (UX requirements doc available here) which differentiated us from simpler B2C e-commerce platforms. This original design was limited by Inxeption's roles both as the seller offering net terms to our buyers and the factoring company for our own buyers.

Pain point

Invoice factoring turned out not to be Inxeption's core competency. It increased risk and led to losses. We wanted to keep the feature, but integrate a third-party company to handle invoice factoring.

Goal

My task was to integrate a third-party company to handle buyer invoice factoring, assuming the risk of advancing payments and collecting them later.

I would need to revisit the existing flow (which was complex), learn the third party's process, identify integration touchpoints, configuring the UI to be flexible rather than hard-coded to accommodate future partnerships with different or multiple factoring companies, and make sure that buyers understood their payment obligations.

In addition, I led the project after the product manager was let go, onboarding a new PM and balancing two other significant projects: a product creation redesign and a new freight shipping quoting method in the checkout flow.

Discover: Who are the players?

When I joined the project, Inxeption had already partnered with OatFi for invoice factoring. Through discussions with product managers on both sides, I got up to speed with OatFi's expected flow. Based on these conversations, I defined five "actors": a buyer persona, a seller persona, an OatFi employee persona, the Inxeption platform code, and the OatFi API.

Conversations with OatFi clarified scenarios involving manual buyer evaluations or rejection. Engineering leads explained that we could reuse existing backend screens that drove a lot of the UI, making editable fields read-only with data pulled from OatFi. This screen reuse saved time.

With clarification on the actors, processes, and architectural considerations, I moved on to aligning the team on how the feature would function.

Define: What's the flow?

To align the team on the complex flow, I created a process flow diagram of the five actors identified during the discovery phase (click to enlarge). Mapping each step and considering data sources allowed me to craft an optimal flow with input from team members. I divided the flows into the "happy path" of a new buyer applying for terms and checking out with those terms, and edge cases, like RFQs with negotiated terms.

Next, I led internal discussions to verify most steps and triggers. Visually grouping the happy path steps into phases of Setup, Shopping, and Fulfillment/Collections structured our discussions and sped up understanding.

However, we uncovered key discrepancies:

Thanks to the visibility that this diagram provided, we resolved discrepancies collaboratively.

Design: What does it look like?

For this particular feature, we were enhancing existing functionality, so I could skip wireframes and jump straight to the high-fidelity clickable prototype. Below are examples of some screens and factors that I took into account.

Table of contents

For most features, I include a table of contents that provides a storytelling framework to guide the viewer and allows team members to jump to important artboards in the prototype.

Approval notification

Inxeption would send this email after the partner's API approved an applicant. The curly braces and magenta annotations indicate how the text can be configured for different factoring partners. I also noted that the text blocks could be repeated if a buyer could simultaneously apply to multiple factoring partners in the future.

Checkout page

This mockup shows how payment terms approved for a business account are displayed to a buyer from that business. This UI can accommodate one or many approved terms from one or many factoring companies. It also accommodates variable down payment percentages including no money down.

In cases where I don't provide a separate requirements document, I use visual callouts and comments to highlight changes for developers. These annotations also double as an agenda for design review meetings.

Two challenges arose on this page, which my colleagues and I addressed:

Buyer's order details

Focusing on the lower part of the page, I defined user messaging for various milestones: newly completed orders not yet ready to ship, payment due soon, payment due today, up to 5 days overdue, and 6 or more days overdue. The wording had to satisfy both our Legal team and partners while remaining clear and concise for buyers, with a prominent CTA to pay our partner.

Although the text might seem straightforward, careful consideration was given to ensure consistency across multiple payment plans using this page. This page handled both initial payments from accepted quotes and final payments from our two payment plans. My deep product knowledge allowed me to account for all these scenarios (see early considerations in the next image).

Wording variations for different payment plans on buyer's order details

Feel free to click through the Figma prototype.

Deliver: Supporting Engineering during implementation

During implementation, I stayed in touch with the feature team to ensure the design was followed, even after the design phase was complete. After our product manager, who scheduled the calls, left, I onboarded the new PM and requested internal progress reviews. These reviews highlighted requirements that hadn't been implemented yet and helped finalize the feature. Thanks to the trust and respect between the engineer and me that had developed over the years, we could give and receive feedback openly.

Conclusion

Despite challenges—layoffs, late Legal feedback, and three high-priority projects—the project was completed successfully. This outcome was driven by my leadership and design contributions, including:

The timeline above shows that the project maintained a steady momentum from start to finish as the team refined and iterated requirements. By designing and implementing in parallel, we increased efficiency, starting development as soon as enough information was available. Unfortunately, due to a late-stage Finance conflict between Inxeption and OatFi, the partnership couldn't proceed. However, had the feature been launched, it would have provided the flexibility to integrate any factoring partner, positioning the business for a significant advantage.