Security & trust
Built to protect the data behind every pass.
Wallet passes carry real customer data, and a pass-signing key is as sensitive as anything you'll hand a vendor. Here's specifically how both are held - including the parts we don't have yet.
Talk to our teamAt a glance
Security built into the platform.
Not a policy document - these are properties of how the thing is built.
No client can write to your data
Every table has row-level security enabled, and there is not one insert, update or delete policy for a browser credential. Reads are scoped to the accounts you belong to; writes only ever happen server-side, behind an explicit permission check.
Signing keys are unreadable, even to you
Your Apple pass-signing private key is encrypted with AES-256-GCM under a key held in AWS Secrets Manager - and its table is deny-all, so no browser credential can reach the ciphertext at all.
Encryption in transit, plus at the application layer
All traffic runs over TLS. On top of the platform's own at-rest encryption, credentials we hold for you - CRM tokens, certificates, integration keys - are separately encrypted with AES-256-GCM before they ever reach the database.
Hashed API keys
Keys are 192 bits of randomness, stored only as a one-way SHA-256 hash, and shown once at creation. Revoking one takes effect on the next request, with no cache to wait out.
Signed webhooks
Every delivery is signed with HMAC-SHA256 over the exact request body, so you can verify it genuinely came from PocketPass before you act on it.
Wallet push over mutual TLS
Apple Wallet updates authenticate with your pass-signing certificate as a client TLS certificate - never a shared bearer secret. Connections are pooled per certificate, so no account's credential can ever serve another's pushes.
Google's callbacks are cryptographically verified
Save and remove callbacks are checked against Google's published signing keys and bound to our issuer id, so a forged callback can't change what your account is billed for.
Roles, and optional two-factor
Invite teammates as admin, editor or viewer - a viewer cannot change anything. Each person can turn on TOTP two-factor with single-use recovery codes.
In detail
For the person doing the vendor review.
Specific enough to check. If your questionnaire needs more, ask - we'll answer it properly.
How your data is kept apart
Every table in the database has row-level security switched on. What matters more is what the policies allow: members can read rows belonging to accounts they're a member of, and that is all. There is no policy anywhere that lets a browser credential insert, update or delete anything.
- Row-level security enabled on every table, with no exceptions
- Zero client-writable tables - every write is server-side, after a permission check
- Tables holding signing keys have no read policy at all, for any credential
- Your account's data is reachable only through a membership you can see and revoke
How credentials are stored
Anything we hold on your behalf - a CRM's OAuth tokens, an Apple pass-signing private key, an integration key - is encrypted with AES-256-GCM before it's written, under a 256-bit key that lives in AWS Secrets Manager and never in the database. A database compromise on its own yields ciphertext.
- AES-256-GCM with a fresh random IV per value, and an authentication tag
- The encryption key is held in AWS Secrets Manager, separate from the data
- Runtime secrets load at boot and are never logged - only a count is
- Amazon SES sends our email under an IAM role, so there is no mail API key to steal
How the wallet pipeline is authenticated
The two places a wallet platform talks to us are both cryptographically verified, in both directions. This is the part most pass platforms skip, and it's the part that decides whether someone else can change what's on your customer's phone.
- Apple push authenticates with mutual TLS using the pass-signing certificate itself
- Push connections are pooled per certificate fingerprint, never per host - one account's certificate cannot serve another's
- Google's save and remove callbacks are verified against Google's published signing keys, then bound to our issuer id
- An expired callback is rejected outright, and an unverifiable one is never treated as success
Who can get in
Access is a membership on an account, with a role attached. Nothing is shared between accounts, and everything a person can reach follows from a membership an admin can remove at any time.
- Three roles - admin, editor, viewer. A viewer can look, and change nothing
- Only admins manage the team, billing and your Apple certificate
- The last admin on an account can't be removed or demoted by accident
- Optional TOTP two-factor per person, with single-use recovery codes
- API keys are per-account, hashed, scoped read/write on every endpoint, and revocable instantly
What happens when something fails
Delivery is at-least-once and designed to be inspectable. When a webhook of yours is down, we keep trying on a published schedule and show you every attempt rather than quietly dropping it.
- Webhook retries back off 30s, 1m, 2m, 4m, 8m across six attempts
- Every attempt is recorded with its response status and error, visible in your dashboard
- Each delivery carries a stable id so you can safely de-duplicate on your side
- Background work runs on a managed queue with a dead-letter queue behind it
When we look at your account
We'd rather say this plainly than leave you to guess. PocketPass staff can enter a customer account to help with a support issue. When that happens it is recorded, and it is visible to you at the time.
- Support access is recorded in an internal audit log, on entry and on exit
- A banner shows in the dashboard for the whole time it's active
- The staff console is unlisted - a non-staff account gets a 404, not a locked door
- Ask us for the record of access to your account at any time
Infrastructure
PocketPass runs on established, well-audited providers rather than self-hosted, hand-rolled systems.
Certifications, honestly
PocketPass does not hold a SOC 2 or ISO 27001 certification today, and we'd rather tell you that here than have you find out three weeks into a procurement cycle. What we can do is answer a vendor security questionnaire properly, walk your team through any of the above in detail, and talk about data residency and contractual terms.