PCI statement

On a Standfast Commerce store the card number goes from the shopper's browser to Authorize.net, your gateway, and not to us. There are two ways that happens, and both end the same way: Authorize.net returns a one-time token, our server charges the token on your gateway, and the card number never enters our servers, our database or our logs. We do not store it, and we cannot see it.

• Authorize.net's hosted payment form. The card fields are served by Authorize.net inside the checkout page. The shopper types into Authorize.net's form, not ours.
• Authorize.net's script in the browser. The card fields are on our checkout page, and Authorize.net's own script (Accept.js) turns the number into a token in the shopper's browser before anything is sent. Only the token reaches us.

For subscriptions, the same step creates a customer payment profile in Authorize.net's vault, under your gateway account. Renewals charge that profile by its identifier. The card number stays with Authorize.net.

Apple Pay and Google Pay, where you switch them on, pass a network token the same way.

Some stores — those selling an unrestricted, non-age-gated catalogue — take cards through Stripe instead. Stripe's own script turns the card number into a one-time token inside a frame Stripe itself serves inside our checkout page; the number never enters our servers, our database or our logs. Stripe is not offered for restricted catalogues, which stay on Authorize.net.

The second arrangement is live today: Authorize.net's script tokenising the card on its own checkout page. Authorize.net's hosted payment form is planned before the first outside merchant goes live. Until it has run on a live store we do not promise it for a merchant store; ask, and we will tell you in writing which arrangement your store would launch on. Stripe's own card-capture method, described above, is live today for stores on that processor.

Every merchant files a PCI self-assessment questionnaire with its acquiring bank each year, and your acquirer decides which one applies to your store. That is true on every hosted platform, including the one you are leaving. We do not name a questionnaire on this page, because it is not our call to make. What we can do is describe the architecture above and, on request, supply Authorize.net's own documentation on how its hosted form and its browser script are meant to be assessed, so that you and your acquirer decide with the facts in hand.

Running today:

• Vendor keys, including the Authorize.net Transaction Key, are encrypted at rest and are never written to logs.
• Staff sign-in uses two-step verification by default, with invite links rather than shared passwords.
• The storefront and checkout pages carry a content security policy that limits which scripts can run.
• Fraud screening at checkout is address verification and the card security code, checked by your gateway. Signifyd, NoFraud and similar services are not integrated; if you use one, keep it.
• Each store's keys encrypted under a key derived for that store, so a row copied from one store cannot open another.

Planned before the first outside merchant goes live:

• The checkout on Authorize.net's hosted payment form, as above.
• A nightly export of each store's database to storage, kept 30 days, so a store can be restored, or taken away by its owner, at any time.

• File your own questionnaire with your acquirer each year. The architecture keeps the card number away from us; the questionnaire is still yours.
• Keep your Authorize.net and merchant-account logins under your own control, with two-step on.
• Tell us if you add any script to the storefront that touches the checkout, because it changes what your acquirer will ask.

• Authorize.net developer documentation, "Accept", describing the hosted payment form and the browser script: developer.authorize.net
• Authorize.net pricing, gateway-only plan: authorize.net