Developer Terms

These Developer Terms govern how a RapidCents integration is built and run: how API credentials are issued and where each one may live, what the sandbox is for and what it must never contain, how the APIs may be used and what happens when a limit is exceeded, how webhooks are verified and handled idempotently, how versions are deprecated, who owns what, and the PCI DSS scope your integration decides. They form part of the RapidCents Services Agreement and bind both the merchant and anyone building for it. Where the Services Agreement already states a rule, these terms cite it by clause letter and number so you can read the operative text for yourself.

Section A — Scope and application

1. Who these Developer Terms bind

These terms cover anyone who touches your RapidCents integration — your own developers, a contractor, an agency, or a software vendor building for you. Whoever writes the code, the merchant whose account it runs on is the one RapidCents holds responsible.

These Developer Terms govern access to and use of the RapidCents APIs, SDKs, Rapid.js, RapidBridge, webhooks, plugins, the sandbox and the developer documentation (together, the “Developer Services”). They form part of the RapidCents Services Agreement and are incorporated into it. The defined terms of the Services Agreement apply here with the same meanings, including “Services”, “Secondary User”, “Cardholder Data”, “Network Rules”, “Customer” and “Transaction”.

They bind two parties, and it is worth being precise about which is which. The first is the Merchant: the business approved for a RapidCents Account, on whose credentials the integration runs. The second is any person who builds, operates, maintains or holds access to that integration on the Merchant’s behalf — an employee, a contractor, an agency, a systems integrator, a software vendor or a consultant. The Services Agreement calls that second party a Secondary User and defines it to include any third party to whom the Merchant grants credentials or API access.

The consequence is stated in the Services Agreement rather than invented here. The definition of Secondary User makes the Merchant responsible for everything a Secondary User does under the account as though the Merchant had done it itself, and clause B.1 (at 1.2) makes the Merchant fully responsible for all activity occurring under its account. A developer who exposes a key, ignores a limit or submits a Transaction the account is not approved for creates a breach by the Merchant. RapidCents does not adjudicate between a merchant and its developer, and nothing in these terms creates a contract between RapidCents and a developer who is not itself a Merchant.

If you are a developer reading this without a RapidCents Account of your own, read it as the standard your client is contractually required to hold you to. If you are a Merchant, read clause 6 before you give anyone credentials.

2. How these terms fit the Services Agreement

If these terms and your merchant agreement ever disagree, the merchant agreement wins. These terms add detail; they do not replace anything.

These Developer Terms are supplemental. They restate obligations the Services Agreement already imposes and add the operational detail an integration needs, in the place a developer will look for it. They do not vary the Services Agreement, do not narrow it, and do not create rights it does not give.

Where these terms and the Services Agreement can be read together, both apply. Where they conflict, the Services Agreement prevails. A citation in these terms to a clause letter and number — B.3, D.2, E.1 — is a citation to that clause of the Services Agreement published at /legal/terms.

The Acceptable Use Policy, the Privacy Policy, the PCI Compliance page and the Security page also apply to an integration. Clause B.5 incorporates the Acceptable Use Policy into the Services Agreement by reference, and clause D.1 (at 1.4) does the same for the Privacy Policy. Nothing in these terms displaces either.

The API reference and the developer documentation describe how the platform behaves; they are not part of the Services Agreement. Where documentation and an operative clause read differently, the clause governs the parties’ obligations and the reference governs the technical contract — a field name, a type, an enumerated value, a limit.

Section B — API credentials

3. The credentials RapidCents issues, and what each one can do

There are different kinds of key and they are not interchangeable. A publishable key is safe in a browser because it cannot move money. A secret key can refund, so it belongs on a server and nowhere else.

RapidCents issues credentials that differ by role and by environment. The split is the design: what a credential can do decides where it may safely live, and a credential that can move money is never permitted anywhere a user, a browser or a decompiler can read it.

Credentials are issued to the Merchant, against the Merchant’s RapidCents Account. They are not issued to a developer in the developer’s own right, they are not transferable between merchants, and a developer working for more than one merchant must use each merchant’s own credentials for that merchant’s traffic rather than routing several businesses through one set. Submitting another business’s Transactions through your credentials is prohibited by clause B.4(g) and by clause H.9 however the code is arranged.

Sandbox and production credentials are issued separately, and neither authenticates against the other environment. That is a property to rely on rather than a limitation to work around: an environment mix-up fails immediately instead of succeeding somewhere unintended.

Request signing is available in addition to the credential for server-to-server integrations that need tamper evidence beyond TLS, and is recommended for high-value flows. It is not a substitute for keeping the secret key secret.

Credentials issued by RapidCents

Credential	Where it belongs	What it can do
Secret API key	Server-side only, loaded from a secret manager at runtime	Creates, captures, refunds and reads — full account capability within its environment
Publishable key	Browser and mobile client code	Initialises Rapid.js and exchanges card data for a token; cannot move money
Webhook signing secret	Server-side only, in the endpoint that receives events	Proves that an inbound event was sent by RapidCents
OAuth grant	Held by a platform acting for a connected business	Acts for that business without the platform holding its keys; revocable by the business

Each of these is scoped to a single environment. A sandbox credential does not authenticate against production, and a production credential does not authenticate against the sandbox. Whether a narrower, read-only restriction can be applied to a key is confirmed by the API reference and by your RapidCents account contact.

4. A secret key must never reach client-side code

Never put a secret key in a web page, an app bundle, a mobile binary, a repository or a support ticket. If one gets out, treat it as compromised and rotate it before you investigate.

This is the one obligation in these terms that admits no exception, no staging carve-out and no temporary arrangement. A secret API key must not appear in client-side code, or anywhere a person other than the Merchant’s authorised personnel can read it. Clause B.1 (at 1.2) of the Services Agreement makes the Merchant responsible for maintaining the confidentiality and security of its account credentials including API keys, and clause B.3 makes the Merchant responsible for the security of its API keys specifically.

In practice the prohibition covers all of the following, and the list is illustrative rather than exhaustive:

• JavaScript served to a browser, including a bundle, a source map, an inline script and a configuration object rendered into the page.
• A mobile application binary, a compiled asset, or anything else shipped to a device, whether or not it is obfuscated.
• A public or shared source repository, a commit history, an issue, a pull request or a continuous-integration log.
• A support ticket, an email, a chat message, a screenshot, a screen recording, or a document shared with a third party — including one shared with RapidCents.
• A client-side environment variable, a configuration file served to the client, or any request the browser makes that carries the key as a parameter or a header.

Where card entry has to happen in a browser or an app, use Rapid.js with the publishable key, or hosted checkout, which moves card entry onto a RapidCents-hosted page altogether. A publishable key can only exchange card data for a token; it cannot create, capture or refund a payment, which is what makes it safe to ship. Your server then creates the payment from that token using the secret key, which never leaves your infrastructure.

Obfuscation is not a control. Neither is a key held in a client-side variable, restricted by referrer, or embedded in an application intended only for internal use. If a secret key can be extracted from something you distribute, it is exposed, and it can issue refunds.

A secret key that has appeared in any of these places is compromised whether or not you can show it was used. Rotate first and investigate second: issue a new key, deploy it, confirm from your request logs that the old key identifier has stopped appearing, then revoke the old key. Clause 5 sets out the rest, and clause 21 covers reporting it.

5. Storage, rotation and revocation

Keep keys in a secret manager, use different keys for each environment and each system, change them on a schedule and whenever someone with access leaves, and keep both keys live briefly so nothing fails mid-rotation.

Clause D.2 (at 2.2) of the Services Agreement requires the Merchant to implement and maintain reasonable security measures appropriate to the information being protected, including strong unique passwords, multi-factor authentication where available, patching, firewalls, encryption and access controls, regular assessment and vulnerability scanning, staff training, and an incident response plan. Applied to API credentials, that means the following.

• Load credentials from a secret manager at runtime. Keep only placeholder values in committed configuration, and run a secret scan before a commit reaches a repository.
• Use separate credentials for each environment, so that sandbox traffic cannot reach production and a production key cannot be deployed to a staging environment by accident.
• Refuse to start the application when the credential does not match the environment it expects. That turns a live outage into a failed deployment.
• Issue separate credentials to separate systems and separate people wherever the platform allows it, so that a rotation or a leak affects one consumer rather than every consumer at once. Continuous integration should hold its own.
• Log which credential identifier served each request, so that a leak can be traced to a system rather than guessed at.
• Rotate on a fixed schedule, and immediately when an employee, a contractor or an agency with access to a credential leaves or the engagement ends.

Rotate with overlap. Revoking the old credential at the instant the new one is issued fails every request still in flight: issue the new credential, deploy it, watch the old identifier disappear from your logs, then revoke. Rehearsing the whole sequence in the sandbox proves the mechanism before the day it has to be done under pressure on production.

RapidCents may revoke or reissue a credential where it is compromised, where it is being used in breach of these terms or the Services Agreement, or where clause B.5 permits suspension. Clause 11 deals with that.

RapidCents will not ask you for a secret key, a password or a one-time code, and no RapidCents document, email or support conversation ever requires you to send one. Treat a request that does as fraudulent, and report it using clause 21.

6. Developers, agencies and platforms acting for a merchant

If you hire someone to build your integration, give them their own credentials and take them away when the work ends. If you are a platform taking payments for other businesses, that needs OAuth and written approval — you cannot run their sales through your own account.

A Merchant that engages a developer, an agency or a software vendor is granting access to a Secondary User. The Services Agreement makes the Merchant responsible for what that person does under the account as though the Merchant had done it itself, and clause B.1 (at 1.2) makes the Merchant responsible for all activity occurring under the account.

Two arrangements are commonly confused, and they are governed differently.

• A developer who builds or operates an integration for one Merchant, on that Merchant’s account, using that Merchant’s credentials. This is a Secondary User arrangement. It is permitted, and the obligations in these terms attach to the Merchant.
• A platform, a marketplace or a service provider that submits, settles or receives funds for Transactions belonging to other businesses. This is not a Secondary User arrangement and it is not permitted on an ordinary account. Clause B.4(g) prohibits using the Services to process Transactions for any third party or to act as a payment intermediary or aggregator, and clause H.9 states that in operative detail: a marketplace, sub-merchants, sub-accounts, split settlement or on-behalf-of payouts require RapidCents’ prior written approval, given expressly and not by conduct.

Where a platform is approved to act for connected businesses, OAuth is the mechanism: the platform acts for a business on that business’s own authorization, without ever holding that business’s keys, and the business can revoke the grant without rotating anything of its own. When a grant is revoked, calls made for that business fail authorization while the platform’s own credentials remain valid; handle that as a state change in your platform rather than as a platform-wide incident.

When an engagement ends, remove the access it required. Rotate any credential the departing party could read, revoke their dashboard access, and remove their systems from any allowlist. Clause D.2 (at 2.2) requires access controls; an agency that still holds a working production key eighteen months after handover is a failure of that control, and it remains the Merchant’s failure.

Nothing in these terms makes RapidCents a party to the contract between a Merchant and its developer. RapidCents gives no warranty, and accepts no liability, in respect of work performed by a developer the Merchant engages.

Section C — Environments

7. The sandbox, and what it is not for

The sandbox is a full copy of the interface with fake money. Build in it, break it, test declines and refunds in it. Never put a real card number in it, and never use it as a load test.

The sandbox is an isolated environment with its own credentials, test merchant identifiers, simulated card networks and accelerated settlement. Nothing in it touches production data or real money. It is not a reduced mock: the endpoints, request bodies, error codes and webhook payloads are the ones production serves, and it is versioned the same way, which is what makes work done there transfer rather than have to be redone.

Sandbox access is issued during evaluation, without a signed merchant agreement, and it remains available after go-live so that releases can keep being tested against it. Use of the sandbox is use of the Services and is governed by the Services Agreement and by these terms.

The sandbox must not be used with real card data. Card numbers, expiry dates, security codes, cardholder names and any other real Cardholder Data must never be submitted to a sandbox endpoint, entered into a sandbox form, or included in a test fixture. Test with the documented test cards, which are what make an outcome deterministic and repeatable. This is not a stylistic preference: a real primary account number sent to a test environment is a disclosure of Cardholder Data outside the flow it was authorised for, and it draws the systems that handled it into PCI DSS scope.

Nor may the sandbox be used with any other person’s real data. Do not use a live cardholder’s details, another merchant’s account, another party’s personal information or production customer records in the course of testing, and do not use techniques that degrade the environment for others.

Four differences from production are deliberate, and they are where go-live surprises come from:

• Fees, funding timing and underwriting outcomes shown in the sandbox are illustrative. Your live rate and deposit schedule come from your account, not from a sandbox response, and no sandbox output is a quote.
• Settlement is compressed so that a full capture-to-deposit cycle can be exercised in one sitting. On production, funding follows the payout schedule on your account, and a job built on the sandbox rhythm will sit idle.
• The sandbox is a correctness environment, not a capacity one. Numbers observed there say nothing about production throughput, and load testing against it mostly produces throttling responses. Clause 10 applies to it.
• Tokens, customer records and payments do not cross environments. A card vaulted in the sandbox has no production counterpart, and anything you need on production has to be created there.

How long sandbox data is retained, and whether a dormant sandbox account is reclaimed, is an operational matter rather than a term of this document. Ask developer support if a test dataset needs to persist.

8. Going live

Four things change at cutover: the secret key, the publishable key, the webhook signing secret and the endpoint events go to. Change all four together — a partial swap fails in a way that looks like something else.

Production access requires an approved RapidCents Account. Sandbox credentials do not confer it, and a sandbox integration that works perfectly is not an approved merchant account.

At cutover, treat the following as a single change set: the secret key, the publishable key, the webhook signing secret and the webhook endpoint the events are delivered to. A partial swap is the most common go-live failure and it presents misleadingly — a handler that verified every sandbox event correctly rejects every live event when the signing secret was not replaced, and because a rejection looks like a forged request, it is frequently misdiagnosed as an attack.

Before the switch, exercise the paths that are hard to reproduce afterwards: an approval, a decline, a refund, a 3-D Secure challenge, and at least one replayed webhook confirming that your handler writes once rather than twice. Then switch keys, place one small live payment, refund it, and watch the first batch settle.

Going live does not end sandbox access, and it does not end these terms. Everything in this document applies to a production integration in the same way it applied to the one built in the sandbox.

Section D — Acceptable use of the APIs

9. Acceptable use of the APIs

Use the APIs the way the documentation says, for your own business, within the law and the card network rules. Do not take the platform apart, resell access to it, or try to get around its risk controls.

Clause B.3 of the Services Agreement requires the Merchant to comply with the current API documentation and usage guidelines when it uses the RapidCents APIs. Clause B.2 grants a limited, non-exclusive, non-transferable, non-sublicensable, revocable licence to access and use the Services solely for the Merchant’s internal business purposes. Clause B.4 sets out what the Merchant agrees not to do and not to allow a third party to do. Those restrictions apply to an integration exactly as they apply to the dashboard, and they are restated here because a developer is the person in a position to breach them:

• Do not use the Developer Services for any illegal, fraudulent or unauthorized purpose, or for anything prohibited by the Acceptable Use Policy.
• Do not use them in a manner that violates any applicable law, regulation or Network Rule.
• Do not copy, modify, reverse engineer, decompile or disassemble any part of the Services or the RapidCents Software, including the SDKs, Rapid.js, RapidBridge and the plugins.
• Do not rent, lease, sell, distribute or sublicense the Services or the RapidCents Software, and do not resell or expose API access to third parties as a service of your own.
• Do not interfere with or disrupt the integrity or performance of the Services or the data contained in them.
• Do not attempt to gain unauthorized access to the Services or to related systems or networks, including another merchant’s account or another merchant’s data.
• Do not use the Services to process Transactions for any third party, or act as a payment intermediary or aggregator, except as clause H.9 permits with prior written approval.
• Do not transmit worms, viruses, malware or any code of a destructive nature.

Two further prohibitions follow from the Acceptable Use Policy and are worth naming in an integration context. Do not evade, disable or interfere with RapidCents’ risk, fraud, verification or compliance controls, and do not misrepresent a Transaction’s nature, amount, currency, country or Customer in order to obtain an authorization. And do not open or operate a second account, or an account in the name of another person or entity, in order to evade a limit, a Reserve, a suspension or a termination.

Polling is not prohibited, but it is the wrong design and it is charged against the same limits as everything else. Repeatedly reading a payment to see whether anything has changed is slower than the webhook, heavier on your limits, and still misses a refund or a dispute raised outside your application. Clause 12 sets out the alternative.

10. Rate limits

There are limits on how fast you can call the API. Going over one gets you a documented error with a retry hint, not a dropped request. Back off when you see it; do not hammer.

Clause B.3 of the Services Agreement provides that RapidCents may set limits on API usage, expressed for example as a number of requests per second. Limits are applied per account, and they apply in the sandbox as well as in production.

This document does not publish the numeric limits, because they are a property of the interface rather than a term of the contract and they belong where an integration can act on them: the limits that apply to your account, and the way a response signals that one has been reached, are documented in the API reference. Where your integration has a legitimate need that exceeds them — a bulk reconciliation job, a migration, a seasonal peak — raise it with developer support in advance rather than discovering the limit in production.

Exceeding a limit returns a documented status code with a retry hint rather than dropping the request silently. Treat that response as a signal and not as an outage: back off on the hint, retry with jitter, and carry an idempotency key so that a request which did in fact succeed is not applied twice. Continuing to send at the same rate is what turns throttling into an incident.

Persistent disregard of a limit — a client that retries immediately and indefinitely, a load test run against production, or traffic that in RapidCents’ judgment imminently threatens the security, integrity or availability of the Services — is a ground for immediate suspension under clause B.5 of the Services Agreement. Clause 11 sets out what that means in practice.

11. Suspension and withdrawal of credentials

RapidCents can switch off your API access without warning if the integration threatens the platform or breaks the rules, and it can hold funds while it investigates. Losing API access costs you no cancellation fee — RapidCents does not charge one.

Clause B.5 of the Services Agreement permits RapidCents to suspend use of the Services immediately and without prior notice where the Merchant or a Secondary User intentionally violates the Acceptable Use Policy, or uses the Services in breach of the Agreement in a way that, in RapidCents’ judgment, imminently threatens the security, integrity or availability of the Services. It also lists the grounds on which access may be suspended or terminated without notice, including breach of the Agreement or the Acceptable Use Policy, suspected fraudulent, illegal or unauthorized use, activity that poses a security risk, failure to cooperate with an investigation or to provide requested information, and chargeback, return or complaint levels above the applicable thresholds.

Applied to an integration, suspension may take the form of revoking or disabling a credential rather than closing an account. RapidCents may revoke, disable or reissue a credential, restrict it to a narrower capability, or block traffic from a particular integration, where any of the grounds in clause B.5 applies or where a credential is compromised.

During a suspension, RapidCents may hold funds in the RapidCents Account or in a Reserve until an investigation or dispute is resolved, as clause B.5 provides. That clause also records the Merchant’s waiver of claims against RapidCents for losses resulting from action taken for integrity or security reasons.

Suspension is not termination, and neither carries a penalty. RapidCents charges no cancellation fee and no early-termination fee. Clause F.1 (at 1.2) lets the Merchant terminate at any time on written notice and records that RapidCents charges no early-termination fee and imposes no penalty for closing an account before the end of a term, and clause A.4 states the same plainly. Clause A.3 adds a further right to cancel without penalty in the specific circumstances it lists — a new fee, an increase to an existing fee outside a schedule the Agreement already names, a failure to pass through an interchange cost reduction, or a unilaterally imposed material adverse change — exercisable on written notice within ninety (90) days. Where access is restored, it is restored to the same account on the same terms.

Termination of the Services Agreement revokes the licence to use the RapidCents Software, as clause A.7 provides, and with it the licence in clause 18 of these terms. Obligations intended by their nature to survive termination — including those relating to intellectual property, confidentiality, liability, and cooperation and record-keeping following a compromise — survive it here as well.

Section E — Webhooks

12. Webhook delivery and signature verification

Webhooks tell you what happened after your request returned. Check the signature against the raw body before you trust the event, and answer with a 2xx quickly.

Webhooks deliver payment lifecycle events to an endpoint the Merchant operates: authorization, capture, refund, dispute opened and settlement funded, among others. They exist because most of what happens to a payment happens after the original request has returned — a refund issued from the dashboard, a chargeback filed weeks later, a deposit funded overnight — and none of it reaches an integration that reads only synchronous responses.

Every payload is signed with an HMAC computed over the exact bytes sent. Verifying that signature is the Merchant’s obligation, not an optional hardening step. An unverified webhook endpoint is an unauthenticated instruction to change the state of an order, release goods or credit an account, reachable by anyone who learns the address.

• Capture the raw request body before any middleware parses it. Framework middleware that parses JSON and hands you an object has already changed the bytes, and the HMAC will not match; the symptom is a valid event rejected as forged.
• Compute the HMAC over that raw body using the signing secret for the environment the event came from, and compare it against the signature header in constant time.
• Reject anything that does not match, and do not fall back to processing it. A failed verification is not a formatting problem.
• Hold the signing secret to the same standard as a secret key: server-side, in a secret manager, never in client code, and rotated on the discipline clause 5 requires.
• Register the endpoint over HTTPS at a routable address with a valid certificate. More than one endpoint may be registered, which is the cleaner arrangement when different systems care about different events — an order service consuming payment events and a finance job consuming settlement events do not need to share a handler.

The exact header, the algorithm and the encoding used for the signature are documented in the API reference, which is the authoritative technical contract for them.

Sandbox and production sign with different secrets. A handler that verified correctly throughout development will reject every live event if the secret was not replaced at cutover; clause 8 treats the two as part of one change set for exactly that reason.

13. At-least-once delivery, ordering and idempotent handling

The same event can arrive more than once and out of order. Say 2xx first, do the work afterwards, and make the work safe to repeat.

Webhook delivery is at least once. The same event can be delivered more than once, and a later event can arrive before an earlier one. Both are properties of the delivery model rather than defects, and an integration that assumes exactly-once, in-order delivery will double-fulfil an order sooner or later. Handling them is the Merchant’s obligation.

• Deduplicate on the event identifier. Record the identifiers you have processed, and make a second delivery of the same event a no-op.
• Acknowledge with a 2xx status first and do the slow work afterwards. Anything outside 2xx is read as a failure and schedules a redelivery, so a slow database write inside the handler produces duplicate deliveries rather than a slow success.
• Trust the state carried in the payload rather than the arrival order, and ignore an event that would move a resource backwards.
• Use an idempotency key on any API call that changes state, including one your handler makes in response to an event, so that a retried call cannot be applied twice.
• Alert on repeated non-2xx responses from your own endpoint. Deliveries do not fail loudly on the receiving side; each attempt and its outcome is recorded against the event, and an endpoint that has silently stopped working is otherwise found by a customer.

Where an endpoint does not acknowledge, delivery is retried on a backoff schedule and then stops. The number of attempts and the period over which they are made are documented in the API reference rather than fixed by this document. An event that was never acknowledged is not lost: events remain queryable through the API, so recovery after an extended outage is a backfill rather than a support request.

The webhook, and not the synchronous response, is what should drive the state of an order. The response reports what happened at that instant; the webhook reports everything after it, and it is the only channel that carries a refund or a dispute originating outside your application.

Section F — Versions and change

14. API versioning and deprecation

Pin your version. Breaking behaviour ships behind a new version, so nothing changes under you until you move. When something is being retired, you get notice and a window, published in the changelog.

The RapidCents API is versioned, and a version is pinned per account and may be sent explicitly on a request. Additive changes reach a pinned integration without action, because the pinned version keeps behaving as documented. Breaking changes ship behind a new version and remain optional until the Merchant moves to it.

RapidCents may deprecate an API version, an endpoint, an event type, a field or an SDK release. Where it does, notice is published in the developer changelog. The entry states what is changing, which API version carries it, whether the change is additive or breaking and, for a deprecation, the date on which the old behaviour stops. The old behaviour continues to be served until that date.

The length of the notice period is set for each deprecation and stated in its changelog entry rather than fixed in this document, because the appropriate window differs between retiring an optional field and retiring a version. RapidCents’ commitment is that a breaking change is announced with a migration window before the old behaviour stops, and that the window and its end date are published rather than communicated only on request. Where a change has to be made without the usual notice — because a Network Rule, a regulator or a security defect requires it — RapidCents will say so in the notice and give as much time as the circumstance allows.

The obligations on the Merchant’s side are ordinary engineering hygiene, and they are the Merchant’s to meet: pin the API version explicitly rather than tracking the latest; record which version each service sends, so that a migration is a known set of deployments rather than a discovery; route changelog notices somewhere the on-call rotation can see them, because a subscription pointed at an unmonitored inbox is the same as no subscription; and test the new version in the sandbox during the window rather than at the end of it.

An SDK release targets a specific API version, so upgrading a package can move an integration across a version boundary without any change to your own code. Pin the package and pin the API version separately.

Clause F.2 of the Services Agreement governs amendments to the Agreement itself, which is a different thing from a change to the API. Clause 22 of these terms deals with changes to this document.

15. SDKs, plugins and third-party integrations

The official SDKs and plugins are supported software. A fork is not — it stops receiving fixes, including security ones. Anything you connect from a third party is your risk, not ours.

RapidCents publishes official SDKs for Node.js, Python, PHP and mobile; plugins and extensions for common commerce platforms, including a WooCommerce plugin for WordPress stores and a connection for a Shopify storefront; Rapid.js for embedded card fields; and RapidBridge for bringing payments into business software that cannot be modified. Each SDK release documents the API version it targets. Which platforms are covered by a prebuilt plugin, and which are covered instead by hosted checkout sessions or payment links, is confirmed by your RapidCents integration contact rather than listed here, because that set changes.

Keep them on supported versions. The Security page states the same obligation in general terms: an integration, a plugin, point-of-sale software or a terminal left on a version that has stopped receiving fixes is one of the ordinary ways a merchant-side incident begins. Confirm plugin compatibility before a major platform upgrade rather than after checkout stops working.

Do not fork a plugin or an SDK to add a feature. A modified copy stops receiving updates, including security updates, and inherits every future incompatibility; where the requirement is real, build it on Rapid.js or the APIs instead. Clause B.4 prohibits copying, modifying, reverse engineering and redistributing the RapidCents Software in any event, and clause 18 sets out what the licence does and does not permit.

Third-party services, applications and content are governed by clause B.6 of the Services Agreement. RapidCents does not endorse or control them, makes no representation or warranty about their functionality, security or reliability, may discontinue support for any of them at any time without notice, and accepts no liability for loss arising from their use. Evaluating, selecting and implementing a third-party integration is the Merchant’s responsibility, as is complying with that provider’s own terms, and the availability of a third-party service through RapidCents implies no business relationship between RapidCents and its provider.

The licence terms under which an official SDK or plugin is distributed accompany the package. Where a package carries its own licence file, that licence governs the code in it, in addition to these terms and the Services Agreement.

16. Beta features and automated features

Anything labelled beta or preview can break, change or disappear, with no warranty. Anything that uses AI, including APPIE, can be wrong — read the output before you act on it.

Clause H.7 of the Services Agreement governs beta and pre-release functionality and features that use artificial intelligence or other automated processing. Both classes reach a developer earlier than they reach anyone else, so the terms are restated here.

A feature RapidCents identifies as beta, preview, pilot, early access, limited release or experimental is provided as is and as available, without warranty of any kind. RapidCents does not undertake that it will function as described, be supported, be compatible with any later version, preserve data entered into it, or ever become a generally available part of the Services, and may modify, restrict, suspend or withdraw it at any time, with or without notice and without providing a replacement. Where RapidCents publishes terms specific to a beta feature, those terms apply in addition to these and prevail over them in respect of that feature. The Merchant uses it at its own risk and remains responsible for every Transaction processed through it.

A feature that uses artificial intelligence, machine learning, large language models, statistical models or other automated processing — including features made available under the APPIE name — produces output by inference rather than by verification. Output may be incomplete, inaccurate, out of date, internally inconsistent, or wrong in a way that is not apparent on its face, and the same input may not produce the same output twice. The Merchant is responsible for reviewing that output before relying on it, acting on it, sending it to a Customer, entering it in a record, or using it to satisfy a legal, tax, accounting, reporting or Network Rules obligation, and will not use it as the sole basis for a decision producing a legal or similarly significant effect on an individual without human review of that decision.

No output of an automated feature, and no content generated by the Services, is legal, tax, accounting, financial, investment or compliance advice, is a representation by RapidCents that a Transaction is lawful, genuine, authorized or collectible, or creates any obligation, service level, response time or guarantee on RapidCents’ part. Do not use a beta feature or an automated feature to develop, train or improve a competing product or model, and do not represent its output to a Customer or a third party as having been verified, endorsed or warranted by RapidCents.

Section G — Intellectual property

17. Ownership: the platform, your code and your data

RapidCents owns the platform, the APIs, the SDKs and the documentation. You own your own code, your content and your data. Integrating does not move either side’s property to the other.

Clause E.1 of the Services Agreement allocates ownership, and building an integration does not move the line.

RapidCents owns all right, title and interest in and to the Services, the RapidCents Software, the APIs, the documentation, the RapidCents trademarks and logos, and all related intellectual property rights. These terms grant no rights in any of that beyond the limited licence in clause 18, and rights not expressly granted are reserved, as clause A.7 provides.

The Merchant retains ownership of the content, data and information it provides or uploads to the Services, which the Services Agreement calls Merchant Content, and grants RapidCents a worldwide, royalty-free, non-exclusive licence to use, reproduce, modify, adapt and display it solely to the extent necessary to provide the Services. RapidCents claims no ownership of the Merchant’s application, its source code, its business logic, its customer records or the products it sells.

Where the Merchant provides suggestions, ideas, improvements or other feedback about the Services, clause E.1 (at 1.3) gives RapidCents a worldwide, perpetual, irrevocable, royalty-free licence to use, modify and incorporate that feedback into the Services without obligation. Reporting a bug or asking for a feature is feedback; it does not transfer the Merchant’s own code.

Customer Data is a separate question. Clause D.1 makes the Merchant the data controller for personal information relating to its Customers and RapidCents a processor acting on the Merchant’s documented instructions, and incorporates the RapidCents Privacy Policy into the Services Agreement. Who owns data and who is accountable for it are not the same question, and it is clause D.1, not clause E.1, that answers the second.

Use of the RapidCents name, marks and logos in an integration is governed by the trademark notice published at /legal/trademark rather than by the licence in clause 18, which grants no rights in them. That notice permits some uses without asking — stating truthfully on your site, in your application, on your receipts and at your point of sale that payments are processed by RapidCents, and displaying the RapidCents logo for that purpose in the manner it prescribes. Others need RapidCents’ prior written permission first, including combining a mark with your own name or logo into a single badge, seal or lockup, and any use that reads as co-branding or as an endorsement. Read that notice before you ship a mark, not after.

18. The licence to use the SDKs, Rapid.js and the documentation

You get a limited licence to use the SDKs and developer tools to build your own integration with RapidCents, for as long as your account is open and in good standing. You cannot resell it, sublicense it, or take it apart.

Clause B.2 of the Services Agreement grants a limited, non-exclusive, non-transferable, non-sublicensable, revocable licence to access and use the Services solely for the Merchant’s internal business purposes, subject to compliance with the Agreement. Clause A.7 grants the corresponding licence for RapidCents Software and records that it lasts only for as long as the RapidCents Account remains active and in good standing, that no ownership rights in the software are acquired, and that unauthorized copying, modification, distribution, reverse engineering or sublicensing is prohibited.

For the avoidance of doubt, within that licence the Merchant and its Secondary Users may:

• Install, configure and run the official SDKs, Rapid.js, RapidBridge and the RapidCents plugins in order to connect the Merchant’s own systems to the Services.
• Copy and adapt the code samples in the documentation into the Merchant’s own application.
• Deploy the resulting integration in the Merchant’s own environments, including development, staging, continuous integration and production.
• Give a developer engaged by the Merchant the access needed to do that work, on the terms set out in clause 6.

The licence does not permit renting, leasing, selling, distributing or sublicensing the RapidCents Software; exposing API access to third parties as a service of your own; copying, modifying, reverse engineering, decompiling or disassembling any part of it; removing or altering a notice in it; or using it other than in connection with the Merchant’s own RapidCents Account. Clause B.4 states those prohibitions, and nothing here narrows them.

The licence ends when the Services Agreement is terminated, as clause A.7 provides. Provisions intended by their nature to survive termination — including those on intellectual property, confidentiality and liability — survive it.

The Services, the RapidCents Software and every beta and automated feature are provided subject to the disclaimer of warranties at clause E.4 and the limitation of liability at clause E.5. Nothing in these terms adds a warranty, a service level, an uptime commitment or an availability guarantee that the Services Agreement does not give.

Section H — Card data and security

19. PCI DSS scope, and how your integration decides which SAQ applies

How you take the card decides how much of PCI DSS you have to answer for. If the card goes straight from the customer’s browser to RapidCents, your questionnaire is the short one. If it passes through your server, it is the long one.

RapidCents validates annually as a PCI DSS Level 1 service provider, and that validation covers the RapidCents environment. It does not cover the Merchant’s systems and it does not discharge the Merchant’s own obligations. Clause D.2 (at 2.1) of the Services Agreement requires the Merchant to maintain PCI DSS compliance for its own systems, processes and personnel, to complete the validation documentation applicable to its merchant level, to remediate compliance issues promptly, and to notify RapidCents immediately of any suspected or confirmed breach of Cardholder Data.

Which self-assessment questionnaire the Merchant completes is decided by how it actually accepts payments — which is to say, by decisions made in the integration. The mapping below covers the common RapidCents configurations as a guide. Your own payment flow decides your SAQ, and your acquirer, or a qualified security assessor where one is involved, confirms it. This table reproduces the mapping published on the PCI Compliance page and does not vary it.

The practical consequence for a developer is that a single design decision moves the Merchant between the shortest questionnaire and a full compliance programme. Posting the card to your own backend in order to validate it, logging a request body that contains a primary account number, or accepting a card number through a support form are each enough to do it.

Scope changes quietly. A change made after validation — a new checkout, a call-centre process that keys cards into an order system, a plugin replaced by a custom flow — can change which questionnaire applies without anyone reopening the question. Reassess immediately rather than waiting for the next validation date: a merchant validated on SAQ A while operating an SAQ D flow is not validated at all.

Validation is annual, and it is carried out against the version of the standard then in force. RapidCents’ own Attestation of Compliance evidences the RapidCents environment only and does not answer a reviewer’s question about the Merchant’s environment; it can be requested through your RapidCents account contact or support.

How the integration maps to a self-assessment questionnaire

How card data is taken	Questionnaire	What it turns on
Hosted checkout, payment links, or Rapid.js embedded fields — the card is posted from the customer’s browser directly to RapidCents and never reaches your servers	SAQ A	The third parties you rely on, the policies around them, and confirming that the delegation is real
Card-present acceptance on validated standalone terminals, with no electronic storage of cardholder data on your systems	SAQ B or SAQ B-IP	Device handling, physical control and the connection — SAQ B for a dial-out connection, SAQ B-IP for a standalone terminal over IP
A custom checkout that relays the card through your own server, card numbers keyed into your CRM or order system, or any electronic storage of cardholder data	SAQ D	The full requirement set, together with quarterly external scanning by an approved scanning vendor

Other questionnaires exist for configurations this table does not describe, including SAQ C, SAQ C-VT and SAQ P2PE. If none of these matches your setup, confirm the right one with your acquirer rather than assuming.

20. Data you must never store

Never keep a security code, a PIN, or full chip or stripe data after the payment is authorised. Encrypting it does not make it allowed. If you need a card on file, store a token.

PCI DSS prohibits the storage of sensitive authentication data after authorization. The prohibition is absolute: encryption does not make it permissible, and it applies whether the data sits in a database, a log file, a message queue, a spreadsheet, a scanned form, a call recording or a paper notebook. In an integration, the log file and the message queue are where it usually happens. The following must never be stored after authorization, by anyone, in any form:

• Card verification values — CVV, CVC or CID.
• PINs, and any PIN block, in any form.
• Full magnetic-stripe (track) data after authorization.
• Full EMV chip data after authorization.

Beyond that absolute prohibition, an integration should avoid holding a primary account number at all. Where there is a genuine reason to keep a payment method on file, store a RapidCents token instead. The card is captured on a RapidCents-hosted surface — embedded fields, hosted checkout, a terminal or the virtual terminal — and what your systems hold is a reference only RapidCents can resolve, which cannot be replayed against another processor. Store the token against the customer record it belongs to, keep the brand and last four digits for display only, and build the path that retires a token when a customer removes the method, because that is the path integrations most often omit.

Keeping the card number as well as the token, even briefly, even encrypted, puts the credential back in your environment and removes the reason for tokenizing at all.

Do not write Cardholder Data into an error message, a stack trace, an analytics event, a crash report, a bug tracker, a support ticket or a message to RapidCents, and do not send card numbers, or files containing them, by email or chat — including while investigating an incident. RapidCents applies the same prohibition to itself: it does not store CVV, PINs, EMV chip data or magnetic-stripe data, and Cardholder Data it does retain is encrypted with AES using 256-bit keys and held apart from public-facing web servers.

21. Security incidents, credential compromise and vulnerability reports

If card data or your credentials are compromised, tell RapidCents straight away — email security and legal — rotate the keys, and do not wipe the evidence. If you find a weakness in a RapidCents product, report it through the disclosure page and never test with real cards.

Clause D.2 (at 2.3) of the Services Agreement requires the Merchant to notify RapidCents immediately of any suspected, alleged or confirmed compromised data event, regardless of its source and including one affecting any of the Merchant’s third-party service providers, by emailing both [email protected] and [email protected]. The obligation is immediate, and no RapidCents document states an outer limit in hours. Report early: reporting early preserves your options, and reporting late narrows them.

A compromised credential is reportable on the same footing as compromised card data. If a secret key, a webhook signing secret or a dashboard credential has been exposed — in a repository, a bundle, a log, a screenshot or a third party’s systems — rotate it first, then report it, then investigate.

In the first hours, containment matters more than tidiness:

• Preserve evidence. Do not reimage, wipe or rebuild affected systems, and do not delete logs. Clause D.2 (at 2.3) requires the Merchant not to alter or destroy related records and to keep complete and accurate documentation of any modification made to them; a forensic investigation needs exactly what a clean rebuild destroys.
• Contain rather than erase: take the affected system off the network, rotate credentials and API keys, and revoke active sessions.
• Do not send card numbers, or files containing them, by email or chat while investigating.
• Expect that RapidCents may engage a forensic vendor approved by an Association, and cooperate fully with it. Clause D.2 (at 2.3) requires that cooperation, requires the Merchant to share investigation material including forensic reports and systems audits, permits RapidCents and its service providers to share that material with the Associations and to conduct remote electronic scans of the Merchant’s systems on notice, and makes the Merchant responsible for the costs associated with the investigation.
• Consider your own separate obligations. Privacy law may require you to report a breach of security safeguards to a regulator and to the individuals affected, on a timeline of its own — in Canada under PIPEDA, Quebec’s Law 25, or the Alberta and British Columbia personal information protection statutes, and in the United States under the state breach-notification and privacy laws that apply to you. Those obligations run in parallel with the notification to RapidCents, not instead of it.

A vulnerability found in a RapidCents product is a different thing from a compromise of your own environment, and it has its own route: report it through the process described at /legal/vulnerability-disclosure, and report it there before disclosing it anywhere else. In the course of testing, do not use live cardholder data, another party’s account or another merchant’s data, and do not use techniques that degrade the service for others. The sandbox exists so that this kind of testing has somewhere safe to happen.

Where an incident on RapidCents’ side affects a merchant’s data or account, RapidCents notifies the affected merchants without undue delay and states what is known, what is not yet established and what the merchant should do, and makes the notifications to regulators, acquiring banks and the Card Networks that law and the Network Rules require.

Section I — General

22. Support, changes to these terms, and how to reach RapidCents

Send the request id when something breaks — it is the difference between a lookup and a research project. These terms can change the way the rest of the agreement does. Ontario law applies, and disputes go to arbitration.

Developer support is a channel to engineers who can look up a request identifier. What moves a ticket is an identifier: the request id from the failing call, the environment it came from, the API and SDK versions in use, the typed error code, and one concrete example of expected against observed behaviour. A ticket naming three request ids that returned the same code in a fifteen-minute window is a lookup; a ticket reporting that declines went up is a research project. Log the request id alongside your own transaction record, because it exists only on the response you would otherwise discard. Request ids are scoped per environment, so say which environment one came from. Response commitments are tiered by severity, with production incidents on the shortest clock; the tiers that apply to your account are confirmed by your RapidCents account contact rather than stated here.

Check the system status page before reporting a platform-wide symptom. Where a component is already reported degraded, a further ticket adds queue rather than information.

These Developer Terms may be amended in the same way as the rest of the Services Agreement. Clause F.2 provides that RapidCents may amend the Agreement by posting a revised version on the RapidCents website or otherwise giving notice, that the revised version takes effect when posted or as the notice states, and that continued use of the Services after that date is acceptance of it. Material changes to payment terms carry the separate notice and cancellation rights set out in Section A. If you do not agree to an amendment, your remedy is to terminate and stop using the Services — and, as clause 11 records, doing so carries no cancellation fee and no early-termination fee.

Notices to RapidCents under the Services Agreement must be in writing, by email to [email protected] or by mail, return receipt requested, to RapidCents Inc., Attention: Legal Department, 515 Consumers Road, Unit 210, North York, Ontario, M2J 4Z2, Canada, as clause F.3 provides. Notices to the Merchant are given through the RapidCents Dashboard, by email to the address on the account, or by mail. General questions about the Services go to [email protected] or +1-844-957-2743; in the United States, 43300 Southern Walk Plaza, #166, Ashburn, Virginia 20148, or +1-202-902-6226. A suspected compromise goes to the addresses in clause 21, not to general support.

Clause E.7 of the Services Agreement governs the law that applies and how a dispute is resolved: the laws of the Province of Ontario and the federal laws of Canada applicable in it, with any dispute determined by arbitration before a single arbitrator in Toronto, Ontario, administered by the ADR Institute of Canada under its applicable rules, and with either party free to seek provisional remedies from a court in aid of that arbitration. That clause applies to these terms, and clause H.10 provides that proceedings are brought individually.

Governing law

The laws of the Province of Ontario and the federal laws of Canada applicable in it, as clause E.7 of the RapidCents Services Agreement provides. Disputes are determined by arbitration before a single arbitrator in Toronto, Ontario, administered by the ADR Institute of Canada.