Company / PCI compliance
PCI DSS, without the projectCollect card data through High Wire and shrink the control set you have to satisfy
PCI compliance is rarely hard because of the rules. It is hard because card data has been allowed to touch too many of your systems, and every one of them then has to be defended, documented, and audited. The fastest way to reduce that work is to stop touching card data at all.
Your scope depends on how you take the card.
The same business can face three very different amounts of work depending on which checkout it builds. This is the table to look at before writing any code.
| How you collect the card | Where card data goes | Typical effect on scope |
|---|---|---|
| High Wire CheckoutHosted, we own the page | Never reaches your servers or your page | The smallest control set available to you |
| High Wire ComponentsOur fields embedded in your page | Entered into our component, encrypted before it leaves the browser | Small, with added requirements for the page that hosts the component |
| API checkoutYour form, your server | Passes through your systems | Significantly larger. Your servers, network, and logging come into scope |
| Existing processor integrationYou already collect cards elsewhere | Wherever it goes today | We assess what you have and tell you what moving would change |
We will tell you which questionnaire applies to your design before you build, not after your first audit.
How we get there.
Three steps, and the first one is a conversation rather than an integration.
We map where card data flows today, which systems touch it, and which of those could stop. The output is a written recommendation and the questionnaire you would land on for each option.
You build against one of our patterns, and we check the integration does what the scope reduction assumes. A component installed incorrectly reduces nothing, so this step matters.
You get our attestation of compliance, the architecture description your assessor needs, and a policies and procedures starting point so you are not writing them from scratch.
What card data does, and never does.
Four flows cover almost every payments architecture. In each one, the card is handled by us rather than by you, which is what moves the work off your side.
What is left after the card data is gone.
Reducing scope is not the same as removing it. These requirements stay with you, and we cover them rather than leaving you to find vendors.
PCI requires quarterly scans by an approved scanning vendor against your public-facing systems, with remediation and rescans until you pass.
Recent versions of PCI DSS require you to know which scripts run on a page that takes payment and to be alerted when they change. This is where card skimming happens.
Access control, logging, and staff training remain yours. We provide a starting bundle rather than a blank page.
Someone still signs an attestation each year. We provide the evidence for our part of the environment so your assessor is not guessing.
Does using High Wire make me PCI compliant?
No, and be wary of anyone who says it does. It reduces which requirements apply to you and gives your assessor evidence for the part we operate. You still validate your own environment.
Which questionnaire will I end up on?
It depends on how you collect the card and on your acquirer's requirements. We will tell you the likely answer for each integration option before you build, and your assessor confirms it.
We already take cards. Is it worth moving?
Often, but not always. The saving is in systems you can take out of scope, and in audit and remediation effort. We will map what you have and show the difference before you commit.
Do you support merchants who must keep card data themselves?
Yes. API checkout exists for that reason. You keep more scope, and we are direct about what that means rather than pretending otherwise.