DEVELOPER PLATFORM
Developer Support
RapidCents developer support is a direct channel to engineers who can look up a failing request rather than a general contact form. Response commitments are tiered by severity, with production-impacting incidents on the shortest clock and integration questions handled on a business-day basis. What decides how fast a ticket moves is the request id from the failing call: with it, the exact attempt can be traced; without it, the report has to be reproduced from a description.
- Sandbox with documented test cards
- Signed webhooks
- Typed errors and idempotent retries
- Dedicated developer support
What crosses the wire
What to send
The request id from the failing call, the environment, the API version and SDK version in use, the typed error code, and one concrete example of expected versus observed behaviour. Everything else is optional.
What gets looked up
The attempt itself: what was received, what was returned, and what the platform did in between. That is only possible when the identifier is present, which is why it is the first thing asked for.
What comes back
Either an explanation of what your integration did, an explanation of what the platform did, or an acknowledged defect with a reference you can track. All three are useful; a request to try again is not.
When to use it
Blocked in production
Include the request id and the error code so the attempt can be traced immediately rather than reconstructed from a narrative.
During integration
Design questions are answered before you have built the wrong thing, which is far cheaper than a correction after go-live.
Before a migration or a cutover
A review of what you intend to change, sent in advance, is a shorter conversation than an incident during the change itself.
How to implement Developer Support
Capture the request id from the failing response.
Note the environment, the API version and the SDK version.
Describe expected versus observed behaviour with one concrete example, not a class of examples.
Say what you have already ruled out, so nobody repeats the work.
Open the channel appropriate to severity, and state the customer impact plainly.
What fails, and how you find out
Request ids not logged
The identifier only exists on the response you already discarded. Logging it alongside your own transaction record costs nothing and is the difference between a traceable incident and an unprovable one.
Reporting a symptom instead of an attempt
A ticket saying declines went up is a research project. A ticket naming three request ids that returned the same code in a fifteen-minute window is a lookup.
Severity set by frustration
Escalating everything to the top tier makes the top tier meaningless for the case that genuinely needs it. Reserve it for customer-facing failure and say what the impact is.
The status page not checked first
If a component is already reported degraded, a ticket adds queue rather than information. Subscribe, check, then report what your logs show that the incident note does not.
Sandbox versus production
Sandbox questions are still support questions
An integration blocked in sandbox is a build blocked, and it is handled on the business-day path. Reproducing an issue in sandbox before reporting it also gives support something safe to poke at.
A sandbox reproduction speeds up a production ticket
If the same request fails the same way with a test card, the investigation stops needing your live traffic and can proceed without touching a real cardholder.
Request ids exist in both environments
They are scoped per environment, so say which one a given id came from. An id looked up against the wrong environment returns nothing and reads as a bad report.
Questions about Developer Support
How do I get help with a RapidCents integration?
Use the developer support channel with the request id from the failing call. That id lets support trace the exact attempt rather than reproducing from a description.
What information should I include in a report?
Request id, environment, API and SDK version, the error code, and the expected versus observed behaviour on a single example.
Is there a service level for production issues?
Yes, tiered by severity, with production-impacting incidents on the shortest response commitment.
What if I did not log the request id?
Send the closest identifiers you do have — your own transaction reference, the exact timestamp with timezone, the amount and the last four digits — and log the request id going forward. It narrows the search but does not replace it.
Can support see my card data?
No, and neither should you. Card numbers live in the vault behind a token, and no support conversation should ever contain a full card number. Send the token reference or the last four digits instead.
Who do I contact about pricing, funding or an account hold?
Your account team, not developer support. Those outcomes are account decisions rather than API behaviour, and routing them here adds a hop without adding an answer.
Should I report something that is only wrong in the documentation?
Yes. A reference page that disagrees with the live interface is a defect worth fixing, and it is usually reported by the person who lost an afternoon to it rather than found by anyone else.
Do sandbox problems get support, or only production ones?
Sandbox issues are handled, on the business-day path, because an integration blocked in sandbox is a build blocked. Reproducing a production problem in sandbox first also helps: if the same request fails the same way with a test card, the investigation no longer needs your live traffic or a real cardholder.
How many failing requests should I include in one ticket?
A few from the same window beat one example or a long list. Three request ids that returned the same error code within about fifteen minutes turn a research project into a lookup, and they show whether the failure is a single edge case or a pattern. Say which environment each id came from, since ids are scoped per environment.
Continue the integration
RapidCents platform status and incident history on a workstation, so an integrator can see whether the rails are up. System Status
Real-time platform status, incident history and subscribe-to-updates.
Explore
RapidCents developer docs open on a workstation: API reference, a copy-ready example, and a terminal for the in-person path. Documentation
Complete developer documentation for RapidCents payment APIs, webhooks, terminals and sandbox…
Explore
A 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.
ExploreA RapidCents sandbox merchant account running test payments, isolated from production, with a sandbox terminal on the desk. Sandbox
Request sandbox access with test merchant IDs and isolated environment.
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
