Security at Zillo

Where we sit

Zillo is built and operated by Pocket Labs Pty Ltd in Sydney, Australia. We're a multi-tenant SaaS where merchants sell gift cards, vouchers, tickets, bookings, and memberships. Payments run through Stripe Connect (we never see card numbers); merchant and customer data sit in our own database, encrypted at rest, with access governed by the controls described below.

Our controls are aligned with ISO 27001 Annex A and the GDPR / Australian Privacy Principles. We're not formally certified to ISO 27001 today; this page describes the operational reality.

Encryption

• In transit: TLS 1.2+ on every public endpoint. Our domains are HSTS-preloaded, so browsers refuse to connect over plain HTTP. Certificates are provisioned by AWS Certificate Manager and rotated automatically.
• At rest: The application database (AWS RDS via Supabase) and object storage (S3) are encrypted with AES-256 using AWS-managed keys. Database snapshots and backups inherit the same encryption.
• Sensitive material: Passwords are stored as bcrypt hashes by our authentication provider. Developer API keys are only ever returned in plaintext at creation time — afterwards we store only the SHA-256 digest, with a constant- time comparison on every request. MFA backup codes are SHA-256 hashed and single-use.

Access control

• Per-merchant isolation: Every row in our database that belongs to a merchant carries a merchant_idand is protected by Postgres row-level-security policies. A merchant's data is never accessible to another merchant's session.
• Role-based access: Within a merchant account, users have one of three roles — owner, admin, staff — each with a documented permission scope.
• Two-factor authentication: Every user can enable TOTP-based 2FA from Settings → Account, with single-use backup codes.
• Developer API keys: Scoped per resource (e.g. orders:read, gift_cards:redeem), with optional IP allow-listing and per-key rate limits.
• Staff access:Zillo support staff cannot read merchant data by default. Access is granted on a time-bounded (60-minute) self-grant model with every access event written to an immutable audit log.

Payments

Zillo never stores card numbers, CVCs, or bank account details. All payment data is collected directly by Stripe via Stripe Elements / Stripe Terminal, which is PCI DSS Level 1 certified. We hold only the metadata needed to reconcile a charge: last four digits, brand, country, Stripe charge ID.

Webhooks & integrations

Outbound webhooks are signed with HMAC-SHA256 over the timestamp and request body so receivers can verify authenticity and protect against replay. Inbound integrations (Stripe webhooks, GitHub secret scanning, etc.) verify signatures before any processing.

Logging & monitoring

• Every authenticated request to the Developer API is logged with method, path, status, latency, IP, and an opaque request ID. Request and response bodies are never logged.
• Anomalous error patterns on an API key (sustained 4xx or 5xx rates) trigger a daily anomaly-detector cron that flags the key for review.
• Rate limiting is enforced per-API-key, per-merchant, and per-IP-prefix to protect the platform against credential stuffing and abuse.
• Staff grants, account-deletion requests, and customer data-subject requests are written to separate audit tables that aren't reachable from the merchant data plane.

Data handling & retention

• Customer data minimisation: We collect the fields a merchant needs to deliver the order — email is required; name, phone, and address are conditional on product type.
• API request log retention: 90 days, then a nightly cron prunes older rows.
• Merchant account closure: Owners can request deletion from Settings → Account. A 90-day grace period lets you cancel; after that, the account is removed from active systems and from backups within 35 days.
• Customer data requests:Customers can submit access / deletion / rectification requests directly to the merchant from the storefront. Merchants fulfill these from their dashboard inbox; if a merchant doesn't respond, Zillo can step in on the controller's behalf.
• Tax records: Order rows are retained (anonymised on the personal-data fields) for 7 years to satisfy Australian tax obligations.

Infrastructure & vendors

We run on AWS in Australia (ap-southeast-2). Our database is Supabase (Postgres on AWS). Transactional email is delivered via Amazon SES. The AI Builder uses Anthropic. The full sub-processor list is published at zillo.app/subprocessorswith last-reviewed dates and links to each vendor's documentation. Our processor obligations to merchants are set out in the Data Processing Addendum.

Software development

• All code changes go through code review, type-checking, and lint before merge.
• Dependencies are tracked via a locked package manifest and reviewed against published advisories before upgrade.
• Secrets are never committed; we rely on environment-managed configuration with rotation procedures for each secret type.
• Production deploys are reviewed and immutable; we don't allow ad-hoc edits to the running environment.

Incident response

If we discover a security incident that affects merchant or customer personal data, we notify affected merchants without undue delay — within 72 hours where GDPR Article 33 applies. The notification will include what was affected, what we know about cause, what we've done, and what (if anything) you need to do.

Email security@zillo.app if you believe you have evidence of an active incident.

Vulnerability disclosure

We welcome reports from security researchers. If you believe you've found a vulnerability in Zillo, please email security@zillo.app.

Good-faith safe harbour

We will not pursue legal action against researchers who:

• Act in good faith to identify vulnerabilities and report them to us privately and promptly.
• Make every reasonable effort to avoid privacy violations, data destruction, or interruption of service.
• Do not exploit the vulnerability beyond what is necessary to confirm its existence.
• Do not publicly disclose the vulnerability before we've had a reasonable opportunity to remediate (typically 90 days).

In scope

• zillo.app, www.zillo.app, dashboard.zillo.app, api.zillo.app, docs.zillo.app.
• Any subdomain of zillo.app that serves a Zillo merchant storefront.
• Our official iOS and Android mobile companion apps.

Out of scope

• Merchant custom domains (the merchant owns the domain; report domain-specific issues to the merchant).
• Stripe, Supabase, AWS, and other sub-processors — report directly to them. We'll happily co-ordinate.
• Findings that require a compromised end-user device, social engineering of Zillo staff or merchants, or physical access.
• Volumetric denial-of-service. Please don't.
• Issues already disclosed (e.g. missing rate limits on public marketing pages, theoretical CSRF where no state change occurs, clickjacking on pages without state-changing actions).

What to expect

• We'll acknowledge your report within 3 business days.
• We'll keep you updated as we triage and remediate, and we aim to resolve critical issues within 30 days.
• We don't pay bounties today, but we're happy to publicly credit reporters who want recognition.

Machine-readable disclosure metadata is available at /.well-known/security.txt.

Questions

Security questions: security@zillo.app
Privacy / data subject rights: privacy@zillo.app