Skip to main content

Payments

What a payments project actually costs

Taking a card is roughly a week of work; making the money retry, refund and reconcile correctly is the rest of the project, and that is where two quotes stop resembling each other.

Get a scoped estimate

Why two quotes for the same job look nothing alike

One firm quotes the checkout. The other quotes the checkout plus the webhook handler that has to survive being called twice, the refund path, the settlement report, and the alert that fires when payments stop overnight. Both are answering the question you asked. Only one of them has read your month-end.

The question that moves the number most is not which gateway you pick. It is whether money ever has to be split, held, or paid onward to someone who is not you. A single-seller checkout and a marketplace paying out vendors share a payment button and almost nothing else.

Cost drivers

What actually moves the number

Every item here has arrived as a change request on somebody's project, after both sides assumed it was simply part of adding payments.

  • Number of gateways

    One gateway is a build. Two is a build plus an abstraction layer, because Stripe and Razorpay disagree about what a refund object even contains.

  • Subscriptions and dunning

    Plans, trials, coupons and proration on a mid-cycle upgrade. Retrying a declined card on a schedule instead of cancelling the customer is separate work again.

  • Marketplace split payouts

    Paying several sellers from one customer transaction needs seller onboarding, KYC per account, a ledger each, and a payout schedule. It roughly doubles a checkout build.

  • Local payment methods

    UPI intent and collect behave nothing like a card. Every added method brings its own pending state, timeout window and failure copy in the checkout.

  • Webhook reliability

    Signed payloads, idempotent handlers, retries with backoff and a dead-letter queue, so a gateway outage delays an order rather than losing one entirely.

  • Reconciliation

    Matching your orders against the provider's settlement file and listing the mismatches instead of quietly netting them off. Finance should run it without asking an engineer.

  • Currencies and tax

    Showing a price in the buyer's currency is easy. Applying GST, VAT or US sales tax by jurisdiction, and settling in another currency, is not.

  • Refunds and chargebacks

    Partial refunds from your own admin screens, the evidence upload flow for a dispute, and a record of who approved each one. Usually remembered after launch.

  • Migrating off a provider

    Card-on-file tokens do not travel between providers, so live subscriptions run on both until the old mandates lapse. Plan it as a project, not a switch.

Scope tiers

Four honest scopes, smallest first

Most teams who write to us belong in the first two. The exclusions under each tier matter more than the inclusions, because that is where a surprise invoice comes from.

TIER 1 — SINGLE GATEWAY CHECKOUT
One gateway, one-off payments live. Ships in 2–3 weeks.
₹1L – ₹1.5L$1.1k – $1.7k
Hosted card fields on your own domain, the success and failure paths, signed webhooks written to your database, and refunds from an admin screen. Right for a first paid product. Does NOT include subscriptions, multi-currency, or a reconciliation report.
TIER 2 — SUBSCRIPTIONS AND BILLING
Recurring billing with failed-card recovery. Ships in 4–8 weeks.
₹3L – ₹6L$3.4k – $6.8k
Plans, trials, coupons, proration, dunning retries, invoices, cancellation flows, and the payment ledger your finance team reads. Right for SaaS moving off manual invoicing. Does NOT include seller payouts, or tax determination beyond one jurisdiction.
TIER 3 — MULTI-CURRENCY, MULTI-GATEWAY
Several providers, several markets, one checkout. Ships in 2–4 months.
₹9L – ₹18L$10k – $20k
A provider-agnostic payment layer, routing by market, local methods such as UPI and net banking, tax by jurisdiction, settlement currency handled separately, and reconciliation against each provider's file. Right for cross-border sellers. Does NOT include seller payouts.
TIER 4 — MARKETPLACE AND PLATFORM PAYMENTS
Split payments and seller payouts. Ships in 4–6 months.
From ₹28LFrom $32k
Seller onboarding with KYC, per-account ledgers, commission logic, split settlement, payout schedules, dispute handling, and reporting for both sides of the transaction. Right for marketplaces. Does NOT include obtaining your aggregator licence or merchant account.

Indicative ranges for scoping conversations, not quotes. They reflect what work of this shape has cost us to deliver — your figure comes out of a paid discovery, against a written scope, and is fixed before any code is written. Gas, licences, cloud and third-party audit fees sit outside these numbers.

How we scope

From gateway choice to money that reconciles

These timings assume the product already exists and someone can hand over sandbox access in the first week. Both assumptions break more often than you would expect.

  1. Discovery

    About a week

    Where your customers pay from, which methods they expect, your quoted fees and settlement terms, and what your finance team currently does by hand at month-end.

  2. Scope and cut

    Under a week

    We write the scope with the exclusions named. This is where a marketplace build often becomes a single-seller checkout, and occasionally where we tell you your current gateway is fine.

  3. Sandbox build

    2–6 weeks

    Checkout, webhooks and the database side built against test mode, with the ugly cases exercised: declined cards, duplicate callbacks, a timeout halfway through a payment.

  4. Live activation and run

    A week, then ongoing

    Production keys, a small run of real transactions watched all the way to settlement, then alerting and the reconciliation job. Providers change their APIs on their own schedule.

Is this worth budgeting for now?

Worth reading before you ask anyone for a quote. A fair number of the teams who write to us should spend the money somewhere else first.

Worth budgeting for now if…

  • Payments are how the product earns, not a side feature
  • Your month-end numbers and the gateway dashboard do not agree
  • You bill on subscriptions and chase failed cards by hand
  • You are selling into a market your current gateway serves badly

Wait, if…

  • A Shopify or WooCommerce payment plugin would do the job today
  • You have no live customers, so payment volume is still guesswork
  • You are switching provider purely on fees at low volume
  • The platform itself still needs building — see Web & SaaS Platform Development
FAQ

Frequently Asked
Questions

Common questions about scoping payments work, what to cut, and what it takes to run afterwards.

Three things, usually. Splitting one payment between several sellers, because that drags in seller onboarding, KYC, a ledger per account and payout schedules. A second gateway, because the two providers disagree about what a refund or a subscription object contains, so you now need an abstraction layer nobody quoted for. And selling into new tax jurisdictions, where showing a local price is trivial but determining GST, VAT or US sales tax correctly is not. Marketplace payouts move the number further than anything else on that list.

Cut the second gateway. One provider covering most of your volume is nearly always enough at the start, and adding another later is contained work if payments sit behind a thin internal interface. Cut multi-currency until you actually have buyers who need it. Cut the hand-built card form and use the gateway's hosted fields, which is cheaper and keeps raw card data off your servers. Do not cut idempotent webhook handling or the payment ledger on your own side. Those two are what make everything after launch debuggable.

Reconciliation, almost every time. Matching your own orders against the provider's settlement file is real engineering, and without it your finance team does the job in a spreadsheet forever. Refund and chargeback handling is the second omission, since evidence upload and an approval trail only feel urgent after the first dispute. Then there is waiting. Merchant onboarding and KYC with the provider run on their timetable rather than yours, and that can hold a launch that is otherwise finished. Budget calendar time for it.

Two separate things, and only one of them involves us. The provider charges per transaction and agrees those rates with you directly, so ask them rather than your development partner. On the engineering side, expect a light recurring load: gateway API versions get deprecated on the provider's schedule, decline rates drift when an issuer changes something quietly, and the reconciliation job needs a human glancing at it. Most teams cover this with a small retainer or a few days a quarter from their own developers.

Phase it. That is the normal path here, not a compromise. Ship one gateway and one-off payments, get real transactions settling into your bank account, and let the reconciliation report show you where the genuine problems are. Subscriptions, extra markets and seller payouts then arrive as separate pieces with their own scope and their own decision to make. The one thing to get right early is keeping payments behind a thin internal interface, so checkout, refunds and webhooks are not written against a single provider's SDK shape.

Have a project in mind?

Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.