Vulnerability Disclosure Policy

This policy is the route for telling RapidCents about a security flaw in one of its products. It sets out what you may test, what you must not test, the safe harbour RapidCents extends to research carried out in good faith within this policy, how to send a report, and what RapidCents will do once it has one. It is written for security researchers, but it applies to anyone who finds a vulnerability, including a merchant or a customer who came across one by accident.

1. Why this policy exists

Section 8 of the Security Statement describes the testing RapidCents does on its own environment. None of it removes the possibility that someone outside RapidCents finds something first.

What follows then depends on whether the finder has a clear route to report and a credible reason to believe that using it will not go badly for them. Without one, the options left are to say nothing, to publish, or to sell. This policy says where the boundary is, commits in section 4 that RapidCents will not turn on you for staying inside it, and says in section 10 what you get back. A suspected compromise of your own merchant account is a different matter on a much shorter clock; see section 13.

2. What you may test

This policy covers the RapidCents platform as section 1 of the Security Statement defines it: the payment gateway, hosted checkout, payment links, Rapid.js and the embedded components, the merchant dashboard, the virtual terminal, invoicing and recurring billing, point-of-sale software, terminals RapidCents supplies, and the APIs, SDKs and webhooks reaching them. It also covers the public websites at rapidcents.com in all three published locale versions. The support portal at help.rapidcents.com runs on a third-party support platform, so what RapidCents can authorise there is its own content and configuration and no more; the platform underneath belongs to its provider, and the third-party exclusion in section 3 governs it.

Hostnames and endpoints change more often than a published legal page does, so this policy does not freeze a list of them. The current list of in-scope domains, hostnames and API endpoints is maintained by the RapidCents security team and provided on request to [email protected]. Treat anything neither on that list nor named here as out of scope, and ask before you touch it.

Test in the sandbox rather than in production: RapidCents publishes a developer sandbox with documented test cards, and a finding demonstrated there is just as valid while costing a merchant nothing. Where a vulnerability genuinely cannot be reproduced outside production, test against an account you own, with the minimum interaction needed, and say in your report why the sandbox would not do. Use your own account and your own data, and never a real payment card.

3. What this policy does not cover

We can only give you permission to test our own systems. A merchant’s website is theirs, not ours — ask them. Third-party services belong to the third party.

The first three items below are not RapidCents’ to authorise. The fourth is a different route entirely. The last two sit inside the scope in section 2 but will not produce a finding. Saying so is more useful than leaving you to find out.

• A merchant’s own website, application, servers, network, staff or point-of-sale environment. Section 11 of the Security Statement and clause D.2 of the Services Agreement place it with the merchant, and RapidCents cannot give permission to test property that is not its own. Section 13 sets out what to do instead.
• Services operated by third parties, including RapidCents’ cloud infrastructure providers, the Card Networks, acquiring banks, and third-party components embedded in a RapidCents page. Data centre physical security, for instance, is the cloud providers’, as section 5 of the Security Statement states.
• Anything belonging to a RapidCents employee, contractor or merchant in a personal capacity: a personal device, email account, home network or social media account.
• A suspected or confirmed compromise of your own merchant account, systems or card data. That is an incident rather than a research finding, and clause D.2 of the Services Agreement requires you to notify RapidCents immediately, by email to both [email protected] and [email protected]. See section 13.
• Behaviour that is intended. A report that RapidCents refuses SSLv3, TLS 1.0 and TLS 1.1 connections describes what section 3 of the Security Statement says RapidCents does deliberately.
• Findings with no demonstrated security impact: raw scanner output, a missing header with no attack described, a theoretical weakness with no path to exploitation, an issue requiring the victim to paste attacker-supplied code into their own browser, or one depending on an already-compromised device. RapidCents reads and answers these, but usually closes them as informational.

4. Safe harbour for good-faith research

Stay inside this policy and act in good faith, and RapidCents will not come after you legally — it will treat what you did as authorised rather than as hacking. The list below is what good faith means here. It is judged on what you did, not on what you meant, and not on whether you gave your name.

Where you carry out security research and disclosure in good faith and in accordance with this policy, RapidCents will not initiate, support, encourage or recommend legal or administrative action against you arising from it — civil claims and complaints to law enforcement or a regulator alike.

So that nothing is left to inference, RapidCents will treat research carried out within this policy as authorised access. It will not be treated as an attempt to gain unauthorized access to the Services or related systems or networks within the meaning of clause B.4(f) of the Services Agreement, as a breach of any other part of clause B.4, or as a ground for suspension or termination under clause B.5. Where you lawfully possess RapidCents software, analysis of it carried out solely to find and report a vulnerability under this policy will not be treated as a breach of clause B.4(c). RapidCents will not assert that such research is an offence under section 342.1 of the Criminal Code (Canada), under the Computer Fraud and Abuse Act in the United States, or under the technological protection measure provisions of applicable copyright law.

If a third party brings a claim against you over activity RapidCents has confirmed was in scope and in good faith, RapidCents will, on request, make it known to that party, to a court or to a regulator that the activity was authorised under this policy. It is not a promise the claim will be dropped, which is not RapidCents’ to give.

Good faith is not a mood. It is a set of conditions, and all of them have to hold:

• You stayed within the scope in section 2 and did none of the things listed in section 6.
• You did not degrade, interrupt or destabilise the Services, disrupt a merchant’s business or a cardholder’s payment, or destroy, alter or corrupt anyone’s data.
• You accessed only the minimum data needed to demonstrate the issue, stopped the moment it was demonstrated, and did not exfiltrate, retain, share or publish it, as section 7 requires.
• You reported to the address in section 8 as soon as practicable, and before disclosing anywhere else.
• You gave RapidCents a reasonable opportunity to remediate before publishing anything, as section 11 asks.
• You took no benefit from the finding: no payment demanded as a condition of disclosure, no threat to publish or sell, no commercial advantage taken.
• You did not use a real payment card, another person’s account or credentials, or another merchant’s data.
• You left nothing behind — no persistent access, added account, scheduled task or stored payload — and said what you had to create so it can be removed.
• You complied with applicable law, and with this policy where it is stricter than the law.
• Where you left RapidCents a way to reach you, you answered its reasonable follow-up questions about your report and your method. Reporting anonymously is not a failure of this condition; section 8 sets out what it costs you instead.

Every condition above is about what you did rather than about who you are, and none of them requires you to identify yourself. Anonymous reporting is protected: a report sent from an anonymous address, or from none, is inside this safe harbour if the conduct it describes was inside it. What anonymity costs you is practical rather than legal, and section 8 sets it out — RapidCents cannot ask you the question that unblocks a triage, cannot tell you the outcome, and cannot credit you under section 12. Nor can it give a third party the confirmation described above until it knows whose activity it was; identifying yourself later, if you ever need that confirmation, remains open to you and weakens nothing here.

Good faith is assessed on what you did, which is why section 9 asks for the dates, times and source addresses of your testing: they let RapidCents match your account of events against its own logs. If you are unsure whether something you are about to do falls inside these conditions, ask at [email protected] first. Asking before acting is itself evidence of good faith.

5. The limits of the safe harbour

Section 4 is a commitment RapidCents makes about its own conduct, and it binds nobody else. Merchants, cardholders, cloud infrastructure providers, the Card Networks, acquiring banks, regulators and law enforcement are not parties to this policy and keep whatever rights they have. If your testing touches a system or a person outside section 2, section 4 does not help you there.

It does not authorise you to break the law or displace RapidCents’ own legal obligations. Where an event is a compromise of data rather than a demonstration of a flaw, RapidCents may be required to notify affected merchants, regulators, acquiring banks and the Card Networks, as section 10 of the Security Statement describes, and nothing in section 4 prevents RapidCents from responding to a lawful order or a court process.

It applies only to activity actually within this policy. Where the scope in section 2 was exceeded, something in section 6 was done, real data was taken past the point of proof, or a condition in section 4 was not met, RapidCents reserves all of its rights and those of the parties affected — judged on what was done rather than on how it is characterised afterwards.

It is not a contract, licence, engagement or partnership and does not make you an agent of RapidCents. It grants no right in RapidCents’ intellectual property beyond what section 4 states, entitles you to no payment, does not suspend the confidentiality obligations in clause E.2 of the Services Agreement for anyone already subject to them, and does not make non-public information you encountered free to use or publish.

6. Testing that is out of bounds

None of the things below are research, and doing any of them takes you outside the safe harbour. Most of them harm someone who never agreed to be part of your test — a merchant, a cardholder, or a person at a desk.

Each prohibition carries its reason, so that you can apply it to a situation this list did not anticipate.

• Denial of service of any kind or scale, including floods, resource exhaustion and algorithmic complexity attacks. A payment platform that is down means merchants who cannot take money and cardholders who cannot pay, neither of whom agreed to your test; clause B.4(e) of the Services Agreement prohibits disrupting the performance of the Services.
• Automated scanning that degrades service, and bulk creation of accounts, transactions, invoices, links, tickets or messages. Volume against a live payment system is indistinguishable from an attack until someone has spent a night establishing otherwise. Rate-limit yourself, stay within the API limits set under clause B.3 of the Services Agreement, and agree anything at scale with [email protected] first.
• Social engineering of any kind against anyone — staff, contractors, merchants, their staff, customers or cardholders — including phishing in every form, vishing, smishing, pretexting, baiting, impersonation, and any attempt to obtain a password, a one-time code or an account recovery from a person. Nobody can consent to a test they were never told about, and the harm from a successful pretext lands on them personally. Section 11 of the Security Statement tells merchants RapidCents will never ask for a password or a one-time code; you must not either.
• Physical attacks and access attempts: entering or attempting to enter RapidCents premises or a data centre, tailgating, talking your way past a reception desk, dumpster diving, or interfering with, opening or substituting a payment terminal in a merchant’s possession. Data centre physical security belongs to RapidCents’ cloud providers and is not RapidCents’ to authorise, and a terminal in a merchant’s hands is in that merchant’s care under the Services Agreement.
• Spam and unsolicited messaging, including any test that sends messages to people who did not ask for them. Canada’s Anti-Spam Legislation governs commercial electronic messages sent from or to Canada, and the United States imposes equivalent requirements of its own, so such a test is a legal problem for you before it is a finding for RapidCents.
• Injecting content other people will see. Test payloads left in merchant-facing fields, invoices, payment links, statement descriptors, support tickets or dashboard records are read by staff and merchants who have no idea a test is underway. Mark test data plainly and remove it.
• Accessing, modifying, exfiltrating or destroying real cardholder data or anyone else’s personal information — the line the rest of this policy is built around, set out in full in section 7.
• Using a real payment card to test in production, and any attempt to move, divert, capture or retain funds. Money movement is demonstrated in the sandbox against documented test cards; a finding demonstrated by moving real money is a different event with a different name.
• Accessing an account, merchant or tenant that is not yours, or continuing into another party’s data once cross-tenant access has been demonstrated. The demonstration is the finding; what lies past it is somebody’s business records.
• Uploading or transmitting worms, viruses, malware, ransomware or any destructive code, which clause B.4(h) of the Services Agreement prohibits outright, and installing or leaving behind persistent access.
• Making disclosure conditional on payment, or threatening to publish or sell a finding unless RapidCents pays. That is extortion rather than research; section 12 says what happens to a report arriving that way.

7. Real data: stop at proof

The moment you can see someone else’s data, you have proved your point. Take a screenshot with the data blacked out, stop, and tell us. Taking more is not more proof — it is a breach, with your name on it.

If your testing gives you access to cardholder data, personal information, credentials or confidential business information belonging to RapidCents, a merchant, a cardholder or anyone else, stop there. That you could reach it is the finding. Everything past it is collection, and it converts a good-faith report into an event RapidCents may have to treat as a breach of security safeguards, with notification obligations for RapidCents and legal exposure for you.

Minimum means minimum: one record rather than a table, a screenshot with the values redacted rather than a copy of the page, an identifier or count rather than contents, the first and last few digits rather than a card number. Do not run a query returning bulk data to establish how many records are exposed — state the scale you believe is involved and let RapidCents confirm it against the logs described in section 6 of the Security Statement. Do not save, download, copy, print, retain, share, post or upload any such data, in your report or anywhere else, including a blog post, a third-party issue tracker or paste service, or any artificial intelligence or other online service that processes what you give it. If you took a copy before reading this, say so and say what you took; do not delete it until RapidCents confirms it has what it needs, then delete it securely and confirm in writing.

Section 2 of the Security Statement records that RapidCents never stores card verification values, PINs, EMV chip data or full magnetic-stripe data. If you believe you have found any of those in storage, a log, a response body or a backup, that is a high-severity report RapidCents wants immediately: say so in your first line and retain no copy.

Personal information is regulated wherever this policy is read. Handling it without authority engages the Personal Information Protection and Electronic Documents Act in Canada, the Act respecting the protection of personal information in the private sector as amended by Law 25 in Quebec, the Personal Information Protection Acts in Alberta and British Columbia, and comprehensive state privacy laws in the United States. Those obligations attach to you as well as to RapidCents once the data is in your hands. Personal information you do send RapidCents is handled under the RapidCents Privacy Policy and retained no longer than the investigation, the remediation and RapidCents’ legal obligations require.

8. How to report

Email [email protected]. Write in English or in French, whichever you prefer, and we will answer in the same language. Do not put anyone’s card number or personal details in the message.

Send the report by email to [email protected] — the security contact RapidCents already publishes, and the address named in clause D.2 of the Services Agreement. Putting the words Vulnerability report in the subject line helps.

• Reports are accepted in English and in French, and RapidCents will reply in the language you write in. Use whichever you are more precise in.
• Send one report per issue: two unrelated findings in one email are triaged at the speed of the slower one.
• Do not report through the support portal at help.rapidcents.com, a support ticket or sales enquiry, social media, or to an individual employee. A vulnerability sitting in a support queue is a vulnerability nobody is triaging.
• If you need to send the report encrypted, say so in your first message without the technical detail, and RapidCents will agree a secure channel with you before you send it. Do not send detail unencrypted on the assumption that a channel exists.
• Anonymous reports are accepted and investigated. The safe harbour in section 4 protects conduct rather than identity, so it still covers what you did — but if RapidCents cannot reach you it cannot confirm your activity was in scope, ask the question that unblocks a triage, tell you the outcome, or credit you under section 12.
• Do not include real cardholder data, credentials or another person’s personal information in the report itself; section 7 explains what to send instead.
• If you are reporting an active, ongoing compromise rather than a latent flaw, say so plainly in the first line. That changes how the report is handled from the moment it arrives.

9. What a useful report contains

The difference between a report triaged in a day and one triaged in a fortnight is almost always whether the reader can reproduce the issue without writing back.

• The product or surface affected, and the exact URL, endpoint, API method or screen.
• The date, time and time zone of your testing, and the source IP addresses you tested from. This lets RapidCents find your activity in the logs described in section 6 of the Security Statement and separate it from a real attack.
• The account, merchant identifier or test data you used, and whether you were in the sandbox or in production.
• A description of the vulnerability and the class it belongs to, in your own words rather than a tool’s.
• Reproduction steps, in order, precise enough for someone else to follow without guessing, including any request and response needed.
• A proof of concept: the least needed to demonstrate the issue, with real data redacted as section 7 requires.
• What an attacker could achieve, and what they would need to get there — a prerequisite, a privileged position, a user interaction, a particular configuration.
• Any tooling used, and its configuration where that affects the result.
• Anything you created, changed or left behind, so it can be found and removed.
• Whether you have disclosed the issue to anyone else or intend to, and any deadline you are working to — at the start, rather than in the third exchange.
• How to reach you, and the language you would like the reply in.

Screenshots and a short video help. Raw scanner output on its own generally does not: it describes what a tool said rather than what an attacker could do, and section 3 explains why such a report is usually closed as informational.

10. What happens after you report

We confirm we got it, we try to reproduce it, we tell you whether it is in scope and how serious it is, we fix it, and we tell you when it is done. Every report gets a decision, including the ones we decide not to act on — and we tell you why.

None of the following is expressed as a fixed number of hours: an acknowledgement promised in a figure RapidCents has not committed to operationally would be worth less to you than a commitment it will actually meet.

• Acknowledgement. RapidCents will confirm receipt to the address you wrote from, promptly and without waiting for triage to finish. If none arrives, resend. If a resent report is still unanswered, RapidCents opens to you under this policy the escalation route that clause A.6 of the Services Agreement gives merchants, whether or not you are one: raise it with support at help.rapidcents.com, [email protected] or +1 (844) 957-2743, and if it is not resolved or formally closed within fourteen business days, escalate to [email protected] with the earlier correspondence attached. That path exists so a report cannot simply disappear.
• Triage. The security team will attempt to reproduce the issue, decide whether it is in scope under section 2, and assess severity by what an attacker could actually achieve — the effect on cardholder data, funds, merchant accounts and availability. RapidCents may come back with questions and asks that you answer them; a report that cannot be reproduced, whose reporter does not respond, is eventually closed as not reproducible.
• Remediation. Fixes go through the change-control process described in section 7 of the Security Statement and are prioritised by severity rather than by the order reports arrived in. Where a vulnerability is major, section 5 of the Security Statement describes the practice RapidCents follows: patches applied without delay.
• Updates. RapidCents will keep you informed at the points where there is something to say — reproduced or not, scope and severity decided, fix shipped — rather than on a calendar of contentless status mail. Ask for a status update at any time and you will get an honest one.
• A decision. Every in-scope report gets an outcome and you will be told what it is: fixed, mitigated, accepted as a risk with the reasoning stated, a duplicate, out of scope, or not reproducible. A decision not to act is still a decision and you will be given the reason. Where an issue is a duplicate, the first report of it is treated as the report of it.
• No conditions attached. RapidCents will not require you to sign a non-disclosure agreement, or accept any other terms, as a condition of submitting a report, receiving a reply, or being told the outcome.

Where a vulnerability has affected merchant data or accounts, what RapidCents notifies and to whom is governed by its incident response process rather than by this policy: section 10 of the Security Statement provides that RapidCents notifies affected merchants without undue delay and makes notifications to regulators, acquiring banks and the Card Networks as law and the Network Rules require.

11. Coordinated disclosure and publication

Tell us first, and please wait until it is fixed before you write it up. After that, publish — just leave out anything that belongs to a merchant or a cardholder.

Report to RapidCents first, and before disclosing anywhere else. Section 10 of the Security Statement already says this; it is repeated here because it is the single request that matters most.

RapidCents asks that you not publish, demonstrate or otherwise make public the details of a vulnerability until it has been remediated and RapidCents has confirmed to you that it is fixed or mitigated. A working attack against a payment platform, published before there is a fix, is handed intact to everyone with an interest in merchants’ money, and the people who pay for it are merchants and cardholders who had no part in the decision to publish.

This is a request, not an indefinite embargo. RapidCents will tell you when it expects to have shipped a fix rather than leaving a report open without an end in sight, will work with you on timing, and will explain its reasons if remediation takes longer than you think reasonable. Where you intend to publish after a fix, RapidCents asks to see the draft in advance so factual errors can be corrected and nothing identifying a merchant, a cardholder or another party goes out with it. RapidCents does not claim a right to approve what you write, to require changes of substance, or to prevent publication of an accurate account of a fixed issue.

Whatever you publish must not contain cardholder data, personal information, credentials, internal identifiers or confidential business information belonging to RapidCents or a merchant; clause E.2 of the Services Agreement governs confidential information for anyone already subject to it. Publishing another person’s data takes the disclosure outside this policy, and with it the safe harbour in section 4, at any point and whether or not a fix has shipped. Publishing the vulnerability itself costs you the safe harbour only where you published without having given RapidCents a reasonable opportunity to remediate, which is the condition section 4 states and the only condition on timing this section enforces. Waiting for RapidCents to confirm a fix is the request; a reasonable opportunity to remediate is the condition, and RapidCents does not treat delay of its own making as your failure to meet it. Where RapidCents publishes its own advisory, it credits the reporter on the terms agreed under section 12.

12. Recognition, and the absence of a paid bounty programme

We do not pay for vulnerability reports. There is no bounty programme. What you get is a real answer, a real fix, and public credit if you want it.

RapidCents does not currently operate a paid bug-bounty programme. There is no reward schedule, no payment for a report, and no bounty platform. This policy is a disclosure route, not a purchase order, and saying so plainly is fairer to you than leaving the question open until after you have done the work.

What RapidCents offers is an acknowledgement, a real triage by people who will try to reproduce what you found, a decision you will be told, and public credit in any advisory RapidCents publishes about the issue. Credit is given with your consent and on your terms — under your name, under a handle, or not at all — and if you say nothing you will be asked before anything is published.

If RapidCents introduces a bounty programme in future, its terms will be published here or at a route linked from here, and will not apply retrospectively to reports already submitted. RapidCents may choose to recognise an exceptional report in some other way at its sole discretion; no report creates an entitlement to a payment or any other reward. A demand for payment as a condition of disclosure, or a threat to publish or sell a finding unless RapidCents pays, is extortion rather than research: it falls outside this policy and outside the safe harbour in section 4.

13. Merchants, merchant sites and third-party services

If your own account or card data has been compromised, that is an incident, not a research report: email security@ and legal@ straight away — immediately, with no grace period — and do not wipe anything. If you found a problem on a merchant’s own website, tell the merchant — it is not ours to authorise you to test.

If you are a RapidCents merchant and you know or reasonably suspect that card data, credentials or systems associated with your merchant account have been compromised, this is not the route. Clause D.2 of the Services Agreement requires you to notify RapidCents immediately of any suspected, alleged or confirmed compromised data event, regardless of source and including one affecting your own third-party service providers, by emailing both [email protected] and [email protected]. Neither that clause nor any other RapidCents document gives you a number of hours to work with: the obligation runs from the moment you know or suspect.

Preserve the evidence. Clause D.2 requires that you not alter or destroy any related records and that you document accurately any modification you make. Contain rather than erase: take the affected system off the network, rotate credentials and API keys, revoke active sessions — but do not reimage, wipe or rebuild, because a forensic investigation needs exactly what a clean rebuild destroys. Clause D.2 also sets out RapidCents’ right to engage a forensic vendor approved by an Association and your obligation to cooperate with it.

If you have found a vulnerability in a merchant’s own website, application, integration or point-of-sale environment, contact the merchant. RapidCents neither owns nor controls any of it and cannot give you permission to test it, so neither this policy nor its safe harbour reaches it — the same boundary section 11 of the Security Statement draws for security generally and the PCI Compliance page draws for PCI DSS validation.

Where the issue appears to arise from a merchant’s use of a RapidCents product, RapidCents does want to know and will contact the merchant. What it can do is bounded: it can change its own product, documentation and defaults, and can require information or remediation from the merchant to the extent clause F.7 and the rest of the Services Agreement allow, but it cannot test, patch or take responsibility for a system a merchant runs. If your report concerns a third-party service RapidCents relies on or embeds, report it to that provider under its own policy, which is the only route that can produce a fix; tell RapidCents as well and it will pass the report on where it is able to.

14. Changes to this policy

This policy is reviewed periodically and revised when the products in scope change, when the way RapidCents receives and handles reports changes, or when the law bearing on security research or personal information changes. The revision date at the head of this page changes with every edit; the effective date changes when the substance of the commitments changes. A report is assessed under the version in force when it was submitted, so a later revision cannot retroactively take a researcher outside a safe harbour they relied on in good faith at the time they acted.

This policy describes practices and states commitments RapidCents makes to a person who reports a vulnerability under it. It is not a warranty that any RapidCents product is free of vulnerabilities. Where this policy and the Services Agreement differ, the Services Agreement governs the contractual relationship between RapidCents and a merchant — with one exception, because without it this policy would promise a merchant nothing. Section 4 does not vary what a merchant owes under that agreement; it states how RapidCents will exercise its own rights under it, which is RapidCents’ to decide. RapidCents does not rely on this paragraph, or on the precedence of the Services Agreement generally, to withdraw section 4 from a researcher who is also a merchant or a member of a merchant’s staff. A researcher who is not a RapidCents merchant is not party to that agreement at all, and the commitments in section 4 are made to them under this policy directly.

Questions about this policy, and requests for the current list of in-scope domains and endpoints, go to [email protected]. Notices under the Services Agreement go 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 of that agreement requires.