Trust & security

A security vendor asking to run code on your payment page should expect harder questions than most vendors get. These are the ones we get asked.

What our script can see

It observes other code: what loads, from where, when, and what changed since the baseline. It does not read form field values. That is a property of how the collector is built rather than a policy we promise to keep, which is the distinction worth pressing any vendor on.

What happens if we go down

Nothing, on your side. Collection is asynchronous and nothing on the page waits for our endpoint. You stop receiving change notifications until we are back; your checkout does not notice. A vendor whose outage can take your checkout with it has made a design choice, and you should ask which one they made.

What we store, and for how long

Script metadata, hashes, timing, baselines and change records. Thirteen months by default, configurable up or down. No cardholder data, at any point, in any product.

Access

Support staff do not have standing access to customer data. Access is granted per incident, time-limited, logged, and the log is visible to you.

Certifications and assessments

A real vendor lists its SOC 2 report, its penetration testing cadence, and who performed them, and provides the report under NDA. A fictional vendor should not claim any of those, so this section names none — which is itself the honest answer for a demonstration site.

Reporting something to us

A real company would publish a responsible disclosure policy here, with scope, a safe-harbour statement and a contact route. This one cannot, because there is nothing to report against and no inbox behind it.

Subprocessors

A real trust page lists every subprocessor with its function and location, and notifies customers before adding one. That list is the most useful thing on most trust pages and the least read.