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:
At checkout, buyers needed to be aware of their available credit. However, we discovered that the balance tracked by our partner could lag due to delayed updates, potentially showing buyers more credit than they actually had, which could lead to overspending. Ultimately, our partner provided a different variable with an accurate credit amount.
From Inxeption's perspective, the ideal moment for our partner to purchase the buyer's invoice was at order completion. However, our partner preferred to wait until the seller marked the order as ready to ship to avoid issues like cancellations or inventory problems, which are are typically resolved during order preparation. Ultimately, we adapted our flow and UI to align with our partner's preference.
To ensure successful collections, buyers need reminders for due dates and late payments. Although our partner provided a notification template, their contract stated they were responsible for sending the reminders. In addition, they lacked an automated notification system, which would take time to develop. We pushed back, and they agreed to manually send notifications for the MVP until their automated feature was implemented.
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:
Our product manager informed us of late legal changes, including a request to click on two separate terms and conditions links—one for a general disclaimer and one for payment terms—before the buyer could complete checkout. This sounded detrimental to usability, but we were unable to meet with our lawyer until after company layoffs, when we lost our product manager. We had to start the conversation from scratch without our PM, which frustrated our lawyer. By empathizing with him, we were able to move on from that hurdle and agree that two separate checkboxes would suffice as long as they linked to the terms and conditions pages.
When I mocked up the new terms and conditions page, I discovered a discrepancy between the late fee percentage in the written terms and what was discussed in a recent meeting. To resolve this, I requested a sync call where our Legal team and our partner's Chief Risk Officer hashed out the numbers and identified other copy changes regarding APR vs. APY that had been missed earlier.
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
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:
A process flow diagram that aligned stakeholders
Mockups that accelerated requirement discussions
Persistent drive toward consensus through issue tracking, iterating, and reviewing
Attention to detail to uncover discrepancies
Proactive communication with both sides and engineering
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.