Shifting the norm on how OTAs work with card data

Booking, paying for, and fulfilling travel is about as complex a process as you can find. A single trip is often comprised of multiple parties and systems talking to each other in what you might consider different languages. On top of that, the environment is fluid. Flights get cancelled, customers upgrade and downgrade their reservations, ticket prices change, dinner reservations get updated. There’s no real end to what might change (even after a trip there could be refunds, disputes, etc.).

Online travel agencies (OTAs) have one of the best views into how all the pieces fit together. They integrate with airlines, car rental agencies, travel insurance companies, etc., and they do it at global scale. Historically, to put those pieces together, OTAs had to handle card data themselves, not only so they could get paid, but also so downstream suppliers could get paid. This was a necessity rather than a choice, and it came with a lot of compliance implications.

That assumption though, that OTAs (and many others in the travel industry) have to handle raw card information isn’t true anymore. The proof is already in practice with many of our customers that operate in the travel industry.

We’ll cover how Evervault supports this new approach, but let’s first talk about some of the complexities of operating in the travel industry, and why OTAs started handling card information in the first place. Having that context will make it easier to understand the “why” behind our products, and the value they bring to businesses in the travel industry.

Legacy infrastructure

We rely on legacy systems every day for some pretty critical things (COBOL software comes to mind) and the travel industry is no exception. It’s one of the best examples of legacy systems and new tech meeting to enable much of our daily lives. A big part of that relates to global distribution systems (GDSs) and how travel data is shared.

GDSs take in data from airlines, hotels, car rental agencies, and other suppliers and make that information available in a single place. This includes flight details, fare information, room availability, and a lot more. OTAs and other businesses can then access all that information through the GDS, rather than integrating directly with all those suppliers. This creates a network effect similar to VISA’s in the payment space, but it’s for connecting travel businesses instead of merchants, banks, etc. The three biggest GDSs are Sabre, Amadeus, and Travelport, with Sabre and Amadeus having the largest market shares.

As a company, Sabre was founded in 1960 and launched their first system in 1964. A few decades later, Air France, Iberia, Lufthansa, and Scandinavian Airlines System (SAS) formed Amadeus in 1987. Their goal was to create an alternative to US systems (like Sabre), and they launched their first one in 1989. These companies and their products have of course evolved over time, and each system has its benefits. OTAs often integrate with multiple GDSs for better coverage across suppliers (airlines, hotels, etc.). Each system also has its own rules, logic, and APIs though, which makes integrating each GDS a fairly bespoke endeavor.

While GDSs have evolved, the way data is shared between the various systems (not just GDSs) is a bit of a different story. Underpinning these systems are two data transfer types: Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT), and the New Distribution Capability (NDC).

EDIFACT

Around 40 years ago, there was no standard way for the many travel systems to communicate. They used different formats for flight information, invoices, orders, etc., and many of the processes were manual. This caused a lot of friction and the United Nations (UN) kicked off an effort to address it and EDIFACT was the result. It established a standard format for sharing travel data, which made a huge impact on the industry. Although it was a significant accomplishment at the time, the standard faces some challenges in today’s world.

EDIFACT is a text-only way for sharing information. So it can handle things like airport codes and customer ID numbers but not images or videos. This wasn’t an issue when EDIFACT was created, but images and videos are standard now. Think about all the visuals used in travel for advertising and for showing customers what they’re buying (meals, seat charts, hotel amenities).

While it defined a standard, EDIFACT is implemented in different ways. There are numerous optional fields, and some implementations may require certain fields that others don’t. These discrepancies became common enough that companies started writing message implementation guides (MIGs) explaining how their implementation of EDIFACT worked. This is of course useful, but if you have to integrate with multiple systems, each with their own EDIFACT flavor, it can be a huge undertaking. On top of all that, the standard itself isn’t human-readable, so it can be difficult to work with.

1UNB+UNOA:1+US::US+50138::THEM+140531:0305+001934++ORDERS'
2UNH+1+ORDERS:91:2:UN'
3BGM+220+A761902+4:20140530:102+9'
4RFF+CT:EUA01349'
5RFF+AAV::C'
6TXT+THIS IS WHAT AN EDI MESSAGE WOULD LOOK LIKE... '
7NAD+BY++OUR NAME PLC::::+++++EW4 34J'
8CTA+PD'
9COM+01752 253939:TE+01752 253939:FX+0:TL'
10CTA+OC+:A.SURNAME'
11COM+2407:EX'
12CTA+TI+:B.BROWN'
13COM+0:EX'
14CTA+SU'
15COM+0161 4297476:TE+01752 670633:FX'
16UNT+15+1'
17UNZ+1+001934'

Example EDIFACT message (source)

EDIFACT is still used today, but its challenges resulted in an effort a few decades later that resulted in the NDC.

The New Distribution Capability

In 2012, the International Air Transport Association (IATA) established the NDC.

Excerpt from the NDC factsheet

This new standard was designed to better reflect how travel booking and retail works today, and it uses XML under the hood which is a more modern way to share data (including rich content types like video) between systems. It’s also more human-readable, as you can see.

1...
2<Party>
3    <Sender>
4      <TravelAgencySender>
5        <Name>JR TECHNOLOGIES</Name>
6        <IATA_Number>20200154</IATA_Number>
7        <AgencyID>00010080</AgencyID>
8      </TravelAgencySender>
9    </Sender>
10  </Party>
11  <Query>
12    <Order>
13      <Offer OfferID="PRICEDOFFER1" Owner="C9" ResponseID="213-9b453cddea3f4fae95fc7c057bf1b1f2">
14        <TotalOfferPrice Code="EUR">746.09</TotalOfferPrice>
15        <OfferItem OfferItemID="OFFERITEM1_1">
16          <PassengerRefs>SH1</PassengerRefs>
17        </OfferItem>
18      </Offer>
19    </Order>
20...

Truncated NDC example (source)

There are still some challenges with it though. Adoption has been slow (but growing), and individual companies, like airlines, can implement NDC in different ways. So similar to EDIFACT, if you want to integrate with multiple airlines, you might have to build bespoke implementations for each one.

If you want more information, we have a separate article on the NDC that goes into some more detail. It’s worth noting here that OTAs often integrate with both EDIFACT and NDC based systems. They can either do this directly or use a third party. For example, Duffel (one of our customers), built an entire business out of making it easier for companies to sell travel, without having to deal with the complexities we just covered.

Checking in

So we’ve established a little bit of background on the inner workings of the travel industry. It’s a fractured environment, with a mix of new and legacy tech. With that in mind, let’s look at some of the complexities around payments, and start digging more into why OTAs needed to handle card data themselves.

Multiparty payments in travel

Digital payments are rarely as straightforward as they seem. From the buyer’s perspective, it might seem like funds go from them directly to the seller, but there are numerous interactions before funds ever move. In terms of travel, a simplified flow might look something like this when you use an OTA.

Example multiparty payment flow

This diagram leaves out a lot of nuance but it’s a starting point. Before we elaborate on the travel and OTA specifics, here are a few brief descriptions of some of the parties mentioned in the diagram. These are a bit simplified as well but they should give you a general idea if you aren’t familiar with them.

• Payment processors and payment service providers (PSPs): companies that sit between businesses and financial institutions that help coordinate payments
• Acquirers: the merchant’s bank
• Issuers: the financial institution that issued the card used for payment
• Suppliers: airlines, hotels, car rental companies, and anyone else that helps fulfill the booking

Think about that flow from the OTA’s perspective and then layer on all of the suppliers they have to work with to fulfill a booking. It’s not just airlines and hotels, it’s travel insurance companies, restaurants, tour companies, etc. Many of those companies will have their own processes (faxing happens a lot still in the industry) and systems, as well as compliance and legal requirements tied to their locales. And somehow, funds have to make their way to all of those parties.

Payments in travel are fragmented and fluid. The customer might pay for their entire trip upfront, or they might pay a deposit and settle up for the remainder later. Each supplier gets a split of the total, and there can be huge gaps between when payments are authorized and when they’re actually captured and the funds are transferred. On top of that, costs can change before customers ever go on their trip. Rates can change, customers might pay for upgrades, events get cancelled, etc.

Without going too deep into it, from the OTA’s perspective, they usually either:

• Accept the entire amount from the customer and pay out to the suppliers, or
• The OTA only captures their portion and the suppliers initiate separate transactions for their subtotals

In the first flow, it’s likely that the OTA is the merchant of record (MoR). This means, among many other things, that they’re the company that shows up on the customer’s credit card statement. It also means they’re responsible for transaction fees and chargebacks. The OTA will have processes in place to pay suppliers separately from the main transaction (although it‘s possible they may still need to pass card information downstream if a supplier requires it).

The second flow is a bit more complex and involves multiple MoRs. Some suppliers don’t permit OTAs to accept payment on their behalf. Instead, the OTA passes credit card details to the supplier so they can process the payment directly. This means for a given booking, it’s possible for the OTA to process the payment for, say, the hotel and the car rental, but not the flight.

All of these elements make payment routing and orchestration big considerations for OTAs. They have numerous levers they can use to tweak their offerings and to optimize payments. For example, they might change offers or route payments differently depending on:

• Whether the card is a personal or corporate card
• Where the person is traveling from and where they’re going
• What PSP has the lowest processing cost or the highest authorization rate for the country the customer’s card was issued in

Bringing it all together

OTAs didn’t really have a choice when it came to handling raw card data. It was either going to be a business requirement for themselves or their suppliers. In cases where suppliers initiate their own transactions, OTAs have to share card information with them so they can charge the customer. Some suppliers also require card data in formats other than the one they were collected in (more on this later). So OTAs don’t just have to share card data, they sometimes have to package it in new ways that their suppliers require. Unfortunately, all this had major compliance implications for OTAs, but Evervault provides a different option.

A new approach

Handling card data directly was the right decision for a long time. The technology just didn’t exist for OTAs to integrate with all the various systems the needed to without touching cards. Even when token vaults came into play and allowed companies to forward card information (and other sensitive data) to other parties, it wasn’t enough because you couldn’t transform the data. If a supplier required card information in a format other than how it was collected, you had to handle the card data yourself. What OTAs really needed was the ability to:

• Collect card information without handling the raw data
• Transform card data into any format their suppliers needed
• Route payments to processors of their choice based on custom logic

Evervault supports all of that and reduces compliance scope at the same time. Let’s talk about card collection first.

Using Evervault decouples card collection, which means you can securely share card information with suppliers and partners (payment service providers, etc.). On the frontend, you use our UI components to collect card information. These components are fully customizable so you can design them to match your brand. After a customer enters their information, it’s encrypted on the frontend and you store the encrypted card data. Raw card information never touches your systems, and Evervault stores the keys to decrypt that card data, so you’re still compliant while minimizing overall PCI scope and risk of breach.

When you're sending card data to companies like Stripe that conform to modern API standards, all you need is a simple way to pass card data on. Our Relay product is perfect for this use case: you make a call to Relay with encrypted data, we decrypt the encrypted fields, and then send the entire request on to Stripe. This happens outside your environment so there’s no additional compliance implications.

When simply forwarding card data isn't enough, you can use Functions. These allow you to rework card data into any format and then share it with others. If you can write the logic in Python or JavaScript, you can execute it in Evervault’s secure environment and then share the result with your downstream partners. This environment is external to your systems and you never see the raw card information, so compliance implications are kept to a minimum.

These card data transformations can be deceivingly simple but they can have huge implications. For example, say the primary account number (PAN) is collected in this format 1234 1234 1234 1234 with spaces between each set of digits. A downstream supplier might also need the PAN, but their system requires it without any spaces in it (1234123412341234). A simple proxy can’t handle that, and if you do the transformation within your own infrastructure, it increases your compliance scope because you have to access the raw PAN to transform it. With functions, you can do that transformation and share the result downstream with minimal compliance impact.

That all hopefully sounds great, but let’s look at some examples.

Seamless hotel checkins through Rippling

Rippling has a product for booking business travel. This includes booking hotels, and in that industry, it’s quite common for the person checking in to not:

1. Be the cardholder for the credit card used to pay for the reservation
2. Have the physical card with them when they check in

In these situations, hotels use card authorization forms to get consent to charge the card used to book the reservation. Among other benefits, this provides a better checkin experience for the employee since they don’t have to pay for the hotel themselves.

Rippling was looking for a way to fill out these card authorization forms without handling raw card data themselves. Doing so would have had major compliance implications which they wanted to avoid. This is where Evervault was able to help.

While somewhat of a simplification, the rough flow behind the scenes looks like this:

1. A virtual card is used to book the reservation through a travel portal
2. That card data is encrypted and brought into an Evervault function
3. Within the function, card data is decrypted, and custom logic runs that generates the authorization form with the relevant details and provides it to the hotel (all done in ~100 lines of Python using various libraries)

Rippling is never exposed to raw card information in that flow, yet they’re still able to work with it. The decryption and custom logic all run within Evervault’s domain, so we take on the compliance scope.

Backoffice flows for SafetyWing

SafetyWing provides global health and travel insurance. To provide the best coverage, they work with insurance brokers across the globe, many of which don’t have an API or a digital way to securely share card information. So in some cases, they actually have to fax information to their partners. To help solve for this, they use Evervault to collect card details from policy holders, and functions to share the relevant details with downstream brokers. Similar to Rippling, they’re able to work with card data in a less-than-straightforward way without touching the raw card information themselves.

An example OTA payment flow

This final example goes a little deeper into how Evervault enables payment flows for OTAs. There are many variables that could change the flow, but this should give you an idea of how Evervault fits into the process. For this example, we’ll use multiple MoRs so you can get an idea of what that looks like.

Multiple MoR payment flow

This flow uses three of our products: card collection, 3DS, and Relay. Customers enter their card details into our secure iframe, and that information is encrypted on the frontend before being stored by the OTA. The OTA tells Evervault to run 3DS on the transaction, which we handle independently and then share the results with the OTA. After successful authentication, encrypted card details go through Relay where they’re decrypted and shared with downstream suppliers. When it comes time to capture the charge, the OTA uses Relay again to initiate the capture with their PSP.

Our standalone 3DS solution is a powerful lever in this example. With successful authentication comes something called liability shift. This moves the responsibility for fraudulent transactions from the OTA to the customer’s issuing bank, which can save the OTA money. However, depending on the supplier, it’s possible the OTA could still be liable for fraudulent transactions. It just depends on the contractual obligations the OTA has with the supplier.

The entire package of products in this example descopes the OTA from a significant number of PCI DSS controls. There are 300+ in total, and we’ve seen some service providers descope to around 60. Additionally, the OTA’s systems are less susceptible to security breaches because they don’t hold any raw card data. Even if a malicious actor obtained the encrypted data, it’s useless without the keys that Evervault stores. So both Evervault and the OTA would have to be compromised in order for the card data to be used.

Closing out with some common questions

Hopefully the possibilities for using card data without handling it directly are a bit clearer now, but you might (understandably) have some questions. You can of course reach out to us, but let’s cover some common concerns we hear from companies both inside and outside the travel industry.

With Evervault, do I keep control over my card data?

Yes. You store encrypted card data and can use it with any PSP or partner that you need to. And if you ever wanted to move away from Evervault, card data can be securely migrated to a different provider. Evervault doesn’t store any of your card data. We only store the keys to access it so there’s nothing that needs to be moved our migrated from our side.

Will using Evervault slow me down like traditional token vaults?

No. If you take a straightforward example (sharing card information with a PSP so they can charge the customer), Evervault is actually 100s of milliseconds faster than traditional token vaults. This is because:

• There are fewer network calls. You have the encrypted card data already so you don’t have to make a call to Evervault to retrieve card information.
• There’s no database lookup from our end. Not having to make networks calls to us to retrieve card data also means we don’t have to do a database lookup, which would add latency.
• Decrypting data is fast. The keys we store for decrypting data are very small, and the operation itself is lightweight so we can handle the whole process in memory.

What assurances can you give me that Evervault is reliable and secure?

We know that our products enable critical processes for your business, and we know there are concerns any time you introduce a new service. That’s why:

• Our infrastructure is active-active across multiple zones
• We use a dual-custody security model
• We have 24/7 monitoring and support
• We’re PCI DSS Level 1 and SOC 2 Type 2 compliant

In terms of collecting card information, even if Evervault went down, you’d still be able to collect cards because you store the encrypted data, not us. We of course have high availability and redundancies in place so this shouldn’t happen, but it’s a unique feature to our approach.

What does Evervault give me in terms of observability and developer experience?

You have access to logs and metrics through our dashboard, and you can sync this data to Datadog for use internally. We’re sure you’ve worked with difficult tooling (as have we), and our integrations have been built to be as easy to understand and use as possible. We also work closely with our users so when our documentation, (human-readable) error messages, and self-serve tools aren’t enough, we’re there. If there are issues, or if you have feedback, we take it seriously and act on it as swiftly as possible.

We want to use as few vendors as possible, what else do you provide that we wouldn’t have to use someone else for?

Alongside card collection, we have several related products that are PSP-agnostic:

• Network tokens: These reduce fraud, boost acceptance rates, and reduce hard declines by automatically updating card credentials when the underlying PAN changes (this can happen when cards are lost or stolen).
• 3DS: This reduces fraud and shifts chargeback liability. Check out how FlightHub leverages Evervault’s 3DS solution for an example.
• Validations for card verification value (CVV), account name inquiry (ANI), and address verification service (AVS): These are valuable risk signals when assessing potential fraud pre-authorization.
• BIN lookups and card fingerprinting: These provide additional risk signals, but they also provide rich card insights to inform PSP routing decisions.