Skip to main content
NewChargeback Protection + Fee Intelligence for high-volume merchants. Get a savings analysis and a review of your dispute handling.See how it works
Details

Chargeback Protection + Fee Optimization

See how it works: high-volume merchants get automated dispute evidence, interchange optimization, and real-time savings visibility.

See how it works

Embed payments into your platform revenue model

A platform embedding payments takes on two jobs: the payment, and the onboarding, splitting and payout of the businesses using it. RapidCents verifies sub-merchants through hosted signup or an onboarding API, splits each payment between the platform fee and the seller's portion, holds reserves where risk requires and reports platform revenue separately. For businesses in Canada, confirm eligibility.

  • Canadian 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

  1. Agree the model: who is responsible for each transaction, and how revenue is shared.

  2. Choose the onboarding surface, either hosted seller signup or the onboarding API inside your own interface.

  3. Define split rules — platform fee and seller portion — applied on capture rather than reconciled later.

  4. Build against the sandbox with webhook handling, then certify the flows you will actually run.

  5. 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.

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.

Cards, currencies and settlement in Canada

What a RapidCents account in Canada accepts, the currencies it settles in, and when the money arrives.

  • Cards and methods accepted

    Visa, Mastercard, American Express, Discover, UnionPay and Diners Club cards from any country, plus Interac Debit, Apple Pay, Google Pay and EFT/PAD bank payments, on one merchant account.

  • 137+ currencies, settled in CAD or USD

    Process in CAD, USD, EUR and 137+ currencies, and deposit payouts directly into your Canadian CAD bank account or your Canadian USD bank account, so USD sales are not converted twice.

  • Next-business-day funding and reconciliation

    Batches close nightly and deposits arrive the next business day, based on cut-off times and eligibility, with deposit-level reporting in one RapidCents dashboard.

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?

From the document status and capability flags shown for each seller, whichever onboarding surface you use. Your product can gate a seller's ability to sell on those flags instead of on a manual check.

Where do seller verification requirements come from?

From the card networks and the regulator, not from a change in who your sellers deal with. Sub-merchants are onboarded under your platform, so the relationship stays with you.

Does checkout stay inside our product?

Yes. Card fields and payment widgets mount inside your application and carry your own styling, emitting events your application handles, so checkout stays in your product while raw card data stays off your servers.

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
  • Canadian payment specialists
  • Secure statement upload