Velo Payments

Program overview

Velo Payments acquires card transactions for roughly 52,000 merchants, runs the dashboard those merchants manage their business in, and settles funds across payout rails we operate ourselves. The asset is money and the record of money. Every severity decision on this page resolves to one question: how close does this finding bring someone to moving, reading or forging value?

The program has run since October 2019. In that time we have resolved 1,864 reports, paid 2,997,508 USD to 409 researchers, and revised this policy eight times: twice because something went wrong, once because a regulator's deadline arrived. Triage is staffed by engineers who work on the payment stack, which is why first response averages two hours rather than two days. We pay the highest ceiling on this directory. In exchange we are the strictest program on it about how you test, and we apply that without discretion.

Testing rules and expectations

Sandbox is not a suggestion

Register a sandbox merchant at dashboard.velopay.example/sandbox. Approval is automatic and takes minutes. Sandbox credentials carry the sk_sbx_ and pk_sbx_ prefixes, and every submission must state the sandbox merchant identifier you used. Reports without one are returned unread. That rule dates from September 2022, a month after a researcher exercised a refund flow against a live merchant account and put a real primary account number in the report.

Use the reserved test instrument numbers from the sandbox documentation. Not your own card, not a colleague's, not a number obtained anywhere else.

Cardholder data

No research question requires live cardholder data to answer it. If you find a path to real primary account numbers, expiry values or authentication data, stop at the moment the path is proven, capture nothing, and tell us within the hour. We will reproduce it against instrumented data ourselves and you will be paid on our reproduction. A report that makes its case by retrieving real cardholder data is processed as a security incident rather than a submission, whatever the intent behind it.

Everything else

• No denial of service, no sustained fuzzing, no load generation against shared sandbox infrastructure.
• Leave people out of it: no phishing, no pretexting, no support calls, no password-reset attempts against employees, merchants, contractors or acquirers.
• No physical attempts against offices or staff devices.
• Do not pivot into a merchant's own systems, however easy our surface makes it look.
• State the UTC window of your session in every submission, next to the merchant identifier.

Proving write access

If you find a way to write, do not prove it by causing damage. Prove it with the smallest change that can be attributed to you and undone in the same minute.

• One or two punctuation characters. Delete a full stop, add a comma. Nothing longer, nothing visible, no payload, no changed number or amount.
• Only on a record you created yourself. Never another user's record, never site content, never anything the public can see.
• Revert within sixty seconds, in the same run, without being asked.
• Capture four states: before, after the change, after the revert, and an independent re-read confirming the revert held.
• If it cannot be reverted, do not change it. Report the write primitive and stop. A row count and a column list already prove database access.

Every request must carry headers that let us separate your traffic from a real attack in our logs:

X-Bug-Bounty:        velo-payments
X-Research-Account:  <the account you submit the report under>
X-Authorisation-Ref: <engagement or report reference>
X-Request-Id:        <unique per request>
User-Agent:          sentinel-research/<handle> (+<this page>)

scripts/proof_of_write.py performs exactly this sequence, refuses any host outside the scope above, refuses a diff longer than two characters, always attempts the revert, and writes a timestamped evidence file. Run it without --execute first, then attach the evidence to your report.

Safe harbor

Testing that stays inside the scope table, uses sandbox credentials only and follows the rules above is authorised. We will not bring civil or criminal proceedings over it, and if anyone questions whether the work was allowed, we will answer them in writing on our own letterhead.

That authorisation is deliberately narrow. It does not reach live merchant accounts, real cardholder data, our acquirers, the card networks, or any merchant's own infrastructure. It ends when you retain data beyond what the proof required, disclose before the agreed date, or make payment a condition of telling us what you found.

One thing we will not pretend about: our obligations to the card brands and to our assessors are not ours to waive. Where a finding requires us to notify, we notify, and that has happened once with a researcher who did nothing wrong. Safe harbor protects you from us. It does not stop a regulated process that exists whether or not anybody behaved well.

Reward decisions

A CVSS v3.1 score opens the discussion and financial reachability settles it. Three factors carry real weight: whether funds can move, whether cardholder data is exposed, and whether a merchant boundary is crossed. A dashboard object-reference flaw that exposes another merchant's settlement schedule outranks a technically noisier bug confined to your own account.

Whoever files first with a working reproduction takes the award. A chain is one award at the severity of its outcome, never one award per link. We add 20% where a report identifies the systemic cause instead of a single instance, and more at our discretion where the write-up changes how we design a control. Findings that require merchant collusion or an already-compromised merchant device drop by at least one band.

Disclosure policy

One hundred and twenty days from triage. The window is longer than most because payment changes go through certification before they ship, and we would rather commit to a date we can hold than miss a shorter one. You get a written update every fourteen days without having to ask.

Publication needs our confirmation that the fix is live in every region. Remove merchant identifiers, transaction references, internal service names, and any sandbox value that maps back to a real entity. We review drafts in five business days and we do not touch your technical conclusions.

Report quality

• The sandbox merchant identifier and the key prefix you used.
• The endpoint, the complete request and response, and the SDK version where one is involved.
• Steps a payments engineer can follow without coming back to you with a question.
• One sentence of financial impact: what moves, what leaks, whose money.
• The UTC start and end of the session.
• Anything you left behind in the sandbox ledger, so reconciliation can clear it in the morning.