Security at Zillo

We take the security of your store — and your customers' data — seriously. This article walks through the protections that are on by default, and the things you can do yourself to keep your account safe.

For the technical / auditor-facing version, see zillo.app/security. The public privacy policy is at zillo.app/privacy.

How Zillo keeps your data safe

How customer payment data is handled

Card numbers and CVCs never reach Zillo. Every checkout, every refund, every POS tap goes directly to Stripe via Stripe Elements or Stripe Terminal. Stripe is PCI DSS Level 1 certified — the highest level for payment processors.

What Zillo stores on your behalf:

• The last four digits of the card and the card brand (so you can reconcile a charge).
• The Stripe charge ID and customer ID (the references we use to issue refunds).
• The amount, currency, application fee, and status.

What Zillo never sees:

• Full card numbers
• CVCs / security codes
• Bank account details (for payouts — held by Stripe in your Connect account)

This means your customers can shop on your Zillo storefront with the same payment-data assurance they'd get from Stripe directly.

Setting up 2FA on your account

Two-factor authentication (2FA) means even if someone learns your password, they can't sign in without your phone. Zillo supports time-based one-time passwords (TOTP) via any standard authenticator app — Authy, 1Password, Google Authenticator, Bitwarden, etc.

1. Open Settings → Account in your dashboard.
2. Click "Set up 2FA".
3. Scan the QR code with your authenticator app.
4. Enter the 6-digit code from the app to confirm.
5. Save your backup codes. You'll get 8 single-use codes. Print them or save them in your password manager — they're your only way back in if you lose your phone.

After 2FA is on, every sign-in requires the 6-digit code from your authenticator. Backup codes work in place of the authenticator for emergency recovery.

API key best practices

Developer API keys live under Settings → Developers → API keys. A few practices that materially reduce blast-radius if a key is ever leaked:

• Scope keys to what they need. A key that only reads orders shouldn't have gift_cards:redeem. We make scope selection explicit when you create the key.
• Use a test key first. zk_test_… keys point at your test mode merchant; they can't touch real customer data or money.
• IP-restrict production keys. If your integration runs from a known IP range, add it as an allow-list when you create the key. We'll reject any request from outside that range, even if the key is correct.
• Rotate on suspicion, revoke immediately on confirmation. Revoked keys stop working instantly — there's no caching delay.
• Watch the anomaly alerts. If a key starts producing an unusual rate of 4xx or 5xx responses, you'll get an email. Investigate before re-using.

What to do when you receive a customer data request

Under the GDPR (EU/UK) and the Australian Privacy Act, customers have the right to ask for a copy of the data you hold on them, to have it deleted, or to have it corrected. Customers can submit these requests directly from your storefront — there's a "Data request" link in the storefront footer that opens a verified web form.

When a customer submits a request, both you and the customer receive an email. The request lands in your dashboard at Customers → Data requests.

1. Verify the customer. The storefront form already requires email verification before the request reaches you, but spot-check that the email matches an order in your records.
2. For access requests: click "Fulfill" and we'll generate a JSON download covering every order, gift card, ticket, voucher, booking, and membership tied to that email — plus a copy of the customer record itself.
3. For deletion requests: click "Fulfill" and we'll anonymise the personal-data fields on every record (name → [redacted], email → [redacted], phone → [redacted]) while keeping the financial fields needed for your tax records. The customer row itself is deleted.
4. Respond to the customer. We'll send them a confirmation email automatically; if you want to add a personal note, copy them on a reply.

You have 30 days under GDPR (and equivalent timeframes under Australian and NZ privacy law) to respond to a verified data subject request. The dashboard shows a countdown timer per request so you don't miss the deadline.

Closing a Zillo account

If you decide to close your Zillo store entirely, an owner can request deletion from Settings → Account → Close account.

1. Confirm by typing your store slug. This prevents accidental clicks.
2. Your storefront becomes "Closing soon" immediately. No new orders can be taken; existing customers can still redeem their gift cards / tickets until your scheduled deletion date.
3. You have 90 days to cancel. Just click "Restore my account" in the same place — everything comes back.
4. After 90 days, the account is permanently deleted from active systems. Backups are purged within a further 35 days.

Some records are retained (in anonymised form) for 7 years to satisfy Australian tax obligations — the personal-data fields are wiped; the financial rows stay so your historical accounts reconcile.

Reporting a security issue

If you believe you've found a vulnerability — a way to access another merchant's data, a way to bypass authentication, an XSS in the dashboard — please email security@zillo.app.

Our full vulnerability disclosure policy is at zillo.app/security#disclosure:

• We acknowledge reports within 3 business days.
• We won't pursue legal action against good-faith researchers.
• We don't pay bounties today, but we're happy to publicly credit reporters who'd like recognition.

For machine-readable contact info we publish security.txt at the standard well-known path.

Next steps