We Built a PCI-Compliant Tourism Platform That Processed $1M+ — Here's How

This wasn't a booking widget

The brief sounded straightforward: build a platform for travel advisors. Then we saw the real requirements — process sensitive payment data across multiple hotel providers, achieve PCI DSS compliance, handle multi-currency transactions, support 200+ concurrent advisors, and keep error rates near zero. All of it production-grade from day one.

Hotels, stores, transport, experiences — connected through a single event-driven backbone. Multiple providers normalized into one system. Every transaction encrypted. Every dollar tracked. See the complete tourism ecosystem case study for the full architecture.

Cloud-native from top to bottom

The right database for each job

Every microservice runs in its own container with auto-scaling. When 200+ advisors are booking at the same time, there are no cold starts and no degraded performance.

A NoSQL layer handles the fast stuff — session management, real-time availability caching, event streams, advisor activity tracking. Sub-10ms reads, even under peak load.

A relational database handles the stuff that can't be wrong — bookings, financial records, commission calculations, provider contracts. ACID transactions on every payment operation. No eventual consistency where money is involved.

Managed auth across the entire advisor network — role-based access, MFA, secure sessions. One less thing to build from scratch (we built enough already).

Every action is an event

The core of the system is event-driven. A booking, a cancellation, a payment, an availability change from a provider — each one fires an event that propagates through the entire platform:

1. Advisor searches availability across multiple hotel providers
2. System aggregates responses, normalizes pricing and room types
3. Advisor books → event fires: booking.created
4. Payment service captures funds under PCI DSS encryption
5. Provider adapter confirms with the hotel's own API
6. Commission service calculates and records advisor earnings
7. Analytics pipeline captures the full event chain

But this isn't just about real-time sync. Every event is immutable and timestamped. When a financial dispute happens — and in travel, they happen — we can trace every step. That audit trail paid for the architecture investment within the first quarter.

The multi-provider problem

Every hotel provider has a different API. Different data formats. Different availability windows. Different cancellation policies. Connecting one provider is a project. Connecting dozens is an architecture problem.

We solved it with an adapter layer. One adapter per provider, one common interface for everything else. Adding provider #50 takes the same effort as provider #2. The rest of the system never changes.

What the adapter handles:

• Availability aggregation — Query multiple providers in parallel, merge results, deduplicate properties listed on more than one
• Rate normalization — Some providers quote per night, others per stay, with or without taxes. We normalize everything before the advisor sees it
• Booking orchestration — Hold, confirm, modify, cancel. Each provider handles these differently, all abstracted behind one interface
• Graceful degradation — If a provider's API goes down, the system continues working. No single provider can break the search

PCI DSS — the real kind

Most platforms claim PCI compliance by using Stripe and calling it done. We built the compliance layer ourselves.

In-house encryption for card data at rest and in transit. Tokenization for stored payment methods. Automated key rotation. Audit logs for every access to sensitive data. This wasn't a shortcut we could take — and it turned into a competitive advantage.

Why we chose the harder path:

• Full control over the payment flow — no black boxes between the advisor's click and the provider's settlement
• Lower per-transaction costs at scale — the math starts working fast when you're processing $1M+
• Travel-specific payment methods — third-party processors don't handle split payments and multi-provider settlements well
• Direct provider settlements — no intermediary delays eating into advisor trust

Why we built messaging from scratch

Travel advisory runs on relationships. Advisors talk to clients, to hotel providers, to the platform — and every conversation is tied to money.

A third-party chat widget can't do this. Messages in this platform aren't generic — they're linked to specific bookings, itineraries, and financial transactions.

Advisor sends a message about a booking → it links directly to that booking. Provider sends an availability update → it triggers an event in the pipeline. Client asks about their itinerary → the advisor sees full context alongside the conversation. No tab-switching. No lost threads.

Real-time analytics across everything

200+ advisors generating thousands of events daily. Without analytics, you're flying blind. With the event-driven architecture already in place, the analytics pipeline was a natural extension — every event already existed, we just needed to make it visible.

The platform provides real-time dashboards for:

• Advisor performance — Bookings, revenue, conversion rates per advisor
• Provider health — API response times, error rates, availability accuracy per hotel API
• Financial reporting — Revenue, commissions, settlements, currency breakdowns
• System health — Error rates consistently below 0.1% in production

We were the engineering team

The client brought domain expertise and an advisor network. We built everything else.

The encryption layer. The messaging system. The event bus. The provider adapters. The analytics pipeline. PCI compliance. All our team. We chose to build rather than buy because travel platforms have requirements that off-the-shelf solutions handle poorly — and when you're processing real money, "poorly" isn't an option.

The result: $1M+ in sales processed, 200+ active advisors, error rates below 0.1%, and new hotel providers onboarded in days instead of months.

What we'd tell you if you're building something similar

Own your payment flow. It's tempting to offload everything to a third-party processor. But when you're handling travel-specific payment patterns — split payments, multi-provider settlements, commission calculations — owning the flow gives you control over costs and the ability to build features your competitors can't.

Go event-driven from day one. The upfront investment is real. But once the event backbone exists, every new feature is easier to build. Real-time sync, audit trails, analytics — you get them for free. We wish we could go back and tell ourselves to do it even earlier.

The adapter layer is your moat. Multi-provider integration is the hard part of travel platforms. The adapter pattern means provider #50 takes the same effort as provider #2. Without it, every new provider is a multi-week project that slows everything else down.

Building a platform that handles real money across multiple providers requires thinking in systems, not features. Explore our engineering solutions or see more case studies of mission-critical platforms. If you're building something that can't afford to break, let's talk.