PCI Compliance

PCI DSS is the card industry’s security standard, and it applies to every business that stores, processes or transmits cardholder data — including yours. RapidCents is validated as a PCI DSS Level 1 service provider, which covers the RapidCents environment and nothing beyond it. This page sets out what that validation does and does not cover, which self-assessment questionnaire your acceptance method puts you on, and what remains yours to complete each year.

1. What PCI DSS is, and who it binds

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements published by the PCI Security Standards Council and enforced by Visa, Mastercard, Amex, Discover and the other Card Networks through their operating rules. It is a contractual standard rather than a statute, and it reaches your business through your merchant agreement and the rules of the networks whose cards you accept.

It binds every party that stores, processes or transmits cardholder data, and every party whose systems could affect the security of that data. That includes merchants of every size and volume, service providers such as RapidCents, and in practice the software vendors, platforms and integrators that sit anywhere in the payment path.

How much of the standard applies to you depends on how card data flows through your systems. That is a question about your integration, not about your industry, your revenue or how many transactions you run.

2. RapidCents as a Level 1 service provider

RapidCents is a PCI DSS Level 1 service provider, the level that carries the most demanding validation requirements. Maintaining it involves on-site audits, internal and external vulnerability scanning — with external scans performed by Approved Scanning Vendors (ASV) — penetration testing and inspection against the standard.

That validation covers the RapidCents processing environment: the payment gateway, hosted checkout, payment links, Rapid.js, tokenization and the secure card vault, the merchant dashboard and virtual terminal, and the infrastructure behind them. The Security Statement describes the controls operating in that environment.

The practical effect for you is architectural. Because card data is captured on a RapidCents-controlled surface and returned to your systems as a token, most of the standard’s technical requirements have nothing in your environment to attach to. That is what keeps a typical RapidCents merchant on a short questionnaire.

3. Shared responsibility: what our validation does not cover

Our compliance is ours; yours is yours. Using RapidCents can make your validation far shorter. It never removes it.

RapidCents’ Level 1 status is evidence about RapidCents’ systems. It is not, and cannot be, evidence about yours. No service provider’s compliance transfers to a merchant: under the Card Network rules, each merchant validates its own compliance, for its own environment, every year. A provider that tells you its certification makes you compliant is describing something the rules do not permit.

What using RapidCents changes is the size of the job, not whether the job exists. Keeping card data off your systems reduces what has to be assessed; it does not remove the obligation to assess and attest to what remains.

In every configuration, the following stay with you:

Section D of the Services Agreement states the same division in contractual terms — clause D.2 places PCI DSS compliance for your systems, processes and personnel with you — and the Security Statement describes where RapidCents’ own controls stop.

• Who has access to your merchant dashboard, your systems and your terminals, and how that access is granted and removed.
• How your staff handle card numbers taken by phone, by mail order or across a counter.
• The security of the networks, servers, endpoints, point-of-sale devices and terminals you control.
• The versions your integration, plugins and terminal software run, and how promptly they are updated.
• Your internal authorization of refunds and of charges made against stored payment methods.
• Completing your annual self-assessment questionnaire and attestation, and any scanning your SAQ type requires.

4. How you accept payments decides which SAQ you complete

The questionnaire follows your data flow, not your industry. Card data that never touches your servers is what keeps you on the short one.

A self-assessment questionnaire (SAQ) is the validation instrument for merchants not required to undergo a full on-site assessment. Several exist, and the one that applies is determined by how you actually accept payments. 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.

The distance between the shortest questionnaire and the longest is measured in months of work, which is why the data flow is worth designing deliberately rather than discovering during an assessment.

• SAQ A — card handling fully outsourced. Hosted checkout, payment links, or Rapid.js embedded fields where the card is posted from the customer’s browser directly to RapidCents and never reaches your servers. The shortest questionnaire, concerned mostly with the third parties you rely on, the policies around them, and confirming that the delegation is real.
• SAQ B or B-IP — validated standalone terminals. Card-present acceptance on standalone validated terminals with no electronic storage of cardholder data on your systems: SAQ B for terminals on a dial-out connection, SAQ B-IP for standalone terminals connected over IP. A narrow questionnaire about device handling, physical control and the connection.
• SAQ D — your systems store, process or transmit card data. A custom checkout that relays the card through your own server, card numbers typed into your CRM or order system, or any electronic storage of cardholder data. The full requirement set applies, together with quarterly external scanning by an ASV, and at that point compliance is a programme rather than a form.
• Other questionnaires exist for configurations this list does not describe, including SAQ C, SAQ C-VT and SAQ P2PE. If none of the above matches your setup, confirm the right one with your acquirer rather than assuming.

5. What quietly changes your scope

Scope usually grows through ordinary operational decisions rather than through a decision to start handling card data. Each of the following can move a business from a short questionnaire to the long one, often months before anyone notices:

If any of these describes how your business now operates, reassess which SAQ applies immediately rather than waiting for your next validation date. A merchant validated on SAQ A while operating on an SAQ D flow is not validated at all.

• Building a custom checkout that posts the card to your server before it reaches RapidCents.
• Taking card numbers over the phone and typing them into a CRM, an order form or a ticket to be processed later.
• Keeping a card number in a spreadsheet, a shared drive, an email thread, a chat message or a call recording.
• Letting an integration, plugin, point-of-sale application or terminal drift onto an unsupported version.
• Adding a channel — a new storefront, a mobile app, a marketplace, a franchise location — without asking where card data goes in it.

6. Data you must never store

Some data can never be kept after authorization, by anyone, in any form. Encrypting it does not make it allowed.

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 spreadsheet, a scanned form, a call recording or a paper notebook.

Where you have a genuine reason to keep a payment method on file, keep a RapidCents token instead of the card number. A token is a reference only RapidCents can resolve back to the credential, and on its own it cannot be used elsewhere. Holding tokens rather than card numbers is what keeps stored payment methods out of your assessment scope.

RapidCents applies the same prohibition to itself: it does not store CVV, PINs, EMV chip data or magnetic-stripe data. Cardholder data RapidCents does retain is encrypted with AES using 256-bit keys and held apart from public-facing web servers.

• Card verification values — CVV, CVC or CID — the digits printed on the card and used to verify card-not-present transactions.
• PINs, and any PIN block, in any form.
• Full magnetic-stripe (track) data after authorization.
• Full EMV chip data after authorization.

7. The PCI non-compliance fee

Completing your validation is what removes the fee. Paying the fee does not make you compliant.

It is common practice across the payments industry to apply a monthly PCI non-compliance fee to merchants who have not completed and recorded their annual validation. Where a fee of this kind applies to your RapidCents account, it is disclosed in your pricing schedule rather than appearing without notice.

The fee is not a payment for compliance and it does not satisfy the standard. Completing your questionnaire and attestation and recording them against your account is what removes the fee going forward — and, more to the point, is what actually addresses the requirement. A merchant who pays the fee every month and never validates carries the full liability of a non-compliant merchant in a breach.

If you have been charged a non-compliance fee and your validation is current, send RapidCents your attestation so the account record can be corrected.

8. Requesting RapidCents’ Attestation of Compliance

An Attestation of Compliance (AOC) is the document signed at the conclusion of a validation, confirming its outcome and the environment it covered. When a customer, a partner, an insurer, a procurement team or your own security reviewers ask for evidence about the payment environment behind you, the AOC is the document to request.

Ask through your RapidCents account contact or through support, and say who is asking and what they need it for. A vendor-risk questionnaire, a procurement review and a bid response generally call for different levels of detail.

Two limits are worth stating plainly. RapidCents’ AOC evidences the RapidCents environment only, so a reviewer assessing your business will still need your own SAQ and attestation — handing over ours does not answer a question about yours. And an AOC is a point-in-time document tied to a validation period, so check that the copy you pass on is the current one.

9. If you suspect a compromise

If you know or reasonably suspect that card data or credentials associated with your merchant account have been compromised, tell RapidCents immediately, by email to both [email protected] and [email protected]. That is what clause D.2 of the Services Agreement requires, at 2.3, for any suspected, alleged or confirmed compromised data event, regardless of its source and including one affecting your own third-party service providers; the Agreement gives you no grace period and fixes no number of hours. Reporting early is what preserves your options; reporting late narrows them.

What you do in the first hours matters more than what you do in the first week:

To report a vulnerability in a RapidCents product — as distinct from a compromise of your own environment — use the route described at /legal/vulnerability-disclosure.

• Preserve evidence. Do not reimage, wipe or rebuild affected systems, and do not delete logs; a forensic investigator 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 the Card Networks may require an investigation by an approved forensic investigator, and cooperate with it as your merchant agreement requires.
• 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.

10. Annual re-validation

PCI DSS validation is annual. Completing a questionnaire once does not carry forward: you re-attest each year, and you re-attest against the version of the standard then in force, which is revised periodically. If your acceptance method puts you on SAQ D, you also maintain quarterly external scanning by an ASV throughout the year, with passing results.

Re-validate against how you take payments today rather than how you took them at your last attestation, and re-validate out of cycle whenever that changes — a new checkout, a new sales channel, a new phone-order process or a new integration can change which questionnaire applies well before your anniversary date.

RapidCents cannot complete your questionnaire or attest on your behalf, and nothing on this page is a determination that your business is compliant. Your acquirer, and a qualified security assessor where one is engaged, confirms which validation applies to you and accepts it.