The complexities of payments for OTAs and Insurance

What should you care about if you are in business, payments, or growth at an organization that acts as an “agent”?

When most think about OTAs (Online Travel Agency), visions of fun travel plans, picture-perfect locales, and new adventures come to mind. Booking.com, Expedia, and Airbnb are the leaders in this space, with a combined revenue total of around 80% of the market. These OTAs aggregate many options from multiple providers, providing a new selling channel for the hotels and providers and a one-stop shopping experience for the buyer. All travel-related services - flights, hotels, car rentals, vacation packages, activities, and even cruises can be booked with a click through these websites or mobile apps.

Consumers making travel plans enjoy the choice and convenience of purchasing on a single platform and frequently get better deals with special member-only prices. They can also participate in loyalty programs like Expedia's OneKey program, which can be used across its properties and isn't bound to a single hotel chain or cruise line.

After taking a hit during the pandemic that forced everyone to be home, OTAs have fully rebounded. In its State of Travel 2024 Report, Skift Research “found that Americans will spend over $200 billion on summer vacations in 2024, with the average household planning to spend nearly $3,000.” According to UN figures, international tourism is expected to increase by more than 15 percent in 2024 compared to 2023, surpassing pre-pandemic figures.

Two Ways for OTAs to Get Paid

Traditionally, OTAs were paid for their travel products in two ways: the post-paid agency model and the pre-paid merchant model.

Evolving the Merchant Model to Include BNPL

Increasingly, OTAs also offer a third option—Buy Now, Pay Later (BNPL)—where, typically through partnerships with fintech companies like Klarna, Affirm, and Zip, customers can pay over time rather than upfront. This is an evolution into a merchant-partner model where BNPL is integrated into the OTA's checkout process as a payment option. OTAs would adapt their existing checkout flow to accommodate the new payment functionality. The Merchant Model is increasing in popularity with OTAs like Booking.com. In contrast to the traditional Agency Model of getting paid later, they handle payments directly from guests rather than leaving them to the hotels. OTAs can control the transaction process more tightly and offer flexible payment options to customers like BNPL. This requires collaborations with fintech companies, both to move faster and address the limitations of legacy infrastructure. For instance, Airbnb has partnered with Klarna, and Expedia with Affirm, allowing customers the flexibility to pay in installments and making the OTAs' travel products more accessible.

Almost Mobile-First

66% of millennials paid for their trips using a smartphone, while 74% used their mobile for travel-related research. Mobile-first providers like Hopper and Hotel Tonight are popular enough with millennials for OTAs to want to protect their turf and end partnerships with them. Of course, the incumbents are more than holding their own in the mobile arena, with Booking.com and Airbnb in the world's top 10 most downloaded mobile apps in travel, accounting for 80M and 52M downloads, respectively. Focusing on mobile is a sound strategy, seeing that almost half of Booking.com's purchases are on it.

AI Seeps In

Travel is a deeply personal experience, and one of AI's most common applications is personalization. ChatGPT is easily the most popular in the new category of AI search engines, with 180.5 million users as of August 2024, and one of its popular uses is for personalized trip planning. OTAs have jumped on the bandwagon to integrate AI into their travel offering, such as Expedia offering ChatGPT in its app and TripGenie from Trip.com for AI-enabled trip planning. While the promise of AI is more tailored and efficient travel planning experiences based on user preferences, at least for now, the results do leave a need for human intervention.

Fighting Inflation

Even as travel is back post-pandemic, the inflationary pressures dogging the economy have caused price sensitivity in consumers, with many saying, ”enough is enough.” Faced with consumers who prioritize price and even reduce the number of trips they take, OTAs are creating loyalty programs to boost purchases. I mentioned the OneKey multi-brand loyalty program from Expedia that works across Expedia, Hotels.com, and Vrbo. 168 million members, and counting can use to lower costs by accumulating points and redeeming these for rewards. Similarly, Booking.com offers the Genius loyalty program with tiered member discounts. These discounts increase for higher tiers, but I have to assume a volume play since they come at a cost to hotels through lower rates and increased commissions.

Getting Paid and Making Payments as an “Agent”

Much as we enjoy the convenience and deals of OTAs and other aggregators, what happens when we click Pay?

OTAs, Insurance agents, and others are just the offering platform. How does the transaction process work so that your card is debited, the travel service provider or insurance company is credited, and the “agent” gets its commission in the Agency Model, or profit in the Merchant Model? Plus, as part of this, how does the information stay secure to protect the consumer from a breach and ensure that the entity collecting their card information is PCI-compliant?

“Agent” payments have an added layer of complexity since they originate on the 3rd-party provider platform and then need to be bound by and go back to the insurance company, airline or hotel. This involves a “double-loop” payment process - from the customer to provider, and then provider to the hotel, airline, or other travel service provider. In the case of an OTA, imagine a transaction where you purchase your flight, hotel, and rental car all together. Or all your insurance products from a single agent platform. What is consolidated into one purchase for you has multiplied the loop on the OTA's back-end since there are now five stakeholders involved in the purchase - you as the payer and the OTA as both payee and payer to three more vendors.

As you wait for the great trip you just booked, the OTA ensures the three vendors receive their payment. They can transfer the money through older methods like ACH payments, BSP - the electronic billing system from the International Air Travel Association (IATA), physical credit and debit cards, or more modern virtual ones. Sometimes, it can be more than one, expanding the complexity for an OTA.

But, we can also imagine the drawbacks of each method. ACH is only US-based and involves manual intervention. BSP has coverage limits and less flexibility for refunds and reconciliation. Both ACH and physical cards can have longer settlement times and are vulnerable to fraud. Virtual cards increase security and spending controls with better scalability and reconciliation but can have limited acceptance and complications with refunds and recurring payments.

The Merchant of Record: To Be or Not to Be?

You might have noticed that the OTA only passes through payment information and does not process payments itself. This can be true in other industries as well—insurance is one example, and others involve an intermediary seller or “agent” between the buyer and ultimate seller. Why not? And what do companies consider when deciding whether to manage payments themselves?

The answer is typically a trade-off between the PCI compliance burden and data ownership. Any company that stores, transmits, processes, or can otherwise affect the security of credit or debit cardholder data is subject to PCI-DSS requirements, including the expanded PCI-DSS v4 that is mandatory as of March 31, 2025. On average, getting PCI certified can take most of a year. After the initial certification, you might spend $100,000 per year on maintenance costs. Non-compliance can result in fines ranging from $5,000 to $100,000 for each month of being out of compliance.

With such considerations, organizations want to reduce their PCI DSS scope and ensure their systems do not touch sensitive information like the PAN (card number). Instead of being the merchant of record (MoR) that sells products to end customers, these OTAs, insurance brokers, or other providers pass on cardholder data to the service provider. The airline, hotel, car rental company, or insurance provider as the MoR takes responsibility for the financial aspects of the transaction, such as taking the user's card payment through a payment gateway for a processor, handling any refunds or chargebacks, and sending back a commission to the intermediary seller.

When most OTAs or Insurance providers approach us at VGS, they have a technical integration with the PSP on behalf of their provider but choose to avoid having the business relationship. They collect the payment information from the end user and pass it to the service provider (hotel, airline, insurer, etc.), who does have a direct relationship with the PSP. The OTAs or Insurance providers aren't the MoR and don't want to take on the complexities of setting up and managing relationships with payment gateways, acquiring banks, fraud prevention providers, and other institutions. They only forward the cardholder data and get paid a commission. This setup is a common one in the industry. In some cases, they may do both the technical integration and initiate the API call to the PSP themselves and decide to take on the direct PSP relationship.

Organizations in an “agent” structure reach out to us to reduce PCI compliance requirements, automate their processes, and eliminate human error. They achieve all this, plus the significant benefit of owning and controlling their data.

PCI Compliance and Data Entry Automation: OTAs, Insurance and More

Even if an Insurance agency isn't the MoR, they do need to protect their customer's data and their organization from breaches. However, their current process may be far less than optimal. For instance, the agency could be receiving the cardholder's payment details inbound and then reveal values to their admin site. An agent then manually binds the policy by filling out customer's information and payment details on the insurance carrier's website. Or, they may be taking card numbers and writing them on a piece of paper, trying to fax or email over a spreadsheet, or sharing a Google sheet with the service provider. The risk to customer data security and the potential for user error is mind-boggling.

There can be a safer alternative to removing the human element while securing the cardholder data. OTAs could collect the inbound data in a token vault, use a headless browser (a web browser without a graphical user interface (GUI)) to collect that information and automatically populate the desired web page, and then use a forward browser proxy to route the OTA web traffic and securely reveal the data to the travel service provider. This could be done with the OTA never touching the sensitive data.

It's worth noting that automation would be more straightforward with a standard, HTTP-based API. The data could be collected from the end user via the web browser or mobile apps and stored as tokens in a vault while keeping the OTA out of PCI compliance scope. However, the travel service provider would have to offer an API endpoint, and the OTA would need to be integrated with them. But without that, this solution balances the need to minimize manual intervention through a browser proxy.

While this example was for an OTA, this intermediary model process works similarly for other industries, like insurance. VGS works with a number of insurance agencies that offers various insurance products from their network of insurance companies.

When an end-user requests an insurance quote from our customer and buys a policy from one of their insurance company partners, below is one example of the steps that could occur. Every setup can be different based on the customer's needs.

1. User provides cardholder information via web, mobile or VGS Collect to the insurance agent for an insurance policy from their carrier partner.
2. Next, they send the user's card details (PAN & CVV) to their VGS token vault, where VGS accepts them as inbound data and tokenizes them.
3. Our customer may not have a direct relationship with the insurance carrier partner's third-party PSP. So, they use the insurance carrier's credentials to automatically send the card details downstream via API to the PSP on the outbound data route to initiate the payment. The direct integration with the PSP's API avoids manual data entry from the insurance agency to the insurance company.
4. Our customer can send and reveal the cardholder data to any API endpoint from their vault. Once payment is confirmed, they make another API call to send their insurance carrier partner information to bind the policy and put the insurance coverage in effect.
5. If the selected insurance company does not agree to bind the policy, our customer can take it to another insurance carrier, which will likely have a different PSP.
6. If the second partner agrees to bind the policy and put the insurance coverage in effect, the second PSP will process the payment.
7. Since our customer can access the card details in a token vault, they have the flexibility of seamlessly sending the information to the second PSP, once again using the backup insurance company's credentials.