Enable B2B buyers to "buy now, pay later" through a third party, eliminating losses

A Case Study: Third-Party Payment Terms in Checkout

Pain point: Inxeption was losing money on payment terms and needed to integrate a third party to assume the risk

At Inxeption, we used our own ecommerce platform to sell products. We offered payment terms, meaning buyers could purchase now and pay later, giving us an edge over simple B2C e-commerce platforms. We were also acting as our own factoring company—approving applications and collecting funds later.

Unfortunately, factoring was not our core competency—we sometimes approved buyers who couldn’t pay, which introduced risk and led to losses. To fix this, we decided to integrate a third-party factoring provider, OatFi, to take on that risk.

Outcome: I resolved gaps in requirements to successfully deliver the integration

Through proactive communication, diagrams, and prototypes, I caught critical gaps in the proposed requirements that, if not caught early, could have caused major problems. I led conversations between stakeholders to resolve these issues, stepping up when product management was short-staffed.
As a product expert, I identified the affected screens of this complex flow and adapted only the necessary portions for efficient implementation.
We successfully completed the integration in six weeks.
The integration shifted responsibility for invoice collection to the third party to eliminate financial losses.
We designed a scalable framework that could support other factoring companies in the future.

Sample Mockups

1) Buyer applies for payment terms, described as "Financing" here.

2) Buyer receives approval email. Curly braces indicate where the service name will be dynamically inserted for future scalability.

3) Buyer monitors approved terms and credit usage. Page dynamically displays the service name.

4) Buyer pays for orders in checkout using preapproved payment terms, which reflect the service provider. Page can accommodate multiple terms and variable down payment, including no money down.

Open Figma Prototype

Figma shows annotated instructions to engineering and QA

My goal: to adapt the existing flow and screens for a third-party factoring company

Inxeption's original payment term solution wasn’t built for external factoring, requiring us to find an efficient integration method.

To gain clarity, I would need to:

Interview both our team and the third party
Learn the OatFi process—identifying integration touchpoints—and map it to our process in a flow diagram
Reconfigure the UI to display third party content rather than hard-coded Inxeption information
Ensure a clear experience so buyers understood when, who, and how much to repay

I defined five actors and worked within engineering constraints

I came up to speed with OatFi's process—including edge cases of manual application reviews—through multiple discussions with product managers on both sides. From those conversations, I defined five actors: a buyer, a seller, an OatFi employee, the Inxeption platform code, and the OatFi API.

The Inxeption Chief Architect advised us to reuse backend code that powered the UI, displaying fields as read-only with OatFi data to save time.

My process flow diagram aligned teams and uncovered discrepancies

With clarity on actors, processes, and architecture, I documented the flow with input from PM and engineers to align the team. Structuring the flow into Setup, Shopping, and Fulfillment/Collections phases streamlined discussions.

Thanks to the visibility that this diagram provided, we uncovered and collaboratively resolved misaligned expectations before they became big problems (annotated in diagram above).

Moment of invoice purchase: Inxeption preferred the partner to purchase the buyer's invoice at order completion, but the partner preferred to wait until the seller marked it ready to ship to avoid cancellations or inventory issues. We adjusted our flow and UI to accommodate this preference.
Correct available credit amount: Buyers needed to see their available credit at checkout, but delays in our partner’s updates could have overstated their balance, risking overspending. Our partner ultimately provided a more accurate variable for available credit.
Ownership of notifications: To ensure successful collections, buyers needed reminders for due dates and late payments. Although the contract made our partner responsible, they asked us to send notifications, citing a lack of automation. We pushed back, and they agreed to handle notifications, initially sending emails manually until their system was ready.

Two more challenges arose during design

Since we were enhancing existing functionality, I jumped from the flow diagram to a clickable prototype, where I addressed additional conflicts.

Late changes for the legal department, and company layoffs

Problems:

Late legal changes required buyers to agree to two terms and conditions links at checkout, one for a general disclaimer and one for payment terms. I was worried that users would not discover the two checkboxes required to enable the “Place Order” button, especially in a scrolling div (see following screen).
I couldn’t consult our lawyer until after layoffs, which also cost us our product manager, at which point I took the lead while onboarding our PM's replacement.

Solution: Restarting the conversation frustrated our lawyer, but in empathizing with him and prioritizing an iterative approach, I agreed to two checkboxes linking to the terms pages.

Comment: Implementation would be longer to dynamically combine the two checkboxes into one if payment terms were applied. Time was of the essence, so I opted for faster implementation, knowing we could monitor for issues and add workarounds, like a tooltip while hovering over the “Place Order” button.

Discrepancy in late fee percentange

Problem: While mocking up the new payment terms page, I noticed a discrepancy in the late fee percentage between the written terms and a recent discussion.

Solution: I arranged a sync call with Legal and our partner’s Chief Risk Officer, where they clarified the numbers and caught earlier missed copy changes, including APR vs. APY.

Comment: While catching a couple typos may seem insignificant, these fee differences are crucial to a financing agreement. They could translate to thousands of dollars and headaches due to refunds, and were caught through my attention to detail.

Enabling flexibility in our design

To replace Inxeption's hard-coded invoice factoring, we updated all payment terms pages to dynamically display third-party factoring information. Leveraging my product knowledge, I defined edits for 40+ screens or page states, enabling swift implementation by engineering.

Below are a few examples.

Backend approval or rejection

The backend screen for Inxeption underwriters to review applicants was changed to read-only and supplemented with third-party fields. This allowed data to flow in seamlessly, giving our team the necessary information without building new screens.

Request for offer

We removed the reference to Inxeption from the "Requested Payment Method" field of the buyer-facing request page.

Order details

While the look and feel didn't change, we updated every field in the "Payment Details" and "Status" sections, some fields in the "Payment History" section, and the text at the bottom, explaining exactly when, who, and how much to repay.

I defined this copy to be as templatizable as possible, since the code for this deceptively simple page was complicated under the covers—an example of my partnership with Engineering.

Reflection

Despite challenges—late legal feedback, layoffs, and two other simultaneous high-priority design projects—we fully completed the integration and built a flexible framework to slot in any provider.

This outcome was driven by my leadership and design contributions, including:

A process flow diagram that aligned stakeholders
Mockups that accelerated requirement discussions
Attention to detail to uncover discrepancies
Proactive internal and external tracking and communication with both sides

Unfortunately, due to a late-stage Finance conflict between Inxeption and OatFi that arose right when code was completed, 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 while reducing risk.

Back to Portfolio

Page updated

Google Sites

Report abuse