Which financial product your software company should launch first
Wallet, card, checkout, or passthrough capital — your first financial product is determined by how deep your customer relationship is and who controls the payment data today.
The default answer in most rooms is credit. It has the highest take rate, the cleanest deck story, and the prettiest unit economics on a whiteboard. It is also one of the most common ways embedded finance launches die before the second board meeting.
I'm writing this for software-first operators with a product surface. You have users who have a particular behavior or habit. You're starting to wonder if a financial product should be the second revenue line.
Credit, again, is the wrong place to start. It needs three things to work: transaction data to underwrite against, a balance sheet to fund from, and enough engagement to collect on time. Most software teams considering the move have one of the three, sometimes two. They build the loan book anyway. Six months later, adoption is thin and losses are not. The product was fine. The company never had the data, the float, or the engagement to carry it.
This piece is about the product you ship before that one.
Ship financial products without becoming a fintech.
Most teams don't skip wallets, payouts, or disbursements because they got the strategy wrong. They skip them because becoming a regulated money services business in the Philippines is a two-year detour with a balance sheet attached.
PayMongo runs those rails — wallets, payouts, disbursements, InstaPay, PESONet, QR Ph — under one API and one ledger.
You ship the product. We hold the licences.
The four products
A wallet sits inside your product as a stored balance, used to settle transactions your users already make there. Hosted checkout or payment links are one-time URLs that collect money from outside your product, on rails you operate. A co-branded or issued card is plastic, physical or virtual, running on a partner bank's rails and capturing spend you'd otherwise never see. Passthrough credit is BNPL or working capital originated by a licensed partner and surfaced inside your flow.
You don't pick by which is best. You pick by what your surface can carry. Two questions do the work.
How deep is the customer relationship? Daily or weekly use is deep. Monthly or less is shallow. A Shopify merchant logs in most working days. A Klook customer shows up when they're booking a trip. One is habit, one is an errand.
Who owns the payment data? Either money moves on rails you control — your checkout, your wallet, your POS — or it clears somewhere else and you watch from upstream. Shopify owns Shop Pay. Rippling watches spend on cards issued by partner banks.
Everything else — take rate, licensing, regulatory drag, partner economics — matters once a product is working. It does not decide whether the product can work in the first place. In month one you're trying to get anyone to use the thing. The other questions are a year out.
Put the two answers on a 2×2. The quadrant points at the product.
The pattern in the wild
Every software-first company that successfully added financial services walked this grid, whether they named the framework or not.
| Company | Quadrant | First financial product | Why it's useful |
|---|---|---|---|
| Shopify | Deep + own rails | Wallet (Shopify Balance) | E-commerce SaaS founded 2006. Shop Pay launched 2017. Shopify Balance launched 2020. Shopify Capital underwrites against the data the wallet and checkout produced. Clean substrate chain: software → checkout → wallet → capital. |
| Shopee → ShopeePay | Deep + own rails | Wallet | E-commerce platform launched 2015. ShopeePay launched 2018 once GMV and daily engagement were established. SEA proof that wallets get added once the platform is already deep + own rails. |
| Grab → GrabPay | Deep + own rails | Wallet | Ride-hailing software since 2012. GrabPay launched 2016 across ASEAN-6 once daily usage was at scale. The wallet was a strategic layer, not the founding bet. |
| Rippling | Deep + partner rails | Co-branded / issued card | HR and IT SaaS since 2016. Rippling Spend launched after the daily workflow was sticky enough to make policies and approvals matter. Spend control attached to an existing workflow. |
| Sleek | Deep + partner rails | Co-branded / issued card | Singapore corporate-services SaaS — incorporation, accounting, compliance — added Sleek Cards on partner-bank rails once the workflow was established. SEA confirmation that workflow stickiness precedes the card. |
| Klook | Shallow + own rails | Hosted checkout | Bookings software with multi-method checkout on its own rails. Trip-driven engagement, not daily. |
| Eventbrite | Shallow + own rails | Hosted checkout | Event-ticketing SaaS with own-rails checkout since launch. Episodic ticketing surface. |
| PropertyGuru / Lamudi | Shallow + partner rails | Passthrough credit | Property classifieds where users come once or twice a year, the transaction closes elsewhere, and any credit offer is partner-originated. Demand surface, no rails. |
| Zillow Home Loans | Shallow + partner rails | Passthrough credit | Property classifieds that built a mortgage referral and origination business via licensed partners. |
Shopify started as e-commerce SaaS in 2006. Shop Pay landed in 2017, Shopify Balance in 2020, Shopify Capital on top of both. Each layer used the data and float the previous one had generated. Shopee followed the same shape in Southeast Asia — GMV first from 2015, then ShopeePay in 2018. Grab too. Rides became a daily reflex across ASEAN-6, and GrabPay arrived only once that habit was in place. Nobody at Grab was betting they could create the habit with a wallet.
Rippling sells HR and IT software. Rippling Spend came later, on partner-bank rails, after the daily workflow around employees and IT had locked in. Sleek did the same for corporate services in Singapore — Sleek Cards arrived once incorporation, accounting, and compliance workflows were sticky. You earn the card with the workflow.
Klook and Eventbrite sit in the shallow + own-rails quadrant. Users show up when they're booking a trip or hosting an event. Both run checkout on their own rails. Hosted payments are the natural first product because they already sit under the payment moment.
PropertyGuru, Lamudi, 99.co, Zillow — classifieds. Users visit rarely. Transactions close with banks and brokers. Mortgage or BNPL has to be partner-originated. The right move is passthrough credit and referral economics. Trying to be a bank from a classifieds page has never worked anywhere.
Top-right: ship a wallet
Here you see your users often, and the money already moves on your ledger.
Shopify is the cleanest case. Merchants live in the dashboard. Shop Pay standardized checkout on Shopify's rails. Balance turned the flow into a stored account experience. Capital used the data and float those surfaces generated. Shopee and Grab pulled the same move in Southeast Asia — win daily usage, then add the wallet.
A wallet in this quadrant doesn't ask for anything new. Users already complete transactions inside your product. Switching to a stored balance is one extra tap, then no taps at all. Money lands in the wallet. The next payment draws from it. The flow on screen barely changes — what changes is where value sits between transactions.
The math: capture 20–40% of GMV in year one into the wallet. At 30% capture on ₱100M monthly GMV and a 1% take rate, the wallet prints around ₱300,000 a month. No license you had to build, no rails you stood up yourself, no core ledger beyond what your partner already runs.
Capital can't work without the wallet underneath it. Shopify Capital underwrites against what Shop Pay and Balance see. Skip that step, jump straight to lending, and you're underwriting on raw logs and third-party data. The book runs blind and starves.
Top-left: ship a card
You own the workflow. You don't own the rails. Your users live in your product every day. Their money doesn't.
Rippling shows how this plays out. HR and IT in one system. Cards, limits, and policies sit on top of that rhythm using a partner bank's licence. Sleek does the same for corporate services. The card is what makes the workflow bite — approvals, limits, and reconciliation only matter when there's actual spend to enforce them against.
You're not asking anyone to switch banks. You're asking them to put your logo on top of the same rails. In return, they get controls enforced where the work actually happens — in your app. The machinery lives in your software. The card is the limb that touches the outside world.
Capture sits around 5–15% of customer spend, depending on segment and incentives. Revenue shows up as a slice of interchange. The bigger payoff is visibility — you finally see which vendors your customers pay, how often, and in which categories. That data hardens your workflow now and your underwriting later.
Card programs that ship too early die quietly. If your product opens twice a month, the card has nowhere to live. It rides in someone's wallet for a quarter, then gets buried under whatever bank app they already use. You earn the right to issue plastic by being open every day.
Bottom-right: ship checkout
Users don't live in your product. When they do, they pay on your rails.
Klook and Traveloka are archetypal. Engagement is trip-driven. Eventbrite is the same shape for events. These companies own the checkout moment entirely, not the ongoing relationship. Links and hosted checkout are the only product that fits.
You're not asking for a new habit. Your users already send something to get paid: an invoice, a booking page, a link. You replace that asset with one that clears on your rails. To the payer it looks familiar — card fields, GCash, Maya, bank transfer, maybe a PayLater option. Underneath, you sit on the flow and keep a cut.
The economics are clean. 1.5–3% on every transaction that hits your link or page. You capture 100% of that stream. Volume tracks how often merchants remember you exist and how often their customers complete payment instead of stalling out at the modal.
Avoid building a wallet here. You can spin one up — the question is whether anyone leaves money in it. On a once-a-month travel or events surface, balances decay to zero. Cost and complexity never pay back. Klook isn't Shopify. Episodic products don't get daily-balance behavior for free.
Bottom-left: ship passthrough credit
You rarely see the user. When money moves, it moves elsewhere.
Property classifieds live here: PropertyGuru, Lamudi, 99.co, Zillow. B2B sourcing marketplaces too — directories where discovery is online and settlement happens over email and bank rails you don't touch. Founders in this quadrant keep trying to build lending. It keeps killing them.
You're distribution, not a lender. Plug a licensed partner into your flows. A BNPL provider, a working-capital fintech, or a bank originates the loan, holds the risk, and runs collections. Your job is to put the right offer in front of the right user at a moment that matters.
You keep a slice of funded volume — 2–5% on loans you don't fund or collect. It won't make you a bank. It will give you incremental margin on behavior that was already there.
Don't treat this as the final form. As soon as you deepen engagement or start owning more of the payment data, move up or right — toward a wallet or a card — and stop renting your users' attention to someone else's balance sheet.
Where teams pick wrong
The same mistakes show up in every market.
| Mistake | What breaks |
|---|---|
| Wallet on a shallow surface | A stored balance assumes return frequency that is not there. The wallet sits empty between uses and you write off the licence cost. |
| Card on shallow + partner rails | Plastic against a relationship that does not open weekly. Interchange volume is too thin to cover fixed costs, and the card stops being top-of-wallet within a quarter. |
| Loan before data | Underwriting from third-party signals because the wallet was never built. Defaults run hot. The book either shrinks or eats your margin. |
| Hosted checkout on a deep-frequency surface | Capture left on the table. Users would have moved to a wallet on the next tap; instead they keep paying link fees on transactions that should have been internal balance transfers. |
| Passthrough credit when you already own the data | The partner learns your users faster than you do. You spend the next year trying to in-source what you should have built first. |
| Card before workflow stickiness | A B2B audience that opens your app twice a month for invoicing has no behavioural surface for a card to attach to. |
How to decide
Label your relationship: deep if users are in your product daily or weekly, shallow if not. Label your rails: you-own if funds land on your ledger, partner-own if they clear somewhere else.
Place yourself on the grid. Top-right ships a wallet. Top-left ships a card. Bottom-right ships checkout. Bottom-left ships passthrough credit.
Run the numbers. MAU, GMV, realistic capture rate, realistic take rate. If the line doesn't clear your hurdle, the problem isn't which financial product to build. The problem is engagement or rails.
Launches that work usually feel like nothing new. The behavior was already there — the financial product just makes it visible and capturable. Launches that fail demand a habit your users never had.
Pick the quadrant right and the first product stops being a question.
Ship financial products without becoming a fintech.
Most teams don't skip wallets, payouts, or disbursements because they got the strategy wrong. They skip them because becoming a regulated money services business in the Philippines is a two-year detour with a balance sheet attached.
PayMongo runs those rails — wallets, payouts, disbursements, InstaPay, PESONet, QR Ph — under one API and one ledger.
You ship the product. We hold the licences.
