Where card numbers go

A studio takes money through Stripe or Square. Either way the card fields on the checkout page belong to the processor, not to us: they are rendered inside the processor's own frame, on the processor's own origin, by the processor's own script.

What that means, step by step

• The card number, expiry and security code are typed into Stripe Elements or the Square Web Payments SDK. Our page cannot read those fields, and no code of ours receives their contents.
• The processor returns a token. That token is what our server sees and what our server charges. It is not a card number and cannot be turned back into one.
• We never store, log or transmit a card number or a security code. What we hold is the processor's identifier for a payment or a saved card, plus the brand and last four digits the processor gives us for a receipt.
• Our own code carries no card input field. A test scans the storefront and checkout source for one and fails the build if it appears.

The checkout page

Checkout is served by us, not by a studio's theme. A studio's own scripts, its analytics tags and its pasted embeds run on its storefront and are stripped from checkout, so the only scripts on that page are our own, the processor's card fields and the bot check. That is deliberate: a script a merchant pasted last year is the usual way a card form gets skimmed.

Error reports and logs

Crash reports go to Sentry with personal data collection off and a scrubber that rewrites URLs before they leave the browser or the server, so a signed checkout link never reaches the report. Server request logs pass every path through the same redaction. Session replay is off everywhere, and our product analytics is not loaded on any storefront or checkout page at all.

What this adds up to

Because all card data is entered in the processor's hosted fields and everything else is outsourced to them, the merchant path here is the one SAQ A describes. Stripe and Square are PCI DSS Level 1 service providers and hold the certification that matters for the card data itself; a studio completes its own SAQ with its processor, and we are happy to answer questions from whoever is filling it in.

What we do not claim

We are not PCI-certified ourselves, and we do not need to be for the flow described above. We hold no SOC 2 report and no ISO 27001 certificate, and we run no paid bug bounty — see the security page for how to report something anyway. Questions about any of this go to [email protected], and what we store more generally is on the privacy page.