DEVELOPER PLATFORM
RapidCents APIs
The RapidCents APIs are the programmable surface of the payment platform: REST resources for payments, refunds, customers, stored credentials, tokens and settlement, over HTTPS with JSON bodies. They are the same interface the dashboard, hosted checkout and embedded fields run on, so a sale taken at a terminal, through a link or from your own code becomes the same kind of record. Four guarantees hold throughout: environment-scoped keys, idempotent money movement, typed error codes, and a signed webhook for later changes.
- Sandbox with documented test cards
- Signed webhooks
- Typed errors and idempotent retries
- Dedicated developer support
What crosses the wire
Where it sits
Behind everything. Your server calls it directly; Rapid.js reaches it with a publishable key to create a token; a terminal sale and a dashboard refund land in the same records. There is one account, one vault and one settlement view underneath all of them.
What you send
A JSON body, a secret key, the API version you are pinned to, and an idempotency key on anything that moves money. Amounts, currency, the payment method reference and your own order reference are the inputs most calls need; the reference names each field exactly.
What comes back
The resource and its current state, plus a request id. Read the state rather than assuming a 2xx means approved, and keep the request id: it is the only thing that makes a single attempt traceable afterwards.
When to use it
Building your own checkout
When the payment step has to live inside your product and follow your own rules about carts, taxes, deposits or partial fulfilment.
Automating operations
Refunds, customer records and stored credentials are all addressable, so work that would otherwise be done by hand in the dashboard can run on a schedule.
Feeding finance systems
Settlement resources expose the batch, the fees and the deposit, which is what lets a ledger entry be written against money that actually arrived rather than against an authorization.
How to implement RapidCents APIs
Get sandbox credentials and pin an API version explicitly in your client.
Create a payment server-side with an idempotency key derived from the operation.
Register a webhook endpoint and verify signatures before acting on any event.
Map every typed error code to an action, with unknown codes failing closed.
Reconcile against settlement records, then move to production keys.
What fails, and how you find out
Treating the HTTP status as the outcome
A call can succeed and the payment still be declined. The state in the body is the answer, and reading the status alone is how declined orders get fulfilled.
Polling instead of listening
Repeatedly reading a payment to see whether anything changed is slower than the webhook, heavier on your rate limits, and still misses refunds and disputes raised outside your application.
Idempotency keys derived from the wrong thing
A key tied to a customer or a session collapses two genuine purchases into one. Derive it from the operation, store it with your record, and reuse it only when retrying that exact attempt.
Reconciling against authorizations
Authorizations expire, get voided and get partially captured. A finance process built on them disagrees with the bank; one built on settlement records does not.
Sandbox versus production
The same surface, smaller consequences
Sandbox exposes the same resources with the same schemas. What changes is that outcomes follow the test card, settlement is compressed, and nothing that happens is money.
Rate limits still apply
Sandbox is not a load environment. Limits exist there too, so a test suite that hammers the API will meet the same throttling response your production code needs to handle anyway.
Availability is scoped to the gateway
The gateway API carries a 99.9% uptime service level on production. Sandbox is provided for development and is not the environment that commitment describes.
Questions about RapidCents APIs
What can the RapidCents APIs do that the dashboard cannot?
Everything the dashboard does, on a schedule and at volume, plus the parts your own product needs to own: a checkout that follows your cart rules, refunds triggered by your fulfilment system, and exports shaped for your ledger rather than for a screen.
Do I need a separate integration for online and in-person payments?
No. Terminal, hosted checkout, payment link and API payments land on the same account and appear in the same records, so reporting, refunds and reconciliation are one integration rather than several.
How do I avoid double-charging a customer on a network timeout?
Send an idempotency key with the original request and reuse that exact key on the retry. The second call returns the first result instead of creating a second payment, which is what makes an unknown outcome safe to retry.
Can I store card numbers if I want full control?
You can hold a token instead, and the practical answer is that you should. Posting raw card data directly puts your systems in the widest PCI assessment; tokenizing through a RapidCents-hosted surface keeps the credential out of your environment entirely.
What is the fastest way to know an API change affects me?
Pin your version, subscribe the changelog to a channel someone reads, and record which version each of your services sends. Those three things turn a breaking change into a scheduled ticket.
Where do I find rate limits and exact field names?
In the API reference, per endpoint. This page describes the shape of the surface and the guarantees that hold across it; the reference is the contract and is the document to trust.
How do I know a payment settled rather than only authorized?
Read the settlement resources rather than the authorization. They expose the batch, the fees deducted and the deposit, which is what lets a ledger entry be written against money that actually arrived. Authorizations expire, get voided and get partially captured, so a finance process built on them will disagree with the bank.
What should my code do with an error code it does not recognise?
Fail closed. Map every typed error code you know to a specific action, and treat anything unknown as a failure rather than as a success by default. A new code appearing in production should stop the operation and raise an alert, not fall through a branch that assumes approval.
Continue the integration
The RapidCents API reference on a workstation, with a sample request, the matching response, and a test terminal. API Reference
REST endpoints for payments, customers, refunds, webhooks and settlements with request and…
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
Rapid.js hosted card fields on a developer workstation, keeping card entry out of the merchant's PCI scope. Rapid.js
Embedded payment components for the web that keep card entry inside RapidCents-hosted fields…
Explore
The RapidCents tokenization API returning a card token, so merchant software never stores the PAN. Tokenization API
Create, reuse and retire payment tokens programmatically so your systems never store card…
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
