A Travel Platform's Dilemma

The Tale of Two Travel Platforms: Meta Search vs. Merchant of Record

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--

.

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

 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.

Don't touch the credit card data!

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.

A single credit card vault doesn't always do the trick

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. 

. 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.

A solution to the travel platform dilemma

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
(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
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. 

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.

What if a hotel, airline or other travel endpoint doesn't have an API to send data to?

Spreedly supports over
. 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:

1. The hotel stays the merchant of record, so all customer service inquiries are routed to the hotel directly.
2. The hotel can still reconcile transactions and reports via their payment gateway as if the payment transaction occurs on their website directly.
3. The travel platform does not have to handle or transmit the data, decreasing PCI scope.

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.

If you're an online merchant or e-commerce provider by now you know you should use an iFrame based payment form to minimize your PCI compliance burden. And, in general, you're in luck! Since PCI DSS 3.0 is almost two years old by now, most payment gateways and payment processors have iFrame-based payment forms available for use. 

However, all is not rosy in the payment form landscape. Just because your gateway offers a payment form that has "iFrame" somewhere in the description does not mean it fulfills the spirit of the PCI guidelines, nor does it mean it's the right choice for your business. 

Because Spreedly integrates to over a hundred separate payment gateways, we see a lot of payment form implementations and can offer a unique perspective for online merchants choosing the right iFrame payment form.

Before we dive in, keep in mind this is mainly a cautionary tale meant to reinforce that you, the e-commerce merchant, are responsible for choosing the tools that adhere to your stated level of PCI certification. Just because you use a gateway X, and that gateway X provides an iFrame payment form, doesn't mean your PCI assessor or the brands themselves will let you abdicate that decision. You're on the hook, so you need to be able to defend your position.

Below we discuss choosing an iFrame payment form across three different axes, starting with the most obvious – adherence to the PCI specification.

 

PCI Compliance

PCI compliance, which all online merchants must adhere and attest to, is a beast of certification. Vague guidelines, competing interpretations, and lots of misinformation make it really hard to know what's required of your business. Fortunately, a series of updates to the original version 3.0 (now at 3.2) and some

We now know, unequivocally, that to qualify for SAQ A
‚load all payment content from a PCI DSS compliant service provider‚Äù. This means the form fields that collect the credit card number and CVV, any accompanying javascript libraries, and the submission of the payment data itself, must both originate and return back to the payment provider itself. This might seem obvious, but in reality it's difficult to know if this is really what your provider is doing since there are often layers of abstraction between your use of the provider's client libraries and the actual representation in-browser.

We now know, unequivocally, that to qualify for SAQ A your iFrame payment form must load all payment content from a PCI DSS compliant service provider.

Here's an easy way to tell if your provider's iFrame form is adhering to this aspect of the PCI guidance.

1. In your browser, navigate to a page that utilizes the provider's iFrame payment form (this could be a demo site, or a known customer).

2. Using your browser's developer tools, inspect the credit card number field.

3. In the rendered document view that comes up in your browsers' developer tools, look to see if the credit card number HTML form element (usually an input field) is rendered within an iFrame (e.g. there's an iFrame anywhere in its parent hierarchy). This is what it looks like when the field is not contained within an iFrame, meaning that sensitive field is not served directly from your provider and you are exposed to additional PCI compliance burden (taken from a production site using a popular gateway's payment form):

‍

By contrast, this is what it looks like when a PCI-sensitive field like the credit card number is served directly from the payment provider within an iFrame:

This might seem like an arcane technical detail but don't dismiss it! It has a direct effect on your ability to self-assess using the 4 page SAQ A vs. the 40 page SAQ A-EP and it is your, not your payment gateways, responsibility to make the final PCI determination.

 

Brand Continuity

Ugly, unusable, downright hostile payment forms are not only death to your conversion rate ‚ they also have a particularly insidious effect on your brand. Not a day goes by without someone taking to their preferred social media channel to vent about what great inconvenience your site has caused them. Do you want this kind of shame retweeted and liked over 2,000 times for your brand?

As an online merchant, store, or e-commerce brand, it is your responsibility to craft the best experience for your users. Though this might take more time than just slapping your current payment provider's stock form on your site, the fact is that it's a commercially justified effort. Not only will your users have a delightful checkout experience, you will walk away with more $$ in your pocket from the non-trivial increase in checkout rates.

Things to look for in an iFrame payment form are the ability to customize both the look and feel of the form as well as the structure of the form itself. This often manifests as the ability to position the credit card number and CVV fields independent of one another and set custom CSS properties on these fields, even though they live inside your provider's iFrame. While a more complex implementation for the merchant, this results in a better checkout rates for online merchants and better brand experience for the customers.

 

Documentation

Old-school payment companies tend to be cut of a different cloth than modern technology or developer tooling companies. Large institutions can be secretive and protective of their technical documentation, which can meaningfully delay your integration effort. Thankfully, this divide is closing. But you should accept nothing less than publicly available integration guides, technical
documentation, and self-service test credentials.

Having documentation is very different from having good documentation. Your provider’s developer documentation should be clearly organized both by purpose (mobile payments, etc…) and product (iFrame form, etc…). Additionally, the API documentation should be very clearly separated from the general guides. Guides are good for walking developers new to the toolset through the features and tend to be prose-oriented. API docs are good for when you know what you’re looking for and just need to see the raw technical details. These are two very different purposes best served by two different structures.

 

iFrame Payment Form Comparisons

At Spreedly, it's our job to provide integrations to over a hundred payment gateways. As a result, we have a lot of relevant experience with iFrame payment forms. We have
as well. Let's look at how a few popular gateways' iFrame forms stack up by these characteristics:

Options

If your payment gateway provides a really clean iFrame payment form that adheres to all the points raised here, then lucky you! However, chances are if you're using any but the top 3-5 developer-oriented gateways, your iFrame payment form options will be lacking. What to do in that case? Switching payment gateways is always an option, but many times there are business reasons to keep your existing processor. 

That's where Spreedly comes into play. Spreedly modernizes your antiquated gateway. Spreedly's tooling, built by developers for developers as part of a modern payment stack, lets you integrate with the payment gateway of your choice.
I hope this guide was helpful. Please sign up for a free developer account at Spreedly if you're not happy with your gateways' tooling. You can also view the Spreedly iFrame documentation if you want a point of comparison.

*See the latest updates regarding iFrames here*