Security Statement

This statement describes how RapidCents protects the systems that carry payment and account data, and where responsibility for security sits between RapidCents and the merchants who use them. It is a description of the controls RapidCents operates, not a warranty that any system is free of vulnerabilities. The controls below cover the RapidCents platform; section 11 sets out what remains yours.

1. Scope of this statement

This statement applies to the RapidCents platform: the payment gateway, hosted checkout, payment links, Rapid.js, the merchant dashboard, the virtual terminal, invoicing and recurring billing, point-of-sale software, terminals RapidCents supplies, and the APIs and SDKs through which those are reached.

It describes the controls in force at the effective date shown above. Controls change as threats and the standards addressing them change, and RapidCents may revise this statement; the revision date shows when the text last changed. Where this statement and the Terms of Service differ, the Terms govern the contractual relationship between you and RapidCents.

This statement describes practices. It is not a service level, a warranty, or a representation that any system, product or transmission is free of vulnerabilities.

2. How card data is handled

Card numbers go to RapidCents rather than to you, and you get back a token. RapidCents never keeps the CVV, the PIN, or the data read off a chip or a stripe.

The platform is built so that raw card credentials reach RapidCents rather than merchant systems. Hosted checkout, Rapid.js embedded fields, tokenization, the secure card vault and validated terminals each capture the card on a RapidCents-controlled surface and return a token — a reference that only RapidCents can map back to the credential, and that on its own cannot be used elsewhere.

Where cardholder data is stored, it is stored encrypted and on systems kept separate from the web servers that serve public traffic. Data belonging to different merchants is logically separated and inaccessible between merchants, and access to merchant data by authorized RapidCents staff is logged.

RapidCents retains cardholder data for up to 24 months of inactivity. Card verification values, PINs, EMV chip data and magnetic-stripe data are not stored at all — not encrypted, not truncated, not held pending a later step.

• Never stored: card verification values (CVV).
• Never stored: PINs.
• Never stored: full magnetic-stripe data.
• Never stored: EMV chip data.
• Stored encrypted where retained: cardholder name, card number, expiry date, and the cardholder address held for AVS.

3. Encryption in transit and at rest

In transit, RapidCents requires TLS version 1.2 connections to its servers, using a limited set of strong ciphers, so that data moving between systems is encrypted and its integrity can be verified. SSLv3, TLS 1.0 and TLS 1.1 are deactivated. An integration or device that can only negotiate one of those older protocols will not connect, which is the intended result rather than a fault.

At rest, RapidCents uses the Advanced Encryption Standard (AES) with 256-bit keys for sensitive merchant and cardholder data. The fields encrypted in storage include the cardholder name, the card number, the expiry date and the cardholder address held for address verification.

4. Access control and authentication

Staff and merchants both use MFA. Internal systems are reachable only over VPN, and access is recorded.

RapidCents requires multi-factor authentication (MFA) for staff and for merchants accessing its systems. It is a requirement rather than an option a user can decline.

Password settings enforce complexity, require passwords to be changed on a defined schedule, and store them hashed and salted. Users cannot reuse any of their last 13 passwords.

Internal systems are reached over VPN, which gives remote access to a limited selection of systems rather than to the environment as a whole. Access is granted by role, so that a role carries the access its work requires and no more. Network access and activity are recorded through local and centralized logging, producing an audit trail that can be reviewed after the fact.

5. Network and infrastructure security

Server environments run firewalls with a deny-all default policy. Inbound and outbound connections are refused unless a rule authorizing them has been reviewed and added.

Internal office networks are kept separate from RapidCents platform environments. There is no wireless access to the platform environment, and the office network is reachable only by employees physically connected to it.

Servers are hardened in line with current security guidance, and systems and network appliances are kept up to date. Where a major vulnerability is identified, patches are applied without delay, and updates are recorded under RapidCents’ change-control policies.

Physical security of the facilities is provided by RapidCents’ cloud data centre providers, which operate 24/7 on-site surveillance and restrict physical access to key personnel through multi-factor controls that include biometrics.

6. Monitoring, logging and intrusion detection

Intrusion detection (IDS) and intrusion prevention (IPS) run at the firewall and locally on every server in the RapidCents environment. They screen network traffic for suspicious behaviour, abnormal traffic and malicious code, and the prevention layer acts on what it identifies rather than only recording it.

Unusual activity raises an alert to the RapidCents security team, together with the attack data where an event has occurred, so the team can review it and inspect what was attempted. Logging is collected both locally and centrally, which is what allows activity to be reconstructed rather than merely noticed.

7. Secure development and change control

RapidCents systems and applications are developed in-house. Developers are trained on secure coding practice, including the guidance published by the Open Web Application Security Project (OWASP), and are kept current as that guidance changes.

Building in-house keeps coding standards, source code and deployment cycles under RapidCents’ control, and lets development, quality assurance and security review the same change before it ships. Changes to systems are logged as part of RapidCents’ change-control policies.

8. Testing and independent assessment

RapidCents is a PCI DSS Level 1 service provider. Holding that status involves on-site audits, vulnerability scanning, penetration testing and inspection against the Payment Card Industry Data Security Standard. RapidCents also follows security practices prescribed by the National Institute of Standards and Technology (NIST).

Networks and applications are scanned regularly, both internally and externally, with external scans performed by Approved Scanning Vendors (ASV). Penetration testing is carried out by the RapidCents security team and by third-party professionals to check that unauthorized access and other malicious activity are not possible; identified vulnerabilities are addressed by the systems and development teams.

Independent assessment covers the RapidCents environment. It says nothing about the security of a merchant’s own systems, and it does not validate a merchant’s PCI DSS compliance. Section 11 and the PCI Compliance page set out that boundary.

9. Availability, backup and continuity

The platform runs on redundant virtual environments across cloud data centres. Those providers use backup power generation and dual-path power distribution, and the architecture is designed to scale compute resources quickly to absorb peak demand.

Databases are backed up daily, both between data centres and offsite, to guard against loss, corruption, theft and destruction.

Redundancy reduces the likelihood of interruption; it does not eliminate it. This statement does not set an availability commitment. Where one applies to your account, it is stated in your agreement with RapidCents and not here.

10. Incident response, notification and reporting a vulnerability

If something happens on our side, we investigate and tell the merchants it affects. If you find a weakness, report it through the disclosure page — and never test with live card data.

RapidCents operates an incident response process covering detection, containment, investigation, remediation and review. Where an incident 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. Notifications to regulators, acquiring banks and the Card Networks are made as law and the Network Rules require. This statement fixes no number of hours for that notice, and neither does the Services Agreement: clause D.1.3(d) states the commitment as notice without undue delay, which means as soon as RapidCents can give a merchant something it can act on, not when an investigation closes.

If you believe you have found a vulnerability in a RapidCents product, report it through the route described at /legal/vulnerability-disclosure, and report it there before disclosing it elsewhere. Do not use live cardholder data, another party’s account or another merchant’s data in the course of testing, and do not use techniques that degrade service for others.

If you know or reasonably suspect that card data or credentials associated with your merchant account have been compromised, tell RapidCents immediately. Clause D.2 of the Services Agreement, at 2.3, requires immediate notice of any suspected, alleged or confirmed compromised data event, regardless of its source and including one affecting your own third-party service providers, by email to both [email protected] and [email protected]. The Agreement gives you no grace period and fixes no number of hours; immediately means on knowing or suspecting. Preserve logs and affected systems rather than rebuilding them: a forensic investigation needs the evidence that a clean rebuild destroys.

11. What remains your responsibility

Our controls stop at our platform. Your staff, your devices, your integration and your PCI validation are yours.

The controls described above cover RapidCents’ systems. They do not extend to your networks, devices, staff, software or the way your team uses the Services, and they do not discharge your own PCI DSS obligations. Section D of the Services Agreement states that split contractually — clause D.2 places PCI DSS compliance for your systems, processes and personnel with you — and the PCI Compliance page explains how it maps to your validation.

Most merchant-side incidents are not sophisticated. They come from a shared login, a card number written somewhere it should not be, or an integration left on a version that stopped receiving fixes.

• Give each person their own dashboard login, grant the access their role needs, and remove it the day they leave.
• Keep multi-factor authentication enabled, and never share a password or a one-time code. RapidCents will not ask you for either.
• Never write a card number, CVV or PIN into a notebook, spreadsheet, email, chat message, CRM record, support ticket or call recording.
• Keep your integration, plugins, point-of-sale software and terminals on supported versions, and secure the servers, endpoints and networks you control.
• Keep terminals in your possession physically controlled, and inspect them for tampering or substitution.
• Complete your own annual PCI DSS validation on the questionnaire that matches how you actually accept payments.
• Tell RapidCents promptly about a suspected compromise, a lost or stolen terminal, or dashboard activity you do not recognize.