Affordability-first discovery
Rank financeable products by the amount due today and the user’s available shopping limit.
Primary signalQualified PDP-to-bag conversion
Back to selected work
Affordable Commerce inside super.money
Designing an affordability layer that connects UPI frequency, transparent credit checkout, a narrow product catalogue, and a seller operating system.
- My scope
- Strategy, UX, P&L, systems, APIs, GTM
- Launch frame
- 6 months · controlled India beta
- Primary buyer
- Existing UPI user · ₹5K-₹30K purchase
- Surfaces
- Borrower mobile · seller web · merchant API
One platformBorrower discovery to seller settlement
01 · Brief
The opportunity starts after payments.
super.money already has high-frequency UPI usage, Credit Health, credit access, and a Splitstore entry. The product question is how to turn those assets into a commerce habit without becoming a broad inventory or logistics business.
How could super.money build a repeatable, contribution-positive commerce business by helping eligible users discover what fits their cash flow?
01PaymentsHigh-frequency relationship
02Credit HealthTrust and readiness
03Credit accessEligible plans
04Affordable CommerceUseful purchase and repeat
02 · Scope
Narrow launch. Deep operating model.
The first release targets one purchase job and three low-complexity category groups. Credit is one affordability instrument; eligible customers can still choose full UPI.
Launch contract
- Existing high-frequency UPI users, primarily 21-35
- Practical purchase between ₹5,000 and ₹30,000
- Budget and refurbished smartphones
- Small home appliances
- Work, study, and mobile accessories
- 100-300 governed SKUs in the controlled release
- One primary credit product plus full UPI
Deliberate non-goals
- Broad marketplace category breadth
- Owned inventory, warehouses, or delivery network
- Fashion, travel, furniture, and luxury at launch
- Guaranteed credit approval or score improvement
- Multiple lender optimization before one rail is stable
- Credit as the only checkout method
- Scale based on GMV without full variable costs
Repayment-aware bag and checkout
Show repayment deltas, remaining limit, total payable, lender, KFS, and consent before confirmation.
Primary signalContribution-positive completed-order rate
Merchant Affordability OS
Unify catalogue controls, funded offers, orders, settlements, analytics, and merchant APIs.
Primary signalIncremental merchant-funded orders
03 · Product experience
Every screen resolves a specific product risk.
Switch between the borrower and seller surfaces. Each state shows the problem, decision, and metric it exists to move.
Current decision
Payments remain primary
- Problem
- A commerce entry must earn attention inside a high-frequency UPI home.
- Product decision
- Keep payment actions intact and make Splitstore a focused destination with a visible eligible limit.
- Measure
- Eligible exposure → Splitstore visit
Credit Health
Explain, guide, and correct.
Credit Health remains a standalone borrower capability. Viewing a score never starts an application, and a score never promises eligibility.
Latest available score
Show bureau, model range, retrieval time, and source-file freshness after purpose-specific consent.
Explainable factors
Translate verified reason codes into positive, limiting, and potentially inaccurate factors.
Focused action plan
Prioritize three safe actions with honest time horizons and track corrections through a visible case.
Partner delay state
Preserve the dated saved score, never estimate a replacement, and notify the user after a verified refresh.
04 · Seller model
Affordability needs an operating system.
Sellers need to know which products can be financed, whether an offer creates incremental orders, and exactly how each order, refund, and payout reconciles.
Onboard
KYB, settlement account, catalogue, and webhook readiness
Curate
Financeability state, blocking reasons, inventory, and quality
Fund
Targeted subvention with budget, cohort, SKU, and holdout
Fulfil
Normal merchant order states with a clear exception queue
Reconcile
Fees, offers, refunds, loan adjustments, and payout
Distribute
Splitstore plus signed checkout sessions on merchant sites
Channel 1
Splitstore
super.money owns discovery, PDP, bag, checkout, and the post-purchase timeline.
Channel 2
Merchant checkout
Signed sessions and webhooks bring the same governed plans to the seller’s own product page.
05 · Business model
GMV is an output. Contribution is the gate.
The planning model uses one ₹7,700 order and carries the complete variable-cost stack through every product decision.
| Illustrative line | ₹ / order | % AOV |
|---|---|---|
| Merchant / take revenue | 139 | 1.80% |
| Lender / affordability revenue | 92 | 1.20% |
| Payment / affiliate revenue | 15 | 0.20% |
| Gross variable revenue | 246 | 3.20% |
| Rewards and offer share | -55 | -0.71% |
| Payments, servicing, fraud, refunds | -48 | -0.62% |
| Expected-loss exposure | -65 | -0.84% |
| Infrastructure and communications | -8 | -0.10% |
| Contribution before fixed cost | 70 | 0.91% |
Planning scenario₹100 Cr
annualised GMV
Monthly orders10.8K
from 1.5M targeted eligible exposures
Monthly contribution₹7.6 L
Illustrative planning assumptions, not a company forecast.before fixed costs
North StarMonthly repeat Affordable Commerce buyers
Scale gatePositive cohort contribution after returns, incentives, payments, support, fraud, and expected loss
06 · System design
Know who owns every state and every rupee.
The architecture separates regulated credit decisions, commerce truth, money movement, and user experience while preserving one understandable order state.
Architecture view
Read full technical deep diveThe responsibility boundary
The app owns experience and orchestration. Regulated lenders own credit approval and the loan account. Sellers own catalogue truth and fulfilment.
One system of record per domain
Catalogue owns product truth, the lender owns the loan, payments own transaction truth, and the order bridge owns fulfilment state.
Durable checkout and idempotency
Every confirmation has a stable key, recorded steps, bounded retries, and compensation when a downstream action fails.
Canonical adapters at the boundary
Lender, bureau, payment, and merchant-specific fields stay inside adapters while internal contracts remain stable.
Consent and money are reconstructable
Immutable audit facts, versioned disclosures, ledger-style settlement entries, and reconciliation jobs support investigation.
07 · Launch
Six months, with evidence at every gate.
Month 1
Define the wedge
30 buyer interviews, 15 merchant interviews, category scoring, baseline funnel, economics, and risk boundaries.
Exit evidence: Signed cohort, category, and contribution model.Month 2
Lock the contracts
Tested journeys, disclosures, seller onboarding, APIs, schemas, events, instrumentation, and partner simulators.
Exit evidence: Approved MVP, compliance, and integration contracts.Month 3
Build the decision loop
Catalogue, discovery, eligibility, offers, bag repricing, lender adapter, and payment adapter.
Exit evidence: Financeable catalogue and simulated eligible journeys.Month 4
Build transaction operations
Checkout saga, orders, repayments, refunds, settlements, support timeline, and reconciliation.
Exit evidence: End-to-end order and matched full/partial refunds.Month 5
Controlled alpha
1,000 invited users, three anchor sellers, 100-300 SKUs, one primary credit plan plus full UPI.
Exit evidence: Funnel, risk, and operations within agreed thresholds.Month 6
Feature-flagged beta
Up to 50,000 eligible users, experiment holdouts, daily risk review, and weekly P&L review.
Exit evidence: Positive cohort contribution with repeat and risk signals.Experiments that decide whether to scale
Primary: PDP-to-bag · Guardrail: ineligible impressions
Primary: contribution-positive AOV · Guardrail: 30+ DPD
Primary: contribution-positive orders · Guardrail: loss
Primary: incremental orders · Guardrail: seller ROI
The product thesis