There are two payment approaches a travel platform can take, a Meta Search Website and a Merchant of Record. Both approaches are markedly different, each having their own pros and cons. Despite the differences, however, travel meta search websites and merchants of record face similar challenges: how to increase payment transactions and reduce PCI scope. Fortunately, a single solution solves for both.
Travel meta search websites and merchants of record each offer the consumer a variety of travel options to choose from. This is where the similarities end. Meta search sites allow consumers to search and then select the best deal. They then re-route consumers to an offsite page to complete the transaction-- not always the best user experience.
For example, they may route consumers directly to a rental car company, hotel reservation page, or the airline's check out page to complete the sale. Or the data may also be routed through a broader reservation platform like Alliance or Sabre. Examples of travel meta search platforms include Hopper, Momondo and Skyscanner. A merchant of record, on the other hand, allows consumers to checkout within the app or on the webpage without leaving. Here, the travel platform is acting as the merchant. They take direct responsibility for the purchase, appearing as the merchant of record on the consumer's credit card statement. A good example is and Hotel Tonight.
There are pros and cons to both approaches. Typically, nearly all online platforms start off purely as meta search websites. This is primarily due to the simplicity and speed with which they can launch. Over time, superior economics, higher conversions, and a better customer support experience, drive some or all of their processing to a merchant of record model. As the travel platform¬†expands globally it¬†often starts the whole process over again.
In the meta search scenario, the online travel marketplace needs to find a way to deliver both the consumer and the credit card data to the entity fulfilling the reservation and/or transaction. In order to decrease PCI scope, the platform may avoid touching the data all together by routing the consumer directly to the travel endpoint to type in their credit card. The endpoint is then responsible for PCI compliance. If a meta search site wants to facilitate an Uber-like experience it¬†may have the user create a profile and store payment data for future use. If it¬†does this, the site is now on the hook for handling credit card data. At this point the meta search site has to worry about PCI compliance.
Whenever I speak to a travel platform¬†about storing credit card data they are usually pretty familiar with Braintree or Stripe. Some even mention acquirer gateways like First Data or Orbital that also offer credit card tokenization or vaulting. In only one of the scenarios above does the traditional credit card vault greatly reduce PCI compliance: if a platform is the merchant of record.
A merchant of record can easily store credit card data with a single payment vault, like Braintree, when they are the party completing the transaction. Additionally, if they are solely processing data via e-commerce or mobile they most likely qualify for the shortest and easiest PCI compliance form. When travel platforms tokenize a credit card with a single vault the downside is that token can only be used with that single payment gateway. Platforms cannot take that token and pass it to another gateway because the other gateway won‚Äôt recognize it. This is an obvious problem when your business model requires working with partners that use different payment gateways.
Before Spreedly there was no way around having to handle the credit card data or being a merchant of record and having the overhead of integrating with different payment gateways. Spreedly's Payment Method Distribution (aka PMD) takes this onus off both meta search websites and merchants of record. PMD supports the ability to securely transmit data from Spreedly's payment vault to multiple API endpoints. This solution greatly reduces a travel platform's PCI scope and eliminates the need for a meta search site to have to handle the data prior to routing it to a third party. Spreedly's PMD API handles the heavy lifting instead.
Payment Method Distribution ultimately is the process by which a customer tells Spreedly to initiate a call to an API and to include credit card data that is securely stored and tokenized within Spreedly's vault. We then act as a proxy that adds in sensitive cardholder data before passing along the customer's API request.
By using PMD an online travel marketplace can vault data in a single location, Spreedly. It can then push that data to multiple API endpoints without the platform ever having to handle, transmit or store that data internally. This greatly reduces its PCI burden.
Spreedly supports over 100 payment gateways worldwide. If an online travel marketplace needs an alternative to PMD, it can use the gateway credentials of the travel endpoint to process the transaction via their site. For example, if a travel platform wants to allow a consumer to book a room with a hotel, but the hotel doesn't have an API, it can gather the payment gateway credentials of that hotel and process the payment transaction directly through that gateway account. In this scenario a few things are accomplished:
In our Uberized world, consumers prefer an experience that doesn't require they enter in their credit card data every single time they purchase through an app or website. Consumers are looking for the magic one or two tap experience. Solutions like Spreedly's Payment Method Distribution allow meta search websites and merchant of record travel platforms to create this Uber-like customer experience without a heavy PCI compliance burden.