Most platforms treat adding payments as an integration task. Pick a provider, wire up the API, ship it. Then the boarding friction, the underwriting questions, the first chargeback and the first reconciliation mismatch all arrive in the same week, and the team realizes payments was never a feature. It is an operation they now run.
This is the roadmap from decision to live, and past live, written from the operator seat. It assumes you have already made the model call. If you have not, that is step one, and it changes everything downstream.
Implementing embedded payments is a sequence, not a switch. It runs in six stages: lock the monetization model, select the provider and contract, integrate and board merchants, migrate the existing book, go live and drive activation, then operate what you now own. Most platforms underestimate two things: how much responsibility shifts onto them at each stage, and that go-live is the middle of the project, not the end.
What does embedded payments implementation actually involve?
Six stages, and a theme that runs through all of them: at each step you take on more of the economics and more of the responsibility that comes with it. The integration everyone worries about is one stage of six, and rarely the one that decides whether the program works. What decides it is boarding, migration and activation, the parts that touch merchants.
Step 1: Lock the monetization model before you integrate
Referral, managed payfac or full payfac is not a pricing detail you settle later. It determines who underwrites the merchant, who owns the risk, who sets the price and how much of the economics you keep. Integrate first and decide the model later and you will rebuild the integration. Decide the model, then everything downstream inherits from it.
If you have not made this call yet, start there. Whether your platform is even ready to monetize payments comes first, and the difference between the referral and payfac models is the decision that shapes the rest of this roadmap.
Step 2: Select the provider and negotiate the contract
The provider selection is a fit question, not a logo question: underwriting and boarding support, reliability, reporting and how much operational weight they carry versus leave to you. The contract is where the economics live. The terms that matter most are the revenue split, the volume-based repricing and the exit and portability language, because the deal that fits at 500 merchants is often wrong at 5,000.
More on how to choose a provider and how to negotiate the processor agreement so the economics still work at scale.
Step 3: Integrate, then board merchants
The integration is the easy half. The hard half is boarding, because that is where you inherit underwriting and KYB obligations you did not have before. Every field you ask a merchant for is a chance to lose them, and every merchant you approve is one you are now accountable for. Design the boarding flow for completion, not for compliance theater, and treat underwriting as an ongoing function, not a one-time gate.
Step 4: Migrate the existing book without churning it
Your existing merchants are the biggest year-one revenue lever and the biggest churn risk in the whole project. Move them badly and you trade a working relationship for a support ticket. Migrate in phases, communicate before you touch anything and run old and new in parallel long enough to catch what breaks. The back-book is where the year-one number is won or lost.
Step 5: Go live and drive activation
Live is not adopted. Going live means the capability exists. Activation means merchants actually use it, and that is a separate job with its own playbook. A platform that ships payments and moves on typically stalls at 15 to 20 percent of the base, then blames the product. The activation work, positioning, timing and sales enablement, is what turns a launched program into a used one.
Step 6: Operate what you now own
This is the stage nobody scopes. Support for payment issues, disputes and chargebacks, reconciliation, recurring billing and often reserve and liability, depending on the model. None of it is hard in isolation. All of it together is a function that needs an owner and a process on day one, not the day the first problem arrives. Once it is running, reading the payments P&L is how you know whether the program is actually working.
How long does embedded payments implementation take?
Honestly, it depends on the model. A referral arrangement can be live in weeks. A managed payfac program is usually a few months. Full payfac is a 12 to 18 month build with real capital and headcount. The spread is driven by how much of the stack you own, which is exactly the tradeoff from step one.
The mistakes platforms make during implementation
Treating go-live as the finish line. Under-resourcing boarding because the integration looked done. Skipping the migration plan and churning the book. Running for months with no reconciliation process because deposits kept showing up. Each one is avoidable, and each one is the default if nobody owns the operation.
Go-live is the middle of the project, not the end. The integration is the part you can schedule. Boarding, migration and activation are the parts that decide whether any of it was worth building.
Related reading in the implementation cluster: merchant underwriting and KYB (what you own at step 3), and recurring billing and the payments stack (part of step 6). For operational support pressure-testing your own plan, see the advisory engagement.