Security
Last updated: September 11, 2026
Merchants run their businesses on PlatformDTC, and their customers enter personal and payment details into checkouts we host. This page describes the security controls in place today: how card data is handled, where data is hosted and how it is encrypted, how accounts and API access are protected, and how to report a vulnerability.
It describes controls we operate. It is not a certification or an audit report.
Payment card data
PlatformDTC does not store full card numbers or card security codes. How card details travel depends on the payment provider a store uses:
- PlatformDTC Payments and Stripe. Card payments are processed by Stripe, a PCI DSS Level 1 Service Provider. Card details are entered into Stripe-hosted fields and never reach PlatformDTC servers. This covers checkout, adding a card to a subscription, and card updates and plan purchases in the merchant dashboard. One-click post-purchase offers show no card form at all — they reuse the payment method the customer already authorised with Stripe.
- Checkout.com. Card details are entered into Checkout.com's hosted payment component and never reach PlatformDTC servers.
- MyFatoorah. Card details are entered into MyFatoorah's embedded payment form and never reach PlatformDTC servers.
- PayPal. Customers approve the payment in PayPal's own checkout. PlatformDTC does not receive their PayPal login.
- Authorize.net. For stores that connect their own Authorize.net account, card details are sent over TLS to PlatformDTC's checkout API, which passes them to Authorize.net to authorise the payment. The card number and security code are not written to our database or our logs.
The API credentials merchants connect for payment providers are encrypted before they are stored.
Infrastructure and encryption
Hosting
PlatformDTC's application servers, primary database and store file storage run on Amazon Web Services in the US East (N. Virginia) region. DNS, and traffic to our API, documentation and status hosts, runs through Cloudflare. Our mail server is hosted by Hetzner in Germany.
Every third party that processes personal data for us is listed, with its purpose and location, on our Subprocessors page.
Encryption in transit
- Our public hosts — platformdtc.com, api.platformdtc.com, checkout.platformdtc.com, docs.platformdtc.com, status.platformdtc.com and mail.platformdtc.com — accept only TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 are refused.
- The API (api.platformdtc.com) sends HTTP Strict Transport Security.
- Connections to the primary database are required to use TLS.
Encryption at rest
- The primary database, Amazon Aurora PostgreSQL, is encrypted at rest with an AWS Key Management Service key.
- Files stored in Amazon S3 are encrypted at rest with AES-256. The buckets that hold store files, checkout assets, support attachments and mail data block all public access.
Network access, backups and logging
- The database accepts connections only from an allow-list of network addresses.
- The primary database has automated continuous backups with point-in-time restore, and deletion protection is enabled.
- Application servers are backed up daily with AWS Backup.
- API activity in our AWS account is recorded by AWS CloudTrail across all regions.
Accounts and authentication
- Passwords are hashed with bcrypt at a cost factor of 12. We never store passwords in plain text.
- Sessions. Session tokens are held in cookies marked
HttpOnly,SecureandSameSite=Lax, so page scripts cannot read them, and the access token is kept in memory rather than in browser storage. On our servers, session tokens are stored only as SHA-256 hashes. - Sign-in protection. Sign-in, registration, sign-in-link and verification-code requests are rate limited.
- Sign in with Google. A Google ID token is verified — including that it was issued for PlatformDTC — before an account is signed in.
- Customer accounts on storefronts. Customers sign in with a one-time code sent by email. The code expires after 5 minutes and allows 3 attempts.
- Integration credentials. Credentials merchants connect for payment providers and tracking pixels are encrypted before they are stored.
Agent Gateway
Agents — PlatformDTC's own and the ones merchants build — take actions on a store through the Agent Gateway API. These controls apply to every call:
- Scoped keys. Agent keys begin with
sq_agt_, carry about 256 bits of randomness, and are shown once, at creation. We store only a SHA-256 hash of each key. A key carries scopes and can be limited to specific stores; a request outside its scopes is refused. Keys can be revoked or rotated at any time, and managing keys requires theagent:adminscope. See Authentication and Scopes. - Audit log. Every call is recorded with the key, account and store, the method and path, the scopes used, the response status, the request and idempotency identifiers, the duration and the source IP address.
- Idempotent retries. A client that sends an
Idempotency-Keyheader gets the original response back when it retries, for 24 hours. Reusing a key with a different request body is rejected. See Idempotency. - Human approval. A key can be created to require approval. Its spend actions — sending a campaign, for example — are not dispatched; they wait as
pending_approvaluntil a person approves or denies them. See Approvals. - Signed webhooks. Webhook deliveries carry an HMAC-SHA256 signature of the raw request body in the
X-Webhook-Signatureheader, so a receiver can verify that a delivery came from PlatformDTC. See Webhooks.
Availability
Current service status, and uptime and response times measured separately for storefronts, checkout, the merchant dashboard, the API, notifications and email delivery, are published at status.platformdtc.com. You can subscribe to status updates there by RSS or Atom.
Reporting a vulnerability
If you believe you have found a security vulnerability in PlatformDTC, email security@platformdtc.com. We acknowledge reports within 48 hours.
Our Vulnerability Disclosure Policy sets out what is in scope, how to test safely, and the safe harbor we offer researchers acting in good faith. Our security contact is also published in security.txt.