Data Protection Policy

We process the minimum personal data required to deliver wallet passes and credit loyalty rewards. Every field we read from a connected commerce platform is consumed by a specific, documented purpose in our system. We do not collect speculative data for unrelated analytics or for resale.

What we tell merchants

Each connected store sees an itemised list of the personal data fields we access, the reasons for access, and the integrations that consume them — surfaced both at OAuth consent time and in the integration detail page of their wallet admin.

Customer name

Used to personalise wallet pass content and the welcome page after a customer enrols.

Customer email

The primary identifier we use to match a Shopify (or other platform) customer to a wallet member. Email is also used for transactional notifications when a customer has pending loyalty credits.

Customer phone

Optional secondary identifier and a fallback delivery channel when configured. Stored only when the merchant's signup form asks for it.

Customer address

Optional, used only when a merchant's signup form requests it for shipping or geographic targeting of campaigns. Address is never the primary identifier.

Order events

We receive order-level webhook events (fulfilled, cancelled, refunded) to credit and reverse loyalty points. We do not store full line-item details beyond what is required for the loyalty calculation and audit trail.

Each merchant goes through an OAuth grant flow that explicitly lists the access scopes we request. We do not silently widen scope after install. Customers' privacy choices (consent to be contacted, opt-outs) propagate from the connected platform — when a merchant marks a customer as opted out, we honour that flag on every downstream message and reward calculation.

Opt-outs we cannot apply

We do not sell customer data, and our system does not perform automated decision-making that has legal or similarly significant effects on customers. Where Shopify or a similar platform asks about opt-out for those activities, the question is not applicable to our processing.

Encryption at rest

All databases are AWS RDS instances with storage-level encryption enabled. Sensitive fields (OAuth access tokens, webhook signing secrets, third-party API keys) are additionally encrypted at the application layer before being written to disk, so a database snapshot alone is not enough to recover them.

Encryption in transit

All public traffic is TLS-only — HTTPS for the wallet admin, the wallet API, and the customer signup forms; HTTPS for every webhook we receive; HTTPS for every outbound call we make to commerce platforms. We reject non-TLS connections at the edge.

Backups

Database backups are taken on a schedule by AWS RDS. Backup snapshots inherit the same storage-level encryption as the live database. Backups are retained per a fixed schedule and are never shared outside the production AWS account.

Test and production isolation

Production data does not flow into the staging or development environments. Each environment has its own database, its own credentials, and its own Shopify app registration. Engineers debugging an issue in staging see synthetic test fixtures, not real merchant customer records.

Access to systems that hold customer data is limited to the Shakewell engineering team, and within that team is granted on a role basis rather than a per-individual basis. Production database access requires a separate credential set from staging and is logged centrally.

Password requirements

Staff accounts on Shakewell-managed services require strong passwords (minimum length, complexity, no reuse against known-breached credentials) and where supported by the provider, multi-factor authentication is enforced. Shared credentials are not used.

Access logging

Every read or write against the wallet API by an authenticated admin user is recorded with the actor, the resource, and the timestamp. The audit log is retained for a fixed period and reviewed periodically.

Our data loss prevention strategy is layered and aims to ensure that customer data cannot be exfiltrated, lost, or accidentally exposed by any single failure.

Network egress

Production database hosts are not directly reachable from the public internet. All outbound integrations call known commerce platform endpoints over TLS; arbitrary outbound traffic from production worker hosts is not permitted in normal operation.

Credential isolation

OAuth access tokens, webhook signing secrets, and third-party API keys are stored encrypted at rest and are never written to application logs. Stack traces and error reports are filtered against a deny-list of sensitive payload patterns before being persisted.

Public response shape

Production API responses never include stack traces, file paths, or framework internals. Error responses surface only a generic message and an error code. The recent fix tracking ticket 86d33m9e7 hardened this gate.

Schema-level minimisation

Tables that hold customer data have explicit casts and only the columns required for the documented purpose. Sensitive columns use Laravel's encrypted cast so the at-rest ciphertext is what touches disk.

Backup posture

Backups are encrypted, scoped to the production AWS account, and never restored into a non-production environment. Restoration is treated as a recovery event, not a routine operation.

We maintain a documented incident response procedure that engineers follow when a suspected security event is identified. The procedure prioritises containment, notification, and learning.

Detection

Authentication failures, unusual API patterns, and unexpected error spikes are surfaced through application logs and platform monitoring. An on-call engineer is responsible for reviewing escalations.

Containment

On confirmed events the first action is to contain — rotate any potentially compromised credentials, disable affected access tokens, and isolate the suspect component from production traffic. Containment runs before broader investigation.

Merchant notification

If customer data of a connected merchant is affected, we notify that merchant as soon as we have a confirmed scope assessment, with the facts we know at the time and a commitment to follow up as the investigation completes.

Post-incident

Every incident is recorded with a written timeline, contributing causes, and at least one durable action item assigned to a named owner. Recurring root causes drive prioritised engineering work.

We retain personal data only as long as it is needed to deliver the wallet pass service to the connected merchant. We do not retain customer data after the merchant disconnects beyond what is needed for audit, billing, or legal obligations.

GDPR webhooks

We implement Shopify's three mandatory privacy webhooks (customers/redact, customers/data_request, shop/redact) and the equivalent endpoints on other connected platforms. When a redact request is received, customer records and any derived data are deleted within the time bound specified by the platform.

Disconnect

When a merchant disconnects their store, we stop receiving and processing new events from that store immediately. The audit trail of past events is retained for the period specified by the merchant's agreement.

Individual customers should direct access, correction, and deletion requests to the merchant whose store they shop with. Shakewell acts as a data processor for that merchant. We support every connected merchant in answering customer requests within the timeframes their regulator imposes.

Shakewell Wallet does not currently hold a formal third-party security certification (SOC 2, ISO 27001). Our controls are documented in this policy, and we are willing to share specific architectural detail with any merchant who asks under a mutual confidentiality agreement.

Questions about this policy or about how we handle a specific merchant's customer data can be sent to hello@shakewell.com.