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
Fee Check

Build on APIs designed for production

Gateway integrations fail in three places: retries that double-charge, unverified webhooks and declines handled as one case. The RapidCents REST API answers each with idempotency keys, signed webhook events and structured decline codes, while hosted card fields keep card data off your servers. Every flow is exercised in the sandbox first. For businesses in Canada, confirm production requirements.

  • Canadian specialists
  • Interchange-plus available
  • Guided migration
  • Post-launch support

Who this solution is for

  • Engineering teams integrating checkout

    Teams building payment into an existing product, where the failure modes matter more than the happy path.

  • Technical founders

    One person deciding the payment architecture, who needs the constraints early rather than after launch.

  • Teams migrating from another gateway

    Existing flows, stored credentials and webhook consumers already in place, and a cutover that has to be reversible.

Common challenges

  • Retries that bill twice

    A timeout is not a decline. Without idempotency, the safe retry and the double charge look identical from the client side.

  • Unverified webhooks

    An endpoint that accepts any POST is an endpoint anyone can post to. Signature verification is the difference between an event and a claim.

  • Declines handled as one case

    A soft decline that would succeed on retry and a hard decline that never will need different code paths, which requires structured decline codes rather than a message string.

The RapidCents approach

  1. Create sandbox credentials and run the flows you actually need against test cards.

  2. Implement authorize and capture as separate steps if you ship later than you charge.

  3. Send an idempotency key on every write, so a network failure can be retried safely.

  4. Verify webhook signatures, and treat the webhook rather than the browser redirect as the source of truth for payment state.

  5. Complete the certification checklist, then monitor live traffic and settlement in the dashboard.

Recommended capabilities

  • REST API

    Endpoints for payments, refunds, customers, tokens and settlement, versioned so an upgrade is a decision rather than a surprise.

  • Idempotency keys

    A repeated write carrying the same key returns the original result instead of creating a second charge.

  • Signed webhooks

    Lifecycle events carry an HMAC signature your endpoint verifies before acting on them.

  • Structured decline codes

    Machine-readable reasons, so retry logic can distinguish a soft decline from a hard one.

  • Rapid.js embedded fields

    Card fields hosted by RapidCents and styled as part of your own checkout, which keeps card data off your servers while the interface stays yours.

Related products

Implementation approach

  • Sandbox

    Test credentials and test cards before any production key exists. Every flow you will run in production can be exercised there first.

  • Integration build

    Authorize and capture, refunds, customer tokens and webhook handling, written against the API version you intend to ship on.

  • Certification

    A checklist covering the flows you built, completed before production credentials are issued.

  • Monitoring after launch

    Live traffic, decline reasons and settlement visible in the dashboard, so the first anomaly is found by you rather than reported by a customer.

What does not change

  • Your stack

    The API is REST over HTTPS. There is no required framework, runtime or SDK.

  • Your checkout design

    Rapid.js fields are styled by you. Reducing PCI scope does not mean handing over the interface.

  • Your PCI obligation

    Hosted fields and tokenization reduce what is in scope. They do not remove the requirement to validate on the questionnaire that matches your integration.

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

What is the difference between the webhook and the redirect?

The redirect tells you the customer came back. The webhook tells you what happened to the payment. A customer who closes the tab never redirects, and the payment still succeeded, which is why order state should be driven by the webhook.

How do I retry safely after a timeout?

Send the same idempotency key. The repeated request returns the original result rather than creating a second charge, so the client can retry without knowing whether the first attempt reached the server.

Do I have to handle 3-D Secure myself?

With hosted checkout the challenge is handled on the RapidCents page. With an embedded or API integration your application handles the challenge event the component emits. Either way, the rules that decide when authentication runs are configured rather than coded.

Is there an uptime commitment?

The gateway API carries a 99.9% uptime SLA. It is scoped to the gateway API specifically rather than to every surface.

Can I test declines?

Yes. The sandbox provides test card numbers, simulated declines and settlement events, with outcomes tied deterministically to the test card, which is the only reliable way to exercise retry logic before it meets a real card.

What happens when the API version changes?

Endpoints are versioned, so an existing integration keeps its behaviour. Upgrading is a change you make deliberately. Note also that sandbox fees, funding timing and underwriting outcomes are illustrative — the live values come from your account.

Should authorization and capture be separate calls?

Only if you ship later than you charge. Authorizing at order time and capturing when the goods leave holds the funds without taking them for an order not yet fulfilled; a sale charged on the spot is simpler as one combined step, with nothing to reconcile between two calls.

Is an SDK or a specific framework required?

No. The API is plain REST over HTTPS and needs no framework, runtime or SDK, so the integration can be written in the language your product already uses. The one browser component to plan for is Rapid.js, which hosts the card fields and keeps card data off your servers.

What can we see once the integration is live?

Live traffic, decline reasons and settlement, all in the dashboard. Watching them from launch means the first anomaly is found by your team rather than reported by a customer, and decline reasons show whether retry logic is separating soft declines from hard ones.

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.

Check My Processing CostsGet Started
  • No obligation
  • Canadian payment specialists
  • Secure statement upload