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

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
Copy the sample for your language and drop in your sandbox key.
Run it against a documented test card and read the response before changing anything.
Run it a second time with a declining card and confirm the failure branch executes.
Adapt the error handling to your own logging, retries and customer messaging.
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.
Continue the integration

A RapidCents SDK project running a test payment, with the same sale visible on a sandbox terminal. SDKs
Official SDKs for Node.js, Python, PHP and mobile with typed models and retry helpers.
Explore
The RapidCents quickstart path: create a test payment, see the response, and confirm it on a sandbox terminal. Quickstart
Get sandbox credentials, create a test payment, receive a webhook and prepare for production in…
Explore
A RapidCents webhook delivery timeline next to the payment that triggered it, with a test terminal on the desk. Webhooks
Signed webhook events for payment lifecycle with idempotent processing guidance.
Explore
A developer working through a RapidCents integration guide, sandbox terminal on the desk and a successful test result on screen. Integration Guides
Step-by-step guides for e-commerce, POS, mobile and marketplace integrations.
Explore
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





