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

DEVELOPER PLATFORM

Code Samples

RapidCents code samples are copy-ready examples for the operations most integrations need on day one: creating a payment, capturing an authorization, issuing a partial refund, vaulting a card for reuse and verifying a webhook signature. Each runs against the sandbox unchanged with a documented test card, in Node.js, Python, PHP and plain cURL. The error handling in them is the handling the operation actually needs, not a comment saying to add some later. Secret storage, logging and framework wiring are left to your application.

  • Sandbox with documented test cards
  • Signed webhooks
  • Typed errors and idempotent retries
  • Dedicated developer support
RapidCents copy-ready payment code sample beside a successful sandbox response
A copy-ready RapidCents payment example next to the sandbox response it produces.

What crosses the wire

  • What each sample shows

    One complete round trip: the request as it is built, the credential as it is attached, the success path and at least one failure path. Field names in the sample match the API reference, which is where their meaning is documented.

  • What is deliberately left out

    Secret storage, logging, queueing and framework wiring. Those belong to your application, and a sample that guessed at them would be wrong for most readers and copied anyway.

  • How to adapt one

    Replace the credential, keep the idempotency key generation, keep the raw-body handling in the webhook sample, and swap the error branches for your own actions rather than deleting them.

When to use it

  • First integration

    Start from a working sample rather than assembling one from reference pages, then read the reference to understand what you pasted.

  • Adding a capability

    Refunds, tokenization and webhook handling each have a sample to adapt, which is faster and safer than extending the payment call you already have.

  • Reviewing someone else’s integration

    The samples are a baseline to compare against when a payment path was written by a contractor or inherited from an earlier team.

How to implement Code Samples

  1. Copy the sample for your language and drop in your sandbox key.

  2. Run it against a documented test card and read the response before changing anything.

  3. Run it a second time with a declining card and confirm the failure branch executes.

  4. Adapt the error handling to your own logging, retries and customer messaging.

  5. Move to production keys after the sandbox run is clean, and swap the signing secret with them.

What fails, and how you find out

  • The error branch was deleted

    The most common edit to a sample is removing the part that handles failure because it is not needed to see a success. That branch is the reason the sample exists.

  • The idempotency key became a constant

    Hard-coding it to get a sample running turns every subsequent charge into a repeat of the first one, and the symptom is payments that appear to vanish rather than fail.

  • Raw body handling lost in the paste

    The webhook sample reads the request before the framework parses it. Dropped into a route that already receives a parsed object, verification fails on every valid event.

  • Sandbox credentials shipped with the code

    A sample carries a placeholder key. Committing it with a real one, even a sandbox one, trains the habit that produces the same commit with a production key later.

Sandbox versus production

  • Written against sandbox by default

    Every sample assumes sandbox credentials and a documented test card, so a first run is safe by construction and produces the same result for everyone reading the page.

  • The same code is the production code

    Only the credential changes. If a sample needs edits beyond configuration to work on production, that is a defect in the sample rather than a step you are expected to figure out.

  • The webhook sample needs a tunnel

    It expects an endpoint the platform can reach. In sandbox an HTTPS tunnel to localhost is enough; production needs a routable address, and that is the one part of the sample that changes at cutover.

Questions about Code Samples

Are the code samples production-ready?

They demonstrate the correct call sequence and error handling, but secrets management, logging and queueing remain your application’s responsibility.

Which languages are covered?

Node.js, Python and PHP, matching the official SDKs, with plain cURL for anything else.

Do the samples cover webhook verification?

Yes. Signature verification is included, because it is the step most commonly implemented incorrectly.

Can I paste a sample straight into my checkout route?

Not without checking two things: that the idempotency key is generated per operation rather than reused, and that the webhook sample still sees the raw request body after your framework middleware runs.

Why do the samples show an error path I do not think I need?

Because the decline is the branch your customers will meet most often, and because a timeout you never handled is what produces a duplicate charge. Those two paths are the ones worth copying most carefully.

Do the samples use the SDK or raw HTTP?

Both, so you can see what the SDK is doing on your behalf. The cURL version is the one to read when you are porting to a language without an official SDK.

Where do the field names in a sample come from?

From the API reference for the endpoint being called. If a sample and the reference ever disagree, the reference is the contract and the sample is the thing to report.

What should I change first when adapting a sample?

The credential, and nothing else, until it runs. Read the response from a documented test card before editing anything. Then keep the idempotency key generation and the raw-body handling, and swap the error branches for your own actions rather than deleting them.

Do the samples ever put card data through my own server?

No. Card entry belongs to Rapid.js hosted fields or a hosted payment page, and the vaulting sample works with the token that comes back. That is what keeps a pasted sample from widening your PCI scope, and it is the property to preserve when adapting one.

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