How TravelPass Group manages PCI compliance with GraphQL and WunderGraph Cosmo
State of GraphQL Federation 2026
How are teams governing schema changes, handling production traffic, and measuring Federation success? Share your experience and get early access to the full report. For every valid survey completed, we'll donate $30 to UNICEF .
TL;DR
TravelPass Group is a travel booking platform whose backend services handle a substantial amount of PCI data that cannot be available to client applications. They keep one federated graph as the single source of truth anyway, by running the self-hosted Cosmo Router: request and response data exchanged through the Router never leaves their infrastructure, and WunderGraph has no access to the Router instance. In that hybrid setup the Cosmo managed service receives only request metadata, which cannot be linked back to actual payloads, and the safeguard is built in by design rather than configured. Namespaces and label matchers then control which federated graph and subgraphs each group of consumers can reach, so app developers and customers get schemas without the sensitive parts. TravelPass were early adopters of GraphQL and ran Apollo before Cosmo. Backend Tech Lead Tyler Hawkins says it only took about a day to reconfigure everything and get started with Cosmo, and that Cosmo was so similar to their old provider that there was not much of a learning curve. The reason given for the quick process is that resemblance between the two products.
Utilizing Cosmo's self-hosted router empowers us with direct control over our data. This enables necessary scalability according to our requirements and ensures absolute PCI compliance, a crucial aspect of our operations. -Tyler Hawkins, Backend Tech Lead at Travelpassgroup.com
Let's examine GraphQL's fundamental promise:
With a single query, receive precisely what you require and avoid excess data.
Amazing concept, right? However, if you've attempted to incorporate GraphQL across an entire engineering team, you might've quickly realized that achieving this objective is more complex than it sounds. For every developer in the organization to get everything they need in a single query, all possible required data must exist within one graph.
A single graph enveloping all data might seem implausible, especially from a compliance standpoint. This was one of Travel Pass's most significant obstacles when they expanded their use of GraphQL. As a travel booking platform catering to millions of global customers, their backend services handle a substantial amount of PCI data that can't be available to our client applications.
One graph = equals one endpoint, meaning client apps could access everything, including cardholder details and other sensitive data, right?
Surprisingly, not necessarily. With a Federated Graph and a self-hosted router, we can contain all our data and services, including the sensitive ones, within our federated graph, yet selectively determine which graphs are available to different groups, such as app developers. In this post, we'll guide you on how Travel pass achieved PCI compliance, and how you can replicate it employing namespaces with Cosmo Studio and the self-hosted Cosmo Router!
It's important to note that Travel Pass group were early adopters of GraphQL and were using Apollo GraphQL before WunderGraph Cosmo.
Travel Pass Group is a company dedicated to enhancing the travel booking experience. They specialize in connecting travelers with a wide range of travel options, enabling them to explore new places and cultures with ease. TravelPass Group has been acknowledged for its rapid growth and workplace culture by several prestigious lists and awards.
They've always been at the forefront of technology adoption, even being an early adopter of GraphQL before it gained widespread popularity. They embraced GraphQL and Apollo GraphQL as their preferred tools for data management and API development.
To understand how Travel Pass Group (TPG) was able to achieve total data sovereignty and remain PCI compliant. It's important we understand how Cosmo's architecture works and what information is shared between the studio and the router.
The architecture diagram displays our Hybrid SaaS model . This model comprises of the customer-hosted router and our hosted studio. To detail, everything below the red line, namely the router, is under your management and hosting. Conversely, we at Wundergraph take care of everything above the red line, which includes hosting the studio.
But even though this is a SaaS model, how was Travel Pass Group able to achieve total data sovereignly and remain PCI Compliant?
By default, your sensitive information is segregated from the Cosmo Managed Service.
Cosmo in its hybrid set-up (Router hosted by you, analytics and tracing data stored in Cosmo Managed Service) means that we receive and store nothing but request metadata. This metadata cannot be linked to or reverted into your actual request payloads, and is used solely to provide the tracing and analytics insights of Cosmo Studio.
Any information (i.e. request / response data) exchanged between different APIs through your Cosmo Router never leaves your infrastructure where the Router is being hosted. WunderGraph is without any access to your Cosmo Router instance.
This privacy safeguard is implemented with WunderGraph Cosmo by design and not dependent on configuration or individual customization, which means that it cannot be - intentionally or by accident - circumvented or switched off.
There also is no scenario where WunderGraph would need to host or access your Router. These measures ensure you stay compliant with data privacy regulations and regulatory requirements, e.g. GDPR, PCI, HIPAA etc.
WunderGraph Studio is also SOC2 compliant.
WunderGraph Cosmo: The Open-Source GraphQL Federation Solution
It's very important that we have a solution that gives us a secure environment, where we can stay PCI compliant as well as have control over our traffic -Tyler Hawkins, Backend Tech Lead at Travelpassgroup.com
Now that we have a clear understanding of Cosmo and its architecture. Let's talk about how Travel Pass Group uses its federated graph as a single point of truth but can expose certain graphs to customers without exposing sensitive data.
As a single source of truth, our federated graph schema contains everything, including sensitive data. So, we can’t just directly have every customer application query our GraphQL endpoint for the entire federated graph. Instead, we need to define which federated graph specific applications can access. We can create Namespaces in Cosmo Studio.
Namespaces are a way to isolate your federated graphs and subgraphs. They are the way to group graphs in different environments, such as production and staging.
By using Namespaces and label matchers, we can ensure we expose the correct federated graph and subgraphs to our customers. This eliminates touchpoints with sensitive information, which is better for all parties involved. We can expose different GraphQL schemas to different parties based on a policy that we set.
That's it. You can apply Namespaces through the CLI.
With Cosmo we were able to get things up and running pretty smoothly. Cosmo was very similar to our old provider so there wasn't much of a learning curve. It only took us about a day to reconfigure everything and get started with Cosmo. -Tyler Hawkins, Backend Tech Lead at Travelpassgroup.com
Transitioning from Apollo to Cosmo took us around one day. The reason for this relatively quick process was the resemblance between the two products, with many of Cosmo's features mirroring those in Apollo. This resulted in minimal disruption due to a reduced learning curve, as only some elements were unfamiliar.
One feature of Cosmo that we found pretty valuable and relished was the labels aspect. This feature provides a systematic way to fragment and comprehend our complex graph better, making it much simpler for us to utilize internally. By using labels, we can tear down the complexity of our graphQL schema into more manageable parts, enhancing our efficiency and comfort in using the system.
We now have cosmo running in production and so far are very happy with the migration and results.
Cosmo's self-hosted router allowed Travel Pass group to stay PCI compliant while separating the complex schema into more manageable sections. The migration process only took Travel Pass about a day to migrate and use Cosmo. To experience WunderGraph Cosmo, sign up for Cosmo's free tier and start building (no credit card needed)
If you prefer watching to reading, you also have the option to view this case study as a video.
Frequently Asked Questions (FAQ)
The federated graph can contain everything, including sensitive data, while namespaces created in Cosmo Studio, together with label matchers, are used to expose the correct federated graph and subgraphs to a given consumer. Different parties can be given different GraphQL schemas based on a policy you set, which eliminates touchpoints with sensitive information, better for all parties involved, while the graph stays the single source of truth.
Namespaces are a way to isolate your federated graphs and subgraphs. They are how you group graphs across different environments, such as production and staging, and they can be applied through the Cosmo CLI.
No. In the hybrid setup, where you host the Router and analytics and tracing data are stored in the Cosmo managed service, WunderGraph receives and stores nothing but request metadata, and that metadata cannot be linked to or reverted into actual request payloads. Request and response data exchanged between APIs through your Cosmo Router never leaves the infrastructure where the Router runs, and WunderGraph has no access to the Router instance. This is implemented by design rather than as a configuration setting, so it cannot be switched off intentionally or by accident.
Around one day. Backend Tech Lead Tyler Hawkins said Cosmo was very similar to their old provider so there was not much of a learning curve, and that it only took about a day to reconfigure everything and get started with Cosmo. The quick process is attributed to that resemblance between the two products, which meant only some elements were unfamiliar.
Co-Founder at WunderGraph
Stefan Avram is one of the co-founders of WunderGraph. A former software engineer, he helped shape WunderGraph’s early customer strategy, translating technical value into practical outcomes and guiding enterprise platform teams from onboarding to production. His work helped establish the company’s approach to customer growth and the adoption of federated architecture.
