Available for New Projects
SaaSPay — Designing BNPL Infrastructure for SaaS from Zero 🚀
SaaSPay — Designing BNPL Infrastructure for SaaS from Zero 🚀
SaaSPay — Designing BNPL Infrastructure for SaaS from Zero 🚀
When I joined SaaSPay, the product existed as a business logic on a whiteboard and an engineering team that had already started building. There was no design, no design system, no component library, no research and no other designer. My first week was mostly me trying to understand what BNPL in a B2B SaaS context even meant before I could design anything for it.
When I joined SaaSPay, the product existed as a business logic on a whiteboard and an engineering team that had already started building. There was no design, no design system, no component library, no research and no other designer. My first week was mostly me trying to understand what BNPL in a B2B SaaS context even meant before I could design anything for it.
When I joined SaaSPay, the product existed as a business logic on a whiteboard and an engineering team that had already started building. There was no design, no design system, no component library, no research and no other designer. My first week was mostly me trying to understand what BNPL in a B2B SaaS context even meant before I could design anything for it.
Role & Team
Role:
Product & UX Designer
Scope:
Full product design — UX, UI, design system, IA — across all three portals
Team:
Engineering-led founding team. I was the only designer
Timeline:
2 years
Context block
SaaSPay is buy-now-pay-later infrastructure for SaaS subscriptions. The idea: a business wants Figma or Notion for their team, but budget approvals take months and trial periods end in weeks. SaaSPay sits in the middle, the vendor gets paid upfront, the buyer pays over 8, 10, or 12 months, and an NBFC lender takes on the credit risk.
SaaSPay is buy-now-pay-later infrastructure for SaaS subscriptions. The idea: a business wants Figma or Notion for their team, but budget approvals take months and trial periods end in weeks. SaaSPay sits in the middle, the vendor gets paid upfront, the buyer pays over 8, 10, or 12 months, and an NBFC lender takes on the credit risk.
SaaSPay is buy-now-pay-later infrastructure for SaaS subscriptions. The idea: a business wants Figma or Notion for their team, but budget approvals take months and trial periods end in weeks. SaaSPay sits in the middle, the vendor gets paid upfront, the buyer pays over 8, 10, or 12 months, and an NBFC lender takes on the credit risk.
The product I had to design wasn't one product. It was three: a seller portal for SaaS vendors to offer BNPL at checkout, a buyer portal for businesses to manage repayment, and an admin portal for the internal ops team and NBFC partners to handle underwriting and disbursals. All three had to be designed simultaneously, by one person, from scratch.
The product I had to design wasn't one product. It was three: a seller portal for SaaS vendors to offer BNPL at checkout, a buyer portal for businesses to manage repayment, and an admin portal for the internal ops team and NBFC partners to handle underwriting and disbursals. All three had to be designed simultaneously, by one person, from scratch.
The product I had to design wasn't one product. It was three: a seller portal for SaaS vendors to offer BNPL at checkout, a buyer portal for businesses to manage repayment, and an admin portal for the internal ops team and NBFC partners to handle underwriting and disbursals. All three had to be designed simultaneously, by one person, from scratch.
Problem
BNPL for SaaS was new enough that the people I was designing for hadn't done this before. Finance heads and procurement managers at mid-sized companies were skeptical, not because the concept was bad, but because they'd been burned by financial products that buried the important information.
BNPL for SaaS was new enough that the people I was designing for hadn't done this before. Finance heads and procurement managers at mid-sized companies were skeptical, not because the concept was bad, but because they'd been burned by financial products that buried the important information.
BNPL for SaaS was new enough that the people I was designing for hadn't done this before. Finance heads and procurement managers at mid-sized companies were skeptical, not because the concept was bad, but because they'd been burned by financial products that buried the important information.
Hidden fees. EMI amounts that didn't match what they'd been quoted. Debit dates that appeared in their bank statement before they'd ever confirmed them. The distrust wasn't about the product. It was about every financial product they'd signed up for before this one.
Hidden fees. EMI amounts that didn't match what they'd been quoted. Debit dates that appeared in their bank statement before they'd ever confirmed them. The distrust wasn't about the product. It was about every financial product they'd signed up for before this one.
Hidden fees. EMI amounts that didn't match what they'd been quoted. Debit dates that appeared in their bank statement before they'd ever confirmed them. The distrust wasn't about the product. It was about every financial product they'd signed up for before this one.
On the seller side, the problem was different. SaaS vendors wanted to offer BNPL to close deals they were losing to budget cycles, but they didn't want to understand credit risk, lender relationships, or reconciliation logic. They wanted a clean integration that looked reliable and required zero operational involvement from them.
On the seller side, the problem was different. SaaS vendors wanted to offer BNPL to close deals they were losing to budget cycles, but they didn't want to understand credit risk, lender relationships, or reconciliation logic. They wanted a clean integration that looked reliable and required zero operational involvement from them.
On the seller side, the problem was different. SaaS vendors wanted to offer BNPL to close deals they were losing to budget cycles, but they didn't want to understand credit risk, lender relationships, or reconciliation logic. They wanted a clean integration that looked reliable and required zero operational involvement from them.
The admin portal existed because none of this could work without humans in the loop — underwriters reviewing applications, ops teams approving disbursals, fraud teams flagging risk. They needed workflows, not dashboards.
The admin portal existed because none of this could work without humans in the loop — underwriters reviewing applications, ops teams approving disbursals, fraud teams flagging risk. They needed workflows, not dashboards.
The admin portal existed because none of this could work without humans in the loop — underwriters reviewing applications, ops teams approving disbursals, fraud teams flagging risk. They needed workflows, not dashboards.
Approach
I built the seller portal first. Not because it was easiest, it wasn't, but because the buyer portal couldn't be tested with real payment plans unless vendors had created them. Sequence mattered.
I built the seller portal first. Not because it was easiest, it wasn't, but because the buyer portal couldn't be tested with real payment plans unless vendors had created them. Sequence mattered.
I built the seller portal first. Not because it was easiest, it wasn't, but because the buyer portal couldn't be tested with real payment plans unless vendors had created them. Sequence mattered.
For the seller onboarding, I mapped every decision a vendor needed to make before going live: what payment tenures to offer (8, 10, 12 months), what credit limits to set, how to handle partial checkouts, what the buyer-facing checkout would look like. I designed this as a step-by-step setup flow, not a settings page. The goal was to get a vendor from signup to live checkout integration in one session without needing to talk to anyone at SaaSPay.
For the seller onboarding, I mapped every decision a vendor needed to make before going live: what payment tenures to offer (8, 10, 12 months), what credit limits to set, how to handle partial checkouts, what the buyer-facing checkout would look like. I designed this as a step-by-step setup flow, not a settings page. The goal was to get a vendor from signup to live checkout integration in one session without needing to talk to anyone at SaaSPay.
For the seller onboarding, I mapped every decision a vendor needed to make before going live: what payment tenures to offer (8, 10, 12 months), what credit limits to set, how to handle partial checkouts, what the buyer-facing checkout would look like. I designed this as a step-by-step setup flow, not a settings page. The goal was to get a vendor from signup to live checkout integration in one session without needing to talk to anyone at SaaSPay.
The buyer portal was where the trust problem lived. I started by looking at what existing BNPL products got wrong, and the pattern was consistent: they made commitment easy and obligation unclear. Confirmation screens that showed monthly amount but not total. Schedules that required downloading a PDF to read. Auto-debit that was buried under three layers of settings.
The buyer portal was where the trust problem lived. I started by looking at what existing BNPL products got wrong, and the pattern was consistent: they made commitment easy and obligation unclear. Confirmation screens that showed monthly amount but not total. Schedules that required downloading a PDF to read. Auto-debit that was buried under three layers of settings.
The buyer portal was where the trust problem lived. I started by looking at what existing BNPL products got wrong, and the pattern was consistent: they made commitment easy and obligation unclear. Confirmation screens that showed monthly amount but not total. Schedules that required downloading a PDF to read. Auto-debit that was buried under three layers of settings.
I designed the buyer portal around a single principle: the full obligation has to be visible before the buyer confirms anything. Every instalment, every date, every fee, all on one screen at the moment of commitment.
I designed the buyer portal around a single principle: the full obligation has to be visible before the buyer confirms anything. Every instalment, every date, every fee, all on one screen at the moment of commitment.
I designed the buyer portal around a single principle: the full obligation has to be visible before the buyer confirms anything. Every instalment, every date, every fee, all on one screen at the moment of commitment.
Challenges and trade-offs
The hardest decision was what happens when a SaaS subscription renews mid-repayment plan.
The hardest decision was what happens when a SaaS subscription renews mid-repayment plan.
The hardest decision was what happens when a SaaS subscription renews mid-repayment plan.
A buyer on a 10-month plan for Figma at month 7: Figma renews their subscription. Do they get a new BNPL plan? Does the existing plan extend? Does the monthly amount change?
A buyer on a 10-month plan for Figma at month 7: Figma renews their subscription. Do they get a new BNPL plan? Does the existing plan extend? Does the monthly amount change?
A buyer on a 10-month plan for Figma at month 7: Figma renews their subscription. Do they get a new BNPL plan? Does the existing plan extend? Does the monthly amount change?
My first design created a new plan alongside the existing one. The buyer portal showed two active plans with two separate timelines and two monthly amounts. I user-tested it. Nobody understood what they owed. Multiple people thought they were being double-charged.
My first design created a new plan alongside the existing one. The buyer portal showed two active plans with two separate timelines and two monthly amounts. I user-tested it. Nobody understood what they owed. Multiple people thought they were being double-charged.
My first design created a new plan alongside the existing one. The buyer portal showed two active plans with two separate timelines and two monthly amounts. I user-tested it. Nobody understood what they owed. Multiple people thought they were being double-charged.
I scrapped it. The second version showed a single monthly obligation number, combining all active plans, with a breakdown available one tap away. The complexity was real, but the buyer didn't need to feel it. They needed to know one thing: what's leaving my account this month?
I scrapped it. The second version showed a single monthly obligation number, combining all active plans, with a breakdown available one tap away. The complexity was real, but the buyer didn't need to feel it. They needed to know one thing: what's leaving my account this month?
I scrapped it. The second version showed a single monthly obligation number, combining all active plans, with a breakdown available one tap away. The complexity was real, but the buyer didn't need to feel it. They needed to know one thing: what's leaving my account this month?
Solution
The seller dashboard gave vendors a real-time view of pending disbursals, active buyer plans, invoice logs, and reconciliation status — all without exposing any of the credit logic that happened between them and the NBFC. They could see what they were owed and when. That was enough.
The seller dashboard gave vendors a real-time view of pending disbursals, active buyer plans, invoice logs, and reconciliation status — all without exposing any of the credit logic that happened between them and the NBFC. They could see what they were owed and when. That was enough.
The seller dashboard gave vendors a real-time view of pending disbursals, active buyer plans, invoice logs, and reconciliation status — all without exposing any of the credit logic that happened between them and the NBFC. They could see what they were owed and when. That was enough.
The buyer dashboard led with the repayment calendar and the upcoming debit amount. Auto-debit could be paused, rescheduled, or cancelled from the same screen — not buried in settings. Contextual nudges appeared at the right moments: an upcoming due date reminder 5 days before, an early repayment discount when a buyer had sufficient credit, a credit limit increase prompt when repayment history was strong.
The buyer dashboard led with the repayment calendar and the upcoming debit amount. Auto-debit could be paused, rescheduled, or cancelled from the same screen — not buried in settings. Contextual nudges appeared at the right moments: an upcoming due date reminder 5 days before, an early repayment discount when a buyer had sufficient credit, a credit limit increase prompt when repayment history was strong.
The buyer dashboard led with the repayment calendar and the upcoming debit amount. Auto-debit could be paused, rescheduled, or cancelled from the same screen — not buried in settings. Contextual nudges appeared at the right moments: an upcoming due date reminder 5 days before, an early repayment discount when a buyer had sufficient credit, a credit limit increase prompt when repayment history was strong.
The nudge design was deliberate. The <3% default rate in the first six months wasn't just about underwriting — it was about never letting a buyer get surprised by a debit they'd forgotten was coming.
The nudge design was deliberate. The <3% default rate in the first six months wasn't just about underwriting — it was about never letting a buyer get surprised by a debit they'd forgotten was coming.
The nudge design was deliberate. The <3% default rate in the first six months wasn't just about underwriting — it was about never letting a buyer get surprised by a debit they'd forgotten was coming.
The admin portal was the least visible and the most complex. Underwriting queues where ops could review applications with credit data surfaced from the NBFC. Fraud flags with severity levels and recommended actions. Role-based access so that an underwriter saw underwriting views and a disbursal approver saw disbursal views — not each other's work. Audit logs for compliance. I designed every workflow around task completion: what does this person need to finish their job today?
The admin portal was the least visible and the most complex. Underwriting queues where ops could review applications with credit data surfaced from the NBFC. Fraud flags with severity levels and recommended actions. Role-based access so that an underwriter saw underwriting views and a disbursal approver saw disbursal views — not each other's work. Audit logs for compliance. I designed every workflow around task completion: what does this person need to finish their job today?
The admin portal was the least visible and the most complex. Underwriting queues where ops could review applications with credit data surfaced from the NBFC. Fraud flags with severity levels and recommended actions. Role-based access so that an underwriter saw underwriting views and a disbursal approver saw disbursal views — not each other's work. Audit logs for compliance. I designed every workflow around task completion: what does this person need to finish their job today?
Results & Impact
The first MVP shipped and went live with a pilot SaaS seller. Default rate in the first six months was under 3% — the nudge system and transparent repayment experience contributed directly to that number.
The first MVP shipped and went live with a pilot SaaS seller. Default rate in the first six months was under 3% — the nudge system and transparent repayment experience contributed directly to that number.
The design system I built was the first design infrastructure SaaSPay had. The next designer who joined didn't start from scratch — they extended what was already there.
The design system I built was the first design infrastructure SaaSPay had. The next designer who joined didn't start from scratch — they extended what was already there.
I don't have conversion metrics tied specifically to design decisions, and SaaSPay's broader fintech traction is tied to factors well outside the product experience. What I can say: a product that had no designed interface when I joined had three working portals, a consistent visual language, and a default rate that held through the pilot.
I don't have conversion metrics tied specifically to design decisions, and SaaSPay's broader fintech traction is tied to factors well outside the product experience. What I can say: a product that had no designed interface when I joined had three working portals, a consistent visual language, and a default rate that held through the pilot.
