How long does it take to add embedded payments to your software?

The question usually arrives as "how long will this take?" and the answer a CTO wants is a date. The trouble is that the date depends on things the payments provider does not control: how many people your team can put on it, whether they have built against a payments API before, how your product models a customer and an invoice today, and what else is in the roadmap for the same quarter.

A figure that gets repeated in the market, six to nine months, is not one we can source to a study, so we do not state it as fact. What we can do is set out the published estimates, say what each one covers, and show which parts of a build add the time. You can then size your own.

Synapto never gives a timeline for your developer's work. We ship an SDK, documentation and a test environment, and a named payments engineer answers questions while your team builds. The build runs on your developer's schedule, so the date is theirs to set.

There are few independent measurements of how long a platform integration takes. The estimates below are the clearest we found; all are from providers with something to sell, so read them as a floor for engineering effort, not a project plan.

Two things stand out. First, the per-feature figures are effort, not elapsed time: two weeks of one engineer's effort can be six weeks of calendar time once it sits beside everything else. Second, none of the estimates include the parts that make a platform build different from a shop's checkout: signing up your customers inside your product, writing settlement back to your ledger, and paying your customers out. Those are where the months come from.

There is also a reason to take the time seriously. A platform whose first launch stalls carries that into every later conversation, with its customers and with its own board, and a customer who had a bad first experience of your payments is the hardest one to bring back. A rushed first attempt costs more than a slow one.

Four pieces of work decide whether a build is weeks or months. Each is your developer's to build against the SDK; each is where a payments engineer earns their place.

The onboarding flow

Your customers have to be identified and their bank details verified before they can be paid. If that happens inside your product, your developer builds the screens and the calls that collect the legal entity, the owners, the bank account and the documents, and handles the states in between: pending, more information needed, approved, declined. Mews, a hospitality platform, lists incomplete beneficial owner or tax identifier details as the most common reason payments activation stalls at go-live. The flow is not hard to build; the states and the edge cases are what take the time.

Reconciliation

A payment that lands in a bank account as part of a batch is not reconciled until it is matched to the invoice it paid, with the fee itemised. If your product already has a ledger, your developer maps settlement records to it. If it does not, that is a product decision before it is an integration task. This is the piece most often left out of the estimate and most often the reason a launch slips a quarter.

Payouts

For a platform that pays its customers out, the build includes the schedule, the split between what the customer keeps and what you keep, the statement the customer sees, and what happens when a refund lands after a payout. Each is small. Together they are a second product.

Go-live checks

Before a live payment moves: production keys separated from test keys, webhook signatures verified, handlers that cope with the same event arriving twice, a successful payment, a declined one, a 3D Secure challenge, a refund and a dispute all exercised end to end. Every published go-live checklist lists the same items; the time they take is the time it takes your team to run them properly.

Rather than take a number from a vendor, size the four pieces against your product.

1. Do your customers sign up inside your product today? If you already collect company details and bank accounts for another reason, the onboarding flow is an extension. If not, it is new.
2. Does your product have a ledger? If invoices, credits and payments are already modelled, reconciliation is a mapping exercise. If money is a number on a booking record, it is a build.
3. Do you pay anyone out? A platform that only collects is simpler than one that collects and distributes.
4. Has the team built a payments integration before? A team that has handled soft declines, partial captures and chargeback webhooks once will not need to learn them again.

Answer those four honestly and you will have a better range than any published figure, because the range will be yours. Ask the payments partner to walk through each one with your developer before anything is promised to your customers.

What shortens a build: one SDK rather than several processor integrations; a test environment that behaves like production; documentation that says what a webhook contains rather than that it exists; and a payments engineer who answers the payments question the day it comes up rather than in a ticket queue three days later. What does not shorten it: a promise. A date set by a provider for work a platform's own developer is doing is not a plan, it is a sales tactic, and the first missed milestone is where trust goes.

Scope with milestones before anything is promised to your customers. Then the date is one your developer set, against work they can see.