Merchant Embedded Lending / Cash Advance

Offer working-capital cash advances and small loans to befday merchants inside the POS, repaid as a share of daily sales, using transaction history as the underwriting + repayment rail. befday is the embedded distribution + data layer, never the lender — a licensed lender or fintech enabler holds the capital and the credit license. Phase-3 monetization, after embedded insurance.

Status: Proposed (direction); implementation deferred to phase 3 (after embedded insurance)
Date: June 2026
Decision: Offer working-capital cash advances / small loans to befday merchants inside pos and the merchant dashboard, underwritten from each shop’s transaction history and ideally repaid as a percentage of daily sales flowing through the POS. befday is the embedded distribution + data layer — surfacing pre-qualified offers and (optionally) routing repayment from settlement — while a licensed lender / fintech enabler holds the capital, the credit license, and the collections/default risk. befday is never the lender. Reuses the same data asset and partner-don’t-build model as Decision 12.

TL;DR

The same POS transaction history that makes a merchant insurable makes them creditworthy — more directly, since lending cares about exactly what the POS sees. befday pre-qualifies merchants, surfaces offers, and (where it sits in settlement) routes repayment as a % of daily sales so repayment flexes with cash flow. A licensed lender holds capital, license, and default risk; befday never lends. Phase 3 — after embedded insurance proves the partner playbook.

Context

The same POS transaction history that makes a merchant insurable makes them creditworthy — arguably more directly, since lending cares about exactly what the POS sees:

Revenue history & trend — can they service a repayment?
Daily sales consistency — is cash flow stable enough for sales-linked repayment?
Time in business / tenure on befday — track record.
Seasonality — size the advance and repayment % sensibly.

Small and informal merchants are chronically underserved by traditional lending: no audited financials, no collateral, thin or no credit file. They resort to slow banks or predatory informal lenders. A POS that already watches real cash flow can pre-qualify them where a bank cannot — and offer the cleanest repayment in small-merchant finance: a slice of each day’s sales, flexing with how the business is doing.

This is the model Square Capital, Shopify Capital, and Stripe Capital built — one of the highest-margin, highest-stickiness layers a POS can add. Sequenced after insurance: insurance is lower-risk and capital-light, a gentler first fintech step; lending adds credit risk and capital, so it should ride on proven density, data, and partner muscle.

Same data asset as spend insights and insurance; here pointed at credit underwriting + sales-linked repayment.

Decision

befday is the distribution + data + repayment rail, not the lender

Same constraint as insurance: lending/credit is licensed and capital-intensive, regulated in Malaysia (moneylending / credit activity, with BNM-adjacent and Ministry oversight depending on structure). befday must not lend its own capital or hold the credit license. befday’s job:

Pre-qualify merchants from POS data (with consent) and surface an offer.
Pre-fill the application so onboarding is near-zero-effort.
Optionally route repayment as a percentage of daily POS settlement to the lender.
Hand off underwriting, capital, disbursement, collections, and default to the licensed partner.
Earn an origination/referral fee or revenue-share, and gain deep retention.

The sales-linked repayment mechanism (the special part)

The POS makes befday’s version better than a generic loan: repayment is collected as a fixed % of daily sales processed through pos.

Slow day → smaller repayment; busy day → larger. Repayment flexes with cash flow — what small merchants need, and what reduces default.
It’s automatic — no invoices, no missed-payment friction — because the money already flows through POS settlement.
Nuance: this only works cleanly if befday/pos sits in the settlement/payment flow. If settlement is fully external, the lender/payment partner routes repayment and befday’s role narrows to origination + data. (Open question below.)

Collaboration is mandatory — same three tiers as insurance

Mirrors Decision 12:

Tier	What befday does	Who’s licensed / holds capital	Load on befday	Verdict
1. Pure referrer	Show an offer, hand off (with consent)	Lender only	Lightest	Fallback
2. Embedded distribution (+ repayment rail)	Pre-qualified offer inside befday, pre-filled, sales-linked repayment routed	Lender (often via fintech enabler)	Medium	Chosen
3. befday lends its own capital	Holds capital, credit license, default risk	befday itself	Heaviest	Hard no

Tier 3 is a firmer “no” than in insurance: holding capital and credit/default risk is a fundamentally different and dangerous business befday should not enter.

Chosen: embedded distribution + repayment rail (Tier 2), via a fintech enabler

Same route as insurance: partner with a lending/fintech enabler that brings licensed-lender relationships, capital, and compliance via API. befday brings merchants, the underwriting data, and (where it sits in settlement) the repayment rail. Work collapses to integration + commercial deal; credit risk stays with the partner.

Product fit (rough priority)

Merchant cash advance — lump sum now, repaid as a % of future sales (best fit; flexes with cash flow).
Short-term working-capital loan — fixed term/amount for inventory or equipment.
Shariah-compliant financing — an Islamic-finance variant (e.g. murabahah/commodity-based) as the local differentiator, mirroring takaful in insurance.
Bill / inventory financing — later, narrower use cases.

Why this fits befday specifically

Generic lender’s problem	befday’s version	Result
Can’t assess informal merchants (no credit file)	POS is the cash-flow record	Newly creditworthy
Repayment/collections friction on small loans	Repaid automatically as a % of daily POS sales	Lower default, no chasing
Distribution to micro-merchants is uneconomic	Pre-qualified offer inside a tool they use daily	Near-zero acquisition
Rigid repayment crushes seasonal businesses	Repayment flexes with daily sales	Merchant-friendly
Generic financing ignores Shariah preference	Islamic-finance variant surfaced where relevant	Differentiated locally

It also creates the deepest POS moat of all: a merchant with an active sales-linked advance running through befday’s POS is structurally locked in for the life of the advance.

Sequencing — phase 3, after insurance

Prerequisites are stricter than insurance because credit risk is involved:

Merchant density — enough shops to interest a lending partner.
Deep transaction history — enough sales data per shop for credible credit underwriting (more than insurance needs).
Proven partner muscle — ideally embedded insurance already shipped, so befday has run the consent/compliance/handoff playbook once on a lower-risk product.
Settlement position (for repayment rail) — clarity on whether pos sits in the money flow.

Merchant density + deep sales history
   →  embedded insurance shipped (partner muscle proven)
      →  embedded cash advance (Tier 2 via fintech enabler)
         →  sales-linked repayment via POS settlement (if befday sits in the flow)

Data Model Impact (sketch)

Like insurance, mostly a read + consent + funnel + reference layer, with one addition if befday routes repayment.

Table / column	Notes
`shops.lending_consent`	boolean + timestamp — explicit opt-in to share POS data for credit assessment
`shops.lending_status`	enum `none\|offered\|applied\|active\|repaying\|closed\|declined` — befday-side funnel state
(derived) credit snapshot	revenue, trend, consistency, tenure, seasonality — computed from existing orders, not new tables
`lending_offers` / `lending_referrals`	new — `(shop_id, partner, offered_at, amount, status, external_ref)` for funnel + commission
`lending_repayment_events`	optional — only if befday routes repayment: `(shop_id, advance_ref, amount, collected_at)` reconciliation
partner advance / collections data	Not in befday’s DB — owned by the lender; befday stores at most an opaque reference

befday persists consent + funnel state + external reference (+ repayment reconciliation only if it sits in settlement); never the loan book, balances, or collections data.
Credit snapshot is a derived view over orders, reusing the spend insights / insurance aggregation.

API Impact (sketch)

Procedure	Status	Notes
`merchant.lending.eligibility`	New	Computes the derived credit snapshot + whether the shop pre-qualifies + indicative amount
`merchant.lending.consent`	New	Records explicit opt-in to share POS data with the lending partner
`merchant.lending.offer`	New	Returns the partner’s pre-qualified offer (via partner API); records funnel state
`merchant.lending.handoff`	New	Hands the merchant to the partner application; stores `external_ref`
`merchant.lending.repaymentRate`	New	(If repayment routed) current % of sales + balance status, read from partner
partner webhooks	New	Lender reports `active/repaying/closed/declined` + repayment confirmations

Underwriting, capital, disbursement, and collections all happen on the partner side. befday integrates via the enabler’s API and tracks the funnel + reference (+ repayment reconciliation only if in the settlement flow).

Consequences

Type	Consequence
Pro	Highest-margin, highest-stickiness fintech layer a POS can add, on data befday already has.
Pro	Deepest retention — an active advance running through befday’s POS locks the merchant in for the advance’s life.
Pro	Real social value — credit for chronically underserved informal/SME merchants, with merchant-friendly sales-linked repayment.
Pro	Islamic-finance variant is a local differentiator, mirroring takaful.
Pro	Reuses the same data asset + partner playbook as insurance — incremental, not net-new capability.
Con	Credit + capital risk make Tier 3 a hard no and raise the bar on partner quality vs. insurance.
Con	Regulatory — moneylending/credit activity is sensitive; befday must stay strictly on distribution/data/repayment-rail, never lending or advising. Higher stakes than insurance.
Con	Repayment rail depends on settlement position — if befday isn’t in the money flow, the best mechanism (sales-linked auto-repayment) isn’t befday’s to offer; role narrows to origination.
Con	Brand/trust risk — defaults, aggressive collections by a bad partner, or a merchant feeling trapped reflect on befday. Partner collections conduct must be vetted.
Con	Premature-build trap (stronger) — needs density, deep history, and ideally insurance shipped first. Explicitly phase 3.

Choosing a lending / fintech partner

Mirrors the insurance partner criteria, with credit-specific additions. Goal: a partner that brings capital + a credit license + compliance + an API, so befday contributes merchants, data, and (optionally) the repayment rail. No vendor is endorsed here.

Must-haves (hard filters)

Licensed to lend in Malaysia (or properly intermediated), keeping befday on the distribution/data/repayment-rail side — never lending or advising. In writing from their compliance team.
Holds the capital and the default risk. befday must not be on the hook for losses.
Sales-linked / revenue-based repayment capability (the whole point) — or a credible path to it.
Real API for eligibility → pre-qualified offer → handoff → repayment/status webhooks.
Owns collections and default end-to-end, with conduct standards befday is comfortable having near its brand.

Strong signals

Consumes befday’s POS credit snapshot for underwriting (uses our main asset).
SME / micro-merchant / informal-sector lending track record.
Sane economics — transparent origination/rev-share, no exclusivity or large minimums pre-pilot.
Settlement integration — can collect repayment from POS settlement cleanly (if befday sits in the flow).
Shariah-compliant financing option.
Responsible-lending posture — affordability checks, no debt-trap structures (protects merchants and befday’s brand).

Red flags

Wants befday to co-fund, guarantee, or share default risk.
Aggressive/opaque collections practices.
Exclusivity or minimums before a pilot.
Pressure to over-collect merchant data beyond underwriting need.
No sales-linked repayment, no SME experience, no real API.

Diligence scorecard (fill during evaluation)

Criterion	Weight	Partner A	Partner B	Partner C
Licensed to lend / keeps befday distribution-only	Gate
Holds capital + default risk (befday off-risk)	Gate
Sales-linked / revenue-based repayment	High
API: eligibility / offer / handoff / webhooks	High
Consumes POS credit snapshot	High
Responsible-lending / collections conduct	High
SME / informal-merchant lending track record	Medium
Commercials (no lock-in)	Medium
Settlement integration for repayment	Medium
Shariah-compliant financing	Medium
Time-to-pilot	Low

Recommended approach

Reuse the insurance partner muscle — same consent/compliance/handoff playbook; ideally evaluate lending after insurance is live.
Panel bake-off, pilot, no exclusivity — 2–3 enablers against the scorecard; thin integration (eligibility + offer + handoff + status webhook) on a limited cohort before any settlement/repayment-rail work.
Make responsible-lending + compliance sign-off a launch gate.

Open Questions

Settlement position: does pos sit in the payment/settlement flow enough to route sales-linked repayment, or is befday limited to origination + data? (Decides whether the best mechanism is even available.)
Sequencing vs. insurance: strictly after insurance ships, or can a lending pilot run in parallel once data is deep enough?
Risk posture: absolutely zero befday capital/guarantee (assumed), or is there ever a case for a small first-loss arrangement to unlock better merchant rates? (Default: zero.)
Repayment %: who sets it and how is it bounded so it never starves a merchant’s cash flow?
Consent reuse: can the insurance data-consent be extended to lending, or must lending have its own explicit opt-in? (Likely separate — credit is more sensitive.)
Revenue model: origination fee vs. revenue-share, and is any rebated to merchants to drive adoption?
Brand exposure: how co-branded, given collections/default can sour the relationship?
Eligibility threshold: minimum tenure / sales volume before a shop is offer-eligible, so the credit snapshot is meaningful?