DEVELOPER PLATFORM
API Reference
The RapidCents API reference documents every endpoint with its request schema, response schema and error cases: authorize and capture, void, refund, tokenize, manage customers and stored credentials, query settlements and replay webhook events. Calls run server to server over HTTPS with a secret key, a pinned API version and an idempotency key on anything that changes state. Responses carry the resource state, a request id for tracing, and on failure a typed code. It is generated against the live interface.
- Sandbox with documented test cards
- Signed webhooks
- Typed errors and idempotent retries
- Dedicated developer support
What crosses the wire
Where it sits
Server to server, over HTTPS, authenticated with a secret key. It is the layer behind hosted checkout, Rapid.js and the dashboard, so a payment created by any of those is readable and refundable through the same endpoints.
What you send
A JSON body plus headers: the secret key, the API version your account is pinned to, and an idempotency key on anything that changes state. The reference names each input and marks required against optional per endpoint.
What comes back
A JSON object with the resource and its current state, a request id for tracing, and on failure a typed code with a machine-readable meaning. HTTP status classifies the outcome; the code inside the body is what you branch on.
When to use it
Building server-side
Payment creation, capture, void and refund all run from your backend with the secret key, which is the only place a secret key belongs.
Reconciling finance systems
Settlement endpoints expose batch, fee and deposit records, so an accounting export ties a deposit back to the transactions inside it rather than to authorization responses.
Automating back-office work
Customer records, stored credentials and refunds are all addressable, so operations that staff would otherwise do by hand in the dashboard can run on a schedule.
How to implement API Reference
Authenticate with your secret key over HTTPS and pin the API version explicitly.
Send an idempotency key with every state-changing request, generated per logical operation.
Branch on typed error codes rather than parsing message strings.
Store the request id from every response alongside your own transaction record.
Reconcile against settlement records rather than authorization responses.
What fails, and how you find out
A reused idempotency key
Reusing a key for a genuinely different operation returns the first result, which looks like the second charge silently disappeared. Derive the key from the operation, not from the customer or the session.
An authorization that is never captured
It expires inside the issuer window and the hold is released. Nothing settles, so a fulfilment pipeline that waits for a capture event will simply stop, with no error to catch.
Throttling treated as an outage
Exceeding the limits applied to your account returns a documented status with a retry hint, not a dropped request. Backing off on that signal is the fix; hammering it is what turns it into an incident.
Sandbox versus production
Same endpoints, same schemas
Sandbox is not a reduced surface. The endpoints, the request bodies and the error codes are the ones you will call on production, which is what makes a sandbox regression suite worth keeping.
Deterministic declines
A production decline depends on the issuer and can change between attempts. In sandbox the test card fixes the outcome, so a test asserting a specific error code stays green for the right reason.
Settlement you do not have to wait for
Batch, fee and deposit records appear on an accelerated schedule so reconciliation code can be exercised in a single test run instead of across a funding cycle.
Questions about API Reference
How does idempotency work on the RapidCents API?
Supply an idempotency key on payment creation and a retry with the same key returns the original result instead of charging twice, which makes network timeouts safe to retry.
What happens when a payment is authorized but never captured?
The authorization expires within the issuer’s window and the held funds return to the cardholder. Nothing settles and no fee applies to the expired authorization.
Are there rate limits?
Yes, applied per account. Exceeding them returns a documented status code with a retry hint rather than dropping the request silently. The reference documents the limits that apply and how a response signals one has been hit.
Should I read a payment result from the API response or from a webhook?
Both, for different reasons. The response is the synchronous outcome and is what the customer waits on. The webhook is the durable record of every later state change, including refunds, disputes and funding, and is what your ledger should follow.
How do I trace one transaction end to end?
Keep the request id from the creating call, the event id of each webhook you processed, and the settlement record the payment landed in. Those three identifiers let support follow a single attempt without reproducing it from a description.
What is the difference between voiding and refunding?
A void cancels an authorization before it settles, so the cardholder never sees a completed charge. A refund returns money after settlement and appears as a separate credit. Which one applies depends on where the payment is in its lifecycle, not on what you prefer.
Can I call the API from a browser or mobile app?
No. Secret keys authorize money movement and must stay server-side. Client surfaces use Rapid.js with a publishable key, which can tokenize card data and nothing more.
Can I refund a payment the API did not create?
Yes. Payments taken through hosted checkout, a payment link, Rapid.js, a terminal or the dashboard are all readable and refundable through the same endpoints, because they land on one merchant account rather than in separate systems.
How do partial captures and partial refunds work against one authorization?
Capture and refund are separate operations on the payment, and each takes its own idempotency key derived from that operation. What remains available depends on the payment’s current state, which the response reports, and the endpoint page states which transitions the resource allows.
Continue the integration
A RapidCents server-to-server request being signed on a developer desk, with a sandbox terminal for the in-person counterpart. Authentication
API keys, OAuth for partners and request signing for server-to-server integrations.
ExploreA typed RapidCents API error on screen, next to the declined sandbox terminal sale that produced it. Errors
Typed error codes, retry guidance and idempotency patterns for production reliability.
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.
ExploreA 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
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
- Payment specialists, not a call centre
- Secure statement upload
