Build vs Buy for Fintech Integrations: 5 Costly Mistakes

Most fintech integration decisions inside Indian SMBs get made in one meeting, usually right after a payment provider sends revised pricing or a bank emails that an old API is being retired. The question gets framed as "build or buy", but it is really a five-year cost question with a compliance tail. These are the five mistakes we see repeated across payment, GST and messaging integrations — and what to do instead.

Mistake 1: Treating build vs buy as one decision for the whole stack

Build vs buy is not a single call. It is a per-capability call, and the right answer is often to buy the rails and build the logic. Money movement, card storage, GST and e-invoice filing, WhatsApp Business API delivery — these are all regulated, all change with circulars you do not control, and none of them differentiate you. Approval workflows, credit terms, TDS treatment, customer-specific pricing and the reconciliation rules your finance team argues about every month — that is where your business actually lives.

A split that tends to hold up:

• Buy: payment collection, mandate and e-NACH execution, GSP filing for GST and e-invoicing, WhatsApp and SMS delivery.
• Build: approval chains, credit control, ledger mapping, dispute workflows.
• Build thin: adapters so a second gateway, bank or GSP can be swapped without a rewrite. A few days now, weeks later.

Mistake 2: Budgeting the build and forgetting the maintenance

A fully loaded backend engineer in India costs roughly ₹15-25 lakh a year. A three-month integration build consumes maybe ₹4-6 lakh of that time, and that is the number the finance team approves. The number nobody approves is the two to four days a month, forever, spent on API version upgrades, key rotation, a bank quietly changing a response field, and regulatory deadlines. Call it ₹3-6 lakh a year in engineering time — before you count the hours someone spends chasing failed settlements.

The rough test: if annual maintenance is more than a third of what a vendor charges you, buying wins on cash alone. Add key-person risk and it usually wins by more.

Mistake 3: Leaving compliance out of the estimate

Compliance is the line item that turns a two-month build into a six-month one. For payments, that means PCI scope, RBI rules on who may aggregate payments, and card tokenisation. For finance, it means keeping e-invoicing and IRN generation current through a GSP, and getting TDS classification right on marketplace-style payouts. For outreach, it means DPDP Act consent, WhatsApp template approvals, and DLT registration if SMS is involved. Build, and you own all of it on your own deadlines. Buy, and you are effectively renting the vendor's compliance team — a real saving that never appears on the invoice.

Mistakes 4 and 5: Ignoring failure paths, and no exit route

These two show up about a year in. Failure paths first: webhooks drop, UPI mandates bounce, settlement files land late on a Saturday. If your integration assumes success, your finance team becomes the retry mechanism.

Before you commit, get written answers to these:

• When a settlement is ₹4,000 short and the gateway says the transaction succeeded, who investigates, and how?
• Who owns a failed retry at 11pm, and what is the escalation path?
• Can we export every transaction, fee, refund and state change as a flat file — today, and after we leave?
• If pricing rises sharply at renewal, how long would a switch actually take?

The exit route is the second half of that mistake. Lock-in is rarely about the contract; it is the data model. If the only interface is a dashboard and fee breakdowns need a support ticket, your switching cost is measured in quarters, not weeks. Ask for raw event data, webhooks on every state change, and a documented export. Then put price-review and data-portability clauses in writing.

Where to start

Pick one integration — usually collections and reconciliation — and cost it over five years, not one. Write down build time, maintenance hours, compliance ownership and exit cost side by side; the decision usually becomes obvious. That is the kind of scoping work we do at Maysan Labs before anything gets built, and it is far cheaper than discovering in year three that the cheapest option was never the cheapest.