Security and infrastructure
Review The Wallet Crew security model, tenant isolation, environments, and outbound IP allowlisting.
Security and infrastructure
The Wallet Crew is a cloud-native, multi-tenant Wallet as a Service (WaaS) platform hosted on Microsoft Azure in Europe. It powers pass creation and updates for Apple Wallet and Google Wallet.
Public traffic is routed through Cloudflare for WAF protection and rate limiting. Cloudflare also provides CDN caching and TLS termination.
Why this architecture matters
Infrastructure choices directly affect security reviews, integration setup, and operational troubleshooting.
Tenant isolation defines who can access data and credentials. Environment isolation defines how testing and production stay separate. Outbound IPs matter when partner systems restrict inbound traffic. Managed services reduce operational overhead while keeping the platform scalable and resilient.
Platform security overview
The Wallet Crew uses managed cloud services, network controls, and tenant-scoped access controls. The platform separates tenant data, credentials, configuration, and API access.
Passes are signed with credentials configured for the relevant tenant. Apple Wallet and Google Wallet updates use their supported delivery services.

The platform supports integrations through connectors, APIs, and webhooks. Capabilities are configured for each tenant’s requirements.
Tenants
A tenant is the primary isolation boundary in The Wallet Crew. All platform data and operations are scoped to a tenant.
Data: passes, identifiers, metadata, events, and analytics remain scoped to the tenant.
Configuration: pass templates, connector settings, and operational rules are managed independently for each tenant.
Credentials: wallet credentials are configured and managed within the tenant scope.
Users and permissions: back-office roles and permissions are evaluated per tenant. A user can be assigned to multiple tenants; each tenant assignment is independent.
API calls: every API request is evaluated in its tenant context.
Most customers operate one tenant. Larger programmes may use separate tenants for brands, regions, or other isolated programmes.
Environments
The Wallet Crew provides separate quality-assurance and production environments for supported tenant configurations.
prod
Live customer operations
Customers, partners, end users
qa
Staging and integration testing
Approved customer and partner users
Isolation between environments
Environments use separate data, credentials, API keys, and pass records. Test with qa before using production credentials and passes.
Configuration portability
Configuration can be promoted between environments without copying live pass data or installed wallet state.
Outgoing IP addresses
When The Wallet Crew makes outbound API requests (egress traffic) to partner systems or to third-party providers, those requests come from fixed public IP addresses. These are the source IPs used by requests leaving The Wallet Crew. They appear as the client or source IP in the receiving gateway, WAF, or application logs.
These IPs apply to calls initiated by The Wallet Crew, such as connector requests, webhook delivery, and any server-to-server callbacks configured on the tenant.
These IPs are only needed when inbound access to the receiving endpoints is restricted. This is common for corporate firewalls, API gateways, and private partner APIs.
Allowlist the IP for the environment in use. When several environments are in use, allowlist each relevant IP.
Production (
prod):20.111.54.22Quality Assurance (
qa):51.11.248.115
Webhooks: don’t rely on IPs only
IP allowlisting reduces noise and blocks obvious unsolicited traffic. It does not prove the request is authentic.
Webhook authenticity should still be verified at the application layer.
The Wallet Crew can sign webhook requests using x-neostore-signature (HMAC SHA-256). The signature proves that the payload was sent by The Wallet Crew and was not modified.
See Webhooks for configuration and signature verification.
Data handling
The Wallet Crew stores configuration and operational pass data needed to run the service. The business source of truth usually stays in the brand’s own systems and is accessed via integrations. This includes CRM, ticketing, loyalty, and marketing automation platforms.
PII is not stored by default. When PII storage is required, it is driven by the tenant configuration and use case.
Data handling depends on the tenant configuration and use case. Do not place unnecessary personal data in pass fields, identifiers, webhook payloads, or integration logs.
FAQ
Last updated

