Embed payments into your platform revenue model
A software platform embedding payments takes on two jobs: the payment, and the onboarding, splitting and payout of the businesses using it. RapidCents handles sub-merchant verification through hosted seller signup or an onboarding API, defines the platform fee and the seller portion per transaction and applies both when the payment is captured, schedules seller deposits daily or weekly with reserve holds where risk requires them, and reports platform revenue and seller liability as separate ledger exports.
- Payment specialists
- Interchange-plus available
- Guided migration
- Post-launch support
Who this solution is for
Vertical SaaS
Software for a trade or industry where the customer already takes payments through someone else, and the payment is the missing part of the workflow.
Marketplaces
A buyer pays and a seller gets paid, which makes onboarding and payout scheduling part of the product rather than part of the plumbing.
Platform finance owners
Whoever reports platform revenue separately from seller liability needs that split to exist in the ledger, not in a spreadsheet.
Common challenges
Onboarding is the product
Sub-merchant verification is the first thing a seller experiences. Built badly, it becomes the reason they never activate.
Splitting after the fact
Calculating the platform fee after settlement means reconciling two records that were never designed to match. Splitting at capture removes the problem instead of managing it.
Payout timing and reserves
Sellers ask when they get paid before they ask anything else, and the answer comes from schedule and reserve policy rather than from the payment itself.
The RapidCents approach
Agree the model: who is responsible for each transaction, and how revenue is shared.
Choose the onboarding surface, either hosted seller signup or the onboarding API inside your own interface.
Define split rules — platform fee and seller portion — applied on capture rather than reconciled later.
Build against the sandbox with webhook handling, then certify the flows you will actually run.
Launch with a small cohort of sellers and confirm payouts and ledger exports before opening it wider.
Recommended capabilities
Connected onboarding
Hosted KYC or an onboarding API for sub-merchants, with document status and capability flags visible per seller.
Split charges
Platform fee and seller portion defined per transaction and applied when the payment is captured.
Payout scheduling
Daily or weekly seller deposits, with reserve holds where the risk profile calls for them.
Embedded UI components
Card fields and payment widgets mounted inside your application with your own CSS, which keeps checkout in your product and raw card data off your servers.
Ledger exports
Platform revenue and seller liability as separate reports, which is the first thing an accountant asks for.
Related products

Card fields hosted by RapidCents sit inside a merchant checkout, with a terminal and the payments dashboard beside them. Embedded Payments
RapidCents embedded payments provide drop-in UI components, card fields, wallet buttons and payment status…
Explore
A software platform routes connected-merchant payments through RapidCents, with terminals and settlement in one view. Platform Payments
RapidCents platform payments enable marketplaces, franchises and software platforms to onboard…
Explore
A payment-gateway integration desk: API response on screen, RapidCents terminal ready for a test sale. Payment Gateway
The RapidCents payment gateway exposes REST endpoints for authorize, capture, void, refund and tokenize…
Explore
Implementation approach
Model review
Business model, flow of funds and responsibility are reviewed before an account is issued. Platform accounts are underwritten on the model, not only on volume.
Sandbox build
Onboarding, split capture, payout and webhook handling implemented against test credentials.
Certification
The flows you intend to run are tested end to end before production keys are issued.
Cohort launch
A first group of sellers goes live, and payouts and ledger exports are verified against real settlement before the rest follow.
What does not change
Your product interface
Embedded components carry your styling and emit events your application handles. Checkout stays inside your product.
Your sellers’ relationship with you
Sub-merchants are onboarded under your platform. Verification requirements come from the networks and the regulator, not from a change in who they deal with.
Your accounting structure
Platform revenue and seller liability export into the ledger you already run.
Frequently asked questions
Who carries the exposure when a sub-merchant takes fraudulent payments?
It follows from the model agreed at underwriting, which is why the model review comes first. Onboarding verification, reserve policy and payout timing all exist to bound that exposure, and all three are set per platform rather than by default.
Do we have to build onboarding ourselves?
No. Hosted seller signup covers it with no interface work. The onboarding API exists for platforms that want verification inside their own product, which is worth the effort mainly when activation rate is a core metric.
When can a seller be paid?
On the schedule configured for your platform, daily or weekly, less any reserve applied. The constraint is risk policy rather than settlement mechanics.
How is our fee recorded?
The platform fee and the seller portion are defined per transaction, applied when the payment is captured, and reported separately in ledger exports.
What does a developer need to start?
Sandbox credentials, the REST API and a webhook endpoint that verifies signatures. Onboarding, split capture and payout can all be exercised against test data before anything is live.
Can we use embedded payments without the platform model?
Yes. Embedded components and hosted fields work for a single business taking its own payments. The platform model only becomes relevant once you are onboarding and paying out other businesses.
How do we know when a seller is cleared to take payments?
Document status and capability flags are visible per seller, whether verification runs on hosted seller signup or through the onboarding API inside your own interface. Your product can gate a seller's ability to sell on those flags rather than on a manual check.
Why is a platform account underwritten differently from a merchant account?
Because the platform, not just the volume, is what is assessed. Business model, flow of funds and who is responsible for each transaction are reviewed before an account is issued, since those decide reserve policy, payout timing and where exposure sits when a sub-merchant goes wrong.
Take the next step
Talk to a RapidCents specialist
RapidCents Fee Check reads a processing statement and shows interchange separately from the markup. Upload a statement for an instant breakdown, or open a merchant account and start accepting payments on one account.
- No obligation
- Payment specialists, not a call centre
- Secure statement upload





