> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/developers-guides/pass-architecture/infrastructure.md).
# Infrastructure
## 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.
### At a glance
* **Cloud**: Microsoft Azure (managed services, private networking)
* **Edge**: Cloudflare (CDN, WAF, DDoS protection, TLS)
* **Data**: Cosmos DB, Azure Data Explorer, Blob Storage
* **Secrets**: Azure Key Vault
* **Async**: Azure Service Bus
* **Real-time**: Azure Web PubSub (WebSocket-based real-time communication)
* **Security model**: tenant isolation, signed passes, optional webhook signing
### 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.
### Infrastructure components
The platform is built on managed Azure services inside private networks. Azure App Service hosts the stateless API and frontends with horizontal scaling. Azure Service Bus runs asynchronous workloads and background processing.
Operational data is stored in Cosmos DB with tenant-level partitioning. Events and analytics are collected in Azure Data Explorer. Configuration and batch files are stored in Azure Blob Storage. Secrets and certificates are stored in Azure Key Vault.
Tenant isolation is enforced at every layer. Each tenant uses its own Apple and Google wallet accounts. Passes are signed using tenant-owned certificates and keys. Apple updates use APNs, and Google updates use Google Wallet APIs.
High-level architecture of the platform across edge, application, data, and integration layers.
The architecture is modular and opt-in. Capabilities are enabled per tenant based on actual needs. Integrations are available through connectors, APIs, and webhooks.
Custom business logic can be implemented with a sandboxed `nil.js` runtime. This preserves security boundaries and platform stability. PII is not stored long-term unless you explicitly configure it.
### Architecture principles
The platform follows a modular, opt-in design. All services, integrations, and background components are disabled by default and enabled only when required by a tenant. This limits complexity, cost, and attack surface to what each customer actually uses.
Security is foundational and based on a zero-trust model, least-privilege access, and private networking for all internal services. These controls apply consistently across all enabled components.
Tenant isolation is enforced at every layer — APIs, data stores, caches, and messaging infrastructure — ensuring strict separation between customers.
The compute layer is stateless, enabling horizontal scaling and resilience. Asynchronous processing decouples workloads and improves reliability for background operations and integrations.
Observability is built in, with events, logs, and metrics available for both internal monitoring and tenant-level reporting.
### 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 are stored in tenant-partitioned data stores. No cross-tenant data access is possible at runtime.
* **Configuration**: each tenant's pass templates, connector settings, and operational rules are stored as versioned YAML configuration files. Changes to one tenant's configuration have no effect on other tenants.
* **Credentials**: each tenant requires its own Apple Developer account and Apple Pass Signing Certificate, and its own Google Wallet issuer account. Wallet credentials are not shared between tenants.
* **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 validated against the tenant context. A key scoped to one tenant cannot access another tenant's data.
Most customers operate one tenant. Enterprise customers may operate multiple tenants, often one per brand, region, or program that requires hard isolation. A tenant is not a folder or sub-account inside a shared workspace. It is a fully isolated operating environment.
{% hint style="info" %}
A user authenticated to the platform but not assigned to a tenant cannot access any data. Authentication and tenant access are separate checks.
{% endhint %}
### Environments
The Wallet Crew runs as a single multi-tenant platform across three environments.
| Environment | Purpose | Access |
| ----------- | ---------------------------------------------------------- | ---------------------------------------------------- |
| `prod` | Live customer operations | Customers, partners, end users |
| `qa` | Staging — mirrors production topology and security posture | Internal teams and staging customers |
| `dev` | Internal development and testing | Engineering teams only — not accessible to customers |
All customer tenants are provisioned in both `qa` and `prod`. `dev` is not available to customers.
#### Isolation between environments
Environments are fully isolated. They use separate VNets, separate data stores, separate secrets in Azure Key Vault, separate API keys, and separate pass records. Production data is never seeded into `dev`.
#### Configuration portability
Tenant configuration files carry no secrets and can be copied between environments. Secrets, live pass data, and installed wallet state are not portable.
#### Wallet certificates
Wallet credentials are stored per tenant per environment. In some configurations, a customer can choose to use the same Apple Wallet certificate in both `qa` and `prod`. This is a controlled customer choice, not a cross-environment data merge.
### Application components
The platform is composed of several layers that work together at runtime.
#### Configuration
Tenant configuration, including connector settings and pass templates, is stored as versioned YAML files in Azure Blob Storage. Files are validated using JSON Schema and logical tests on save. A distributed cache holds active configuration per tenant and is invalidated whenever a configuration timestamp changes in Blob Storage, ensuring consistent runtime behavior across all running instances.
#### API
The API is built with .NET 10 and follows a REST design optimized for additive evolution, maintaining backward compatibility across versions. Authentication varies by endpoint: OAuth2 (JWT) for authenticated flows, API keys for partner integrations, and public endpoints where appropriate. Polly is used for retries, circuit breakers, and throttling. Rate limits are applied per tenant.
#### Frontends
The public frontend and the back-office are built with React 19, using Material-UI, react-hook-form, react-router, and i18next. Static assets are served via App Service and cached through Cloudflare CDN. Tenant-specific branding and layout are fetched via API at runtime.
#### Background processing
Asynchronous workloads follow CQRS patterns. Operational messages are queued or published to Azure Service Bus topics and consumed by Azure Functions. Retry policies and Dead Letter Queues ensure reliability. Tenant-scoped queues and topics provide processing isolation.
#### Real-time communication
Azure Web PubSub provides WebSocket-based real-time communication for features that require push-based updates to connected clients.
### Operational resilience and scale
#### Scaling
The platform is hosted on Azure App Service with horizontal scaling enabled. Each environment runs a minimum of two active instances for high availability. Automatic scaling can expand capacity to eight instances based on sustained CPU load. Under normal conditions, average CPU usage stays below 20%, with peak usage around 75%.
#### Development and release lifecycle
The development and release lifecycle runs through Azure DevOps. Continuous Integration pipelines automatically run unit tests, code quality checks, and software composition analysis on every build. Deployments to production use App Service deployment slots, allowing new versions to be validated before going live. Health checks are continuously monitored during deployment, and an automatic rollback is triggered if anomalies are detected. All build and deployment steps run in a secretless manner using Azure Managed Identity.
#### Disaster recovery
Disaster recovery relies on Azure-managed capabilities. Cosmos DB and Azure Blob Storage include built-in backup and recovery. The platform targets 99.5% overall availability. Current and historical service status is publicly available at .
### Outgoing IP addresses
When The Wallet Crew makes outbound API requests (egress traffic) to your 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. You will see them as the client/source IP in your 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 you configure.
You only need these IPs when you restrict inbound access to your own endpoints. This is common for corporate firewalls, API gateways, and private partner APIs.
{% hint style="info" %}
If you call The Wallet Crew APIs from your systems, you usually don’t need allowlisting. Your outbound traffic originates from your own network.
{% endhint %}
Allowlist the IP for the environment you use. If you use multiple environments, allowlist each relevant IP.
* **Production (`prod`)**: `20.111.54.22`
* **Quality Assurance (`qa`)**: `51.11.248.115`
* **Development (`dev`)**: `40.66.49.162`
#### Webhooks: don’t rely on IPs only
IP allowlisting reduces noise and blocks obvious unsolicited traffic. It does not prove the request is authentic.
You should still verify webhook authenticity at the application layer.
The Wallet Crew can sign webhook requests using `x-neostore-signature` (HMAC SHA-256). This lets you verify the payload was sent by us and not modified.
See [Webhooks](/developers-guides/integration-guides/webhooks.md) for configuration and signature verification.
### Data handling
The Wallet Crew stores configuration and operational pass data needed to run the service. Your business source-of-truth usually stays in your 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 your configuration and use case.
When PII is required — for example, when an email address is used as a pass identifier — it may be held temporarily in a distributed cache for a configurable duration, below 10 minutes by default, after which it is automatically evicted. No PII is persisted in logs, analytics systems, or long-term storage unless explicitly configured by the tenant.
### 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 you are hitting the right environment. Also confirm your 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 our 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 your account team to request it.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.thewalletcrew.io/developers-guides/pass-architecture/infrastructure.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.