Built a branded, white-label travel insurance booking microsite for a B2B2C distribution partner, ready to deploy across multiple client brands
A React-based travel insurance booking microsite for a B2B2C distribution platform's first client deployment, integrating the platform's travel insurance APIs and a partner-provided payment gateway into a clean, branded purchase flow on GCP Cloud Run.
Key Takeaways
A travel and insurance distribution platform came to Unico Connect to build the first client deployment of a white-label travel insurance booking microsite. We delivered a React-based site hosted on GCP Cloud Run, integrating the platform's underlying travel insurance APIs and the client's payment gateway into a single branded purchase flow covering landing, plan listing, plan detail, checkout and confirmation.
The architecture was designed for the first client deployment but engineered so future clients can be onboarded as a configuration change rather than a re-build.
The Challenge
The client operates as a B2B2C distribution platform in travel and insurance, providing the underlying booking, plan and policy infrastructure that consumer-facing brands deploy through their own branded surfaces. The business model depends on being able to onboard new client brands quickly, with each brand getting a polished customer experience that feels native to their identity rather than visibly running on a shared template.
The first concrete deployment in this engagement was for a partner brand operating in the travel insurance space, with their own client base who needed to purchase international travel insurance through a branded site. The client side of the engagement was practical: deliver a microsite under the partner brand, allowing their customers to select travel destinations, dates and traveller details, see travel insurance plan options, select and pay for a plan and receive a confirmation. Underneath that surface, the actual travel insurance plans and the booking workflow had to flow through the platform existing APIs.
The strategic challenge sat behind this first deployment. The platform wanted to build the microsite for this first client in a way that would set the template for additional client deployments. Each subsequent client would have their own branding, possibly their own minor variations on the booking flow, but the underlying integration with the platform APIs and the operational mechanics of the deployment had to be consistent. Building the first client deployment as a one-off would have produced something that worked for the immediate use case but did not solve the platform strategic problem; building it with reusability in mind required upfront architectural work without the immediate payoff.
There was also a deliberate scope boundary. The platform team and the partner team were clear that this engagement was focused on the consumer-facing microsite, not on the backend API platform (already in place) or the payment gateway integration logic (the partner provided the payment gateway and the API contract). Our job was to build the front-end microsite cleanly, integrate it with the right APIs and produce a deployable artefact that the platform team could host and operate. Volume expectations were modest at launch, approximately 1,000 requests per month for this first deployment with cloud cost expected under Rs.1,000 per month, but the architecture had to accommodate growth without re-platforming.
Our Approach
We engaged as a focused engineering partner, with the work structured around the first client microsite delivery and the architectural decisions that would make subsequent client deployments efficient. The first phase was understanding the platform's existing API surface, the partner's payment gateway requirements and the operational model under which the deployment would run.
Key decisions:
React microsite on GCP Cloud Run
React gave us the component model to handle the booking flow's progressive disclosure cleanly. Cloud Run gave the platform a serverless deployment that matched the volume profile, low at launch and scaling to additional clients over time, without infrastructure overhead. At around 1,000 requests per month the monthly cost runs well under Rs.1,000, scaling proportionally as volumes increase.
Branding as configuration, not code
We treated the branding layer as configuration rather than as code customisation, so the same underlying codebase can host the next client deployment with a different brand identity. The booking flow logic, the API integration patterns and the operational mechanics stay constant; the visual identity, brand-specific copy and any client-specific configuration are isolated to a layer that can be swapped without touching the core build.
Clean contract with the platform APIs
We worked closely with the platform team on the contract between the microsite and the underlying APIs. Plan listing, plan detail and purchase confirmation all run through the platform's APIs rather than independent logic in the microsite. The payment gateway integration follows the partner's specification. The microsite is the customer-facing surface; the platform is the system of record, and keeping that separation clean is what makes the architecture reusable.
The solution we built
A React-based progressive web experience covering the full travel insurance purchase journey under the partner brand, talking to the platform travel insurance APIs and the partner payment gateway, hosted lean on GCP Cloud Run.
Branded landing and plan search
The landing page presents the brand identity and surfaces the input flow where the customer selects their travel destination, dates and basic traveller details (name, age, gender) before submitting for plan options. It lands the partner brand cleanly while staying quick to load and clear in its purpose.
Plan listing and comparison
Surfaces the available travel insurance plans returned by the platform's APIs, based on the customer's inputs. Each plan is presented with the detail customers need to compare, coverage, pricing and key benefits, without overwhelming the page.
Plan detail view
Goes deeper than the listing, with the full coverage description, the exclusions and the conditions that customers should know before they commit, so the choice is informed rather than rushed.
Checkout and payment handoff
The customer confirms their plan selection and traveller details, then completes payment through the partner-provided payment gateway integration. The handoff follows the partner's API contract, with the microsite as the surface and the gateway as the processor.
Policy confirmation
The confirmation page closes the loop, surfacing the policy reference, the next steps and any required follow-up clearly. The data flows are designed for reliability: customers should never get stuck on a plan that turns out to be unavailable, or complete payment without their policy being generated.
Lean GCP Cloud Run hosting
The platform team can update the deployment, scale volume up or down and operate the microsite without managing servers or operating-system overhead. The cost envelope at the initial volume is intentionally small, and the architecture is designed to absorb growth without re-platforming.
Tech stack
Outcomes & Impact
Microsite delivered
A branded booking flow is live for the first client brand
The microsite handles the customer journey from destination input to policy confirmation under the partner brand. For the platform, this is the visible proof point of the white-label model: a partner can offer travel insurance through a site that feels native to their identity, while the platform handles the plans, the policy generation and the operational mechanics.
Reusable architecture
Subsequent client deployments are configuration, not re-builds
New brand identity, partner-specific tweaks to the flow and a different payment gateway where required can be absorbed without touching the core codebase. This is the structural change that turns the platform white-label thesis from a slide into a working system.
Cost-efficient at launch
Serverless costs scale with usage, not idle time
Cloud Run's serverless model means deployment costs scale with usage rather than running idle when volumes are low. The cost envelope at the initial volume is intentionally small, which matters for a B2B2C model where each client deployment needs to be commercially viable at modest launch volumes.
Scales the B2B2C model
The platform can grow clients without growing engineering in proportion
Onboarding the next client now follows the template the first deployment established, so the platform can run multiple client deployments in parallel without infrastructure overhead. That is what makes the unit economics work as the platform grows.
Trusted and verified by our clients
Frequently Asked Questions
Tell us about your project
Tell us about your platform, the partner experience you want to deliver and where you want the product to be in twelve months. A 30-minute call is the fastest way to find out whether Unico Connect is the right partner.
Prefer to book directly?
🗓️ Schedule on Calendly →Or email us:
✉️sales@unicoconnect.com