PCI statement

What happens to a card number on a Standfast Commerce store, what we do around it, and who decides which questionnaire you file. Said plainly. This page describes the architecture; it is not a certification.

How a card is taken

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.

Where the platform stands today

420.com, a Standfast Commerce customer, went live on 16 September 2026 with the second arrangement: Authorize.net's script tokenising the card on its own checkout page. The hosted payment form is planned before the first outside merchant goes live. Until it has run on 420.com we do not promise it for a merchant store; ask, and we will tell you in writing which arrangement your store would launch on.

Which questionnaire you file

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.

What we do on our side

Running on 420.com 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.

Planned before the first outside merchant goes live:

• The checkout on Authorize.net's hosted payment form, as above.
• Each store's keys encrypted under a key derived for that store, so a row copied from one store cannot open another.
• 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.

What you still do

• 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.

Sources

• 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

This page describes the architecture. It is not a certification and not legal advice. Your acquiring bank confirms which questionnaire applies to your store.