Adding Payments to Your Platform: What It Actually Costs to Build
Someone says it in a roadmap meeting, usually about eighteen months in.
"Why don't we just pay our sellers ourselves?"
Or issue cards. Or hold balances. Or take payments in-house instead of routing everything through someone else's checkout.
It's a good instinct. The economics are real, the product case is usually sound, and adding payments to your platform can be exactly the right call.
They're just estimating the wrong thing.
It always sounds like two sprints
And the reason it sounds like two sprints is that the visible part genuinely is.
Payment APIs are good now. A decent engineer can move test money in an afternoon and have something working by Friday. The prototype is convincing. Everyone in the room sees a demo and reasonably concludes the hard part is done.
It isn't.
The prototype is the lamp.
What you've actually signed up to build is the connection to the grid.
What's actually in the box
Strip away the vocabulary and an embedded payments build comes down to five things that all have to work together.
Somewhere to hold money.
A balance or account that belongs to a specific user, with the infrastructure and controls to keep track of whose money is whose.
A way to take money in.
Payment collection, bank transfers, virtual accounts or other rails that get funds where they need to go — tagged to the right customer without someone matching bank references by hand.
A way to send money out.
Payouts, disbursements and remittance. This is where rails, currencies, cut-off times, limits and compliance start becoming your problem.
A way for people to spend it.
If you want those balances to be useful, that can mean virtual or physical cards. And card issuing brings another layer of scheme, processor and issuer relationships. Visa's own partner guidance describes BIN sponsors, issuer processors and programme managers as distinct parts of the card-programme ecosystem.
A way to know who everyone is.
KYC, KYB, sanctions screening, transaction monitoring and ongoing customer due diligence. FATF's current standards make clear that customer due diligence and risk-based ongoing monitoring aren't one-time onboarding exercises.
None of these is especially difficult on its own.
The difficult part is making all five agree with each other, continuously, reliably and at scale.
That agreement is the actual product.
And it's the part no demo shows you.
The part that never makes it into the estimate
Three costs sit outside the engineering plan entirely.
The licence
If you're providing regulated payment services yourself, you need to understand the regulatory perimeter before you write the first line of code.
In Singapore, the Payment Services Act regulates activities including account issuance, domestic and cross-border money transfer, merchant acquisition and e-money issuance. MAS operates different licensing regimes depending on the activities and applicable thresholds, including the Standard Payment Institution and Major Payment Institution regimes.
The important point isn't the number on the threshold.
It's that licensing is part of the product architecture, not something you bolt on after the product is built.
The partnerships
Cards are the clearest example.
Unless you're directly connected to the card scheme yourself, you may need a sponsoring institution, processor and other programme partners.
That sponsor relationship isn't just an API key. It comes with due diligence, risk controls, compliance responsibilities and commercial constraints.
You are not simply buying access to a card network.
You're entering a financial relationship.
The function that never ends
Screening.
Monitoring.
Reporting.
Audits.
Fraud management.
Reconciliation.
Security and access controls.
Rule changes.
Regulatory updates.
Customer reviews.
These aren't launch tasks.
They're ongoing operating functions.
That's why the real cost of building payments isn't just engineering headcount. It's the permanent organisation required to operate what you've built.
There are only two honest options
Build it.
You own more of the economics, roadmap and infrastructure.
This makes sense when payments is your product — when the differentiation your customers pay for lives inside the money movement itself.
The price is years, not sprints, and an operating cost that never returns to zero.
Buy it. Or embed it.
Someone else provides the underlying financial infrastructure, regulatory capabilities and partner relationships. You configure what you need and build your customer experience around it.
You go live faster.
The price is real too: you share the economics, inherit a partner's roadmap and take on some degree of dependency.
Anyone who tells you otherwise is selling.
The question isn't whether buying is better.
It's whether payments is the thing your customers choose you for — or the thing that has to work underneath the thing they choose you for.
Most platforms, honestly answered, are the second.
The question worth asking in that meeting
Nobody should ask:
"Can we build this?"
You almost certainly can.
The question is:
"Do we want to be in the financial infrastructure business for the next ten years?"
Because that's the commitment on the table.
Not the sprint.
Answer that one first.
The build-versus-buy decision gets much easier afterwards.
Build the financial product. Not necessarily the financial infrastructure.
For platforms that want to embed financial capabilities without building the underlying infrastructure themselves, MatchMove provides account issuance, payments, payouts, card issuing and KYC/KYB capabilities through its regulated infrastructure.
It's the difference between assembling the financial system yourself and building on infrastructure that's already there.
FAQ
Do I need a licence to offer payments inside my own app?
It depends on what you're doing with the money, where you're operating and which payment services you're providing. In Singapore, activities such as account issuance, domestic and cross-border money transfer, merchant acquisition and e-money issuance fall under the Payment Services Act. The applicable licensing requirements depend on the specific business model and activities.
What is BIN sponsorship?
BIN sponsorship allows a company that isn't itself a card-scheme member to issue cards through a sponsoring financial institution. The sponsor provides access to the scheme and takes on defined issuing, regulatory and risk responsibilities.
How long does it take to build payment infrastructure?
The API integration may take weeks. The full infrastructure can take considerably longer because licensing, banking relationships, scheme access, partner due diligence, compliance and operational readiness can become the critical path.
Should I build or buy payment infrastructure?
Build when financial infrastructure is a core competitive advantage. Buy or embed it when payments is important to your product but isn't the reason customers choose you.
The right comparison isn't API cost vs. vendor fees.
It's total cost of ownership vs. the strategic value of owning the infrastructure yourself.
Sources: Monetary Authority of Singapore (MAS); Visa; Financial Action Task Force (FATF).