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 predictable places: retries that double-charge, webhooks nobody verified, and declines handled as one case. The RapidCents REST API answers each — idempotency keys so a repeated write returns the original result, HMAC-signed webhook events an endpoint verifies before acting, and structured decline codes that separate a soft decline from a hard one. Rapid.js hosted card fields keep card data off your servers while the checkout interface stays yours. Every flow is exercised in the sandbox first.

  • Payment 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.

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?

Separate them 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 you have not fulfilled. For an immediate sale a single combined step is simpler, and there is nothing to reconcile between the two.

Is an SDK or a specific framework required?

No. The API is REST over HTTPS, with no required framework, runtime or SDK, so the integration is written in whatever your product already uses. Rapid.js is the exception worth knowing about: it hosts the card fields in the browser, which is what keeps card data 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.

Check My Processing CostsGet Started
  • No obligation
  • Payment specialists, not a call centre
  • Secure statement upload