WalletWallet API
WalletWallet API Navigation
View live demo Get API Key Dashboard

Security Overview

Last updated: 1 September 2026

How WalletWallet, operated by Proof of Stake SRL, protects the data our customers and their end users entrust to the Service. Written for security reviewers; the contractual commitments live in the Data Processing Agreement and the Privacy Policy.

Infrastructure

The Service runs entirely on Cloudflare’s managed platform: Workers for compute, D1 for the relational database, R2 for pass object storage, and Queues for asynchronous work. WalletWallet operates no servers, virtual machines, or container hosts of its own, so there is no operating system, disk, or network layer for us to patch; Cloudflare maintains the platform beneath the application code.

Data residency

Customer and pass data is stored at rest in Cloudflare’s European Union region: the primary database (Cloudflare D1) and the pass object store (Cloudflare R2) both run in Cloudflare’s EU location, with no replicas outside it. Request processing runs on Cloudflare’s global edge network, so compute is not EU only, and traffic is encrypted in transit throughout. For the transfers this involves, Cloudflare provides the EU Standard Contractual Clauses and holds an EU Cloud Code of Conduct verification.

Encryption

  • In transit: all API, dashboard, and website traffic is served over TLS, as are our connections to Apple Push Notification service and the Google Wallet API.
  • At rest: Cloudflare encrypts stored data at rest across the platform.
  • Signing credentials: on Bring Your Own Cert plans, customer-supplied Apple certificates, APNs keys, and Google service-account credentials are additionally encrypted at the application layer with AES-256-GCM under a master key held as a deployment secret. Each ciphertext is cryptographically bound to the owning account, so a blob moved to another tenant’s record fails authentication instead of decrypting.

API keys and pass tokens

  • API keys are randomly generated 128-bit bearer tokens (ww_live_…), unique per account, minted only at signup and rotation. Rotation disables the previous key.
  • Each pass carries a server-generated random authentication token that installed passes use to authorise update checks. Callers cannot set or read another pass’s token.
  • The dashboard has no passwords to steal: sign-in is a one-time code sent by email, or Google sign-in.

Tenant separation and access control

Every stored record and object is keyed to the owning account, and authorisation checks run on every request. Production access is limited to authorised personnel, and operational tooling uses scoped, least-privilege API tokens. Unauthenticated endpoints (device log submission, OAuth authorisation) are rate limited per IP at the edge.

Availability and recovery

The primary database supports point-in-time recovery covering the previous 30 days. Signed pass files are rebuilt automatically from the stored canonical pass body if a stored copy is missing. An independent scheduled health-check worker monitors the API. We do not currently publish an uptime page or offer a general SLA; Business plans include a committed SLA.

Retention and deletion

Retention follows Section 7 of the Privacy Policy: account data for the life of the account, deletion within 30 days of request, Apple Wallet error logs for at most 7 days, verification codes expiring within minutes. Revoking a pass voids it on both wallet platforms; by Apple’s and Google’s design, a pass already installed on a device cannot be removed remotely by any provider.

Certifications

If a certification is a requirement for your review, contact us at [email protected].

Reporting a vulnerability

Email [email protected] with the details and steps to reproduce. We confirm receipt within 2 business days, keep you informed while we investigate, and do not pursue action against good-faith research that respects user data and service availability.