This documentation is currently under development. Certain sections are not yet complete and will be added shortly.
For the complete documentation index, see llms.txt. This page is also available as Markdown.
ArchitectureReference

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.

Real-world examples
  • A partner needs the outbound IP to allowlist webhook delivery or connector traffic.

  • A security team needs to confirm that qa and prod are isolated.

  • A multi-brand deployment needs to understand whether tenants share wallet credentials or data stores.

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.

High-level architecture diagram showing the edge, application, data, and integration layers of The Wallet Crew
High-level architecture of the platform across edge, application, data, and integration layers.

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.

Environment
Purpose
Access

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.

Calls made to The Wallet Crew APIs usually need no allowlisting. That outbound traffic originates from the calling network.

Allowlist the IP for the environment in use. When several environments are in use, allowlist each relevant IP.

  • Production (prod): 20.111.54.22

  • Quality 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

Does The Wallet Crew use a single IP for everything?

No. It varies by environment. Some integrations can also have dedicated endpoints depending on how they are deployed and enabled.

I see another source IP. What should I do?

First, confirm the request is hitting the right environment. Also confirm the logs show the real client IP. Some setups log intermediary proxy IPs instead.

If it still differs, contact support with the endpoint and a timestamp.

Can The Wallet Crew connect to our systems through a VPN?

Yes, this can be configured on demand for strict network constraints. It is typically a dedicated setup with extra operational overhead. It can also introduce additional infrastructure and support costs.

Most customers prefer IP allowlisting and request signing instead.

Is there a Security Insurance Plan (SIP) available?

Yes. The SIP summarizes the security governance, controls, and responsibilities for operating The Wallet Crew. It’s the best starting point for vendor security reviews and internal risk assessment.

The Security Insurance Plan is available on request.

Is there a more detailed architecture reference?

A full technical architecture and security reference is available for customer IT teams and technical partners. Contact support or the account team to request it.

Last updated