We've all experienced what it's like to get re-directed from one site to another to make a payment. In many parts of the world this is still the default payment process offered by payment gateways. Benefits include the fact that none of the processing occurs on the merchant site thus reducing the risk around storing and transacting credit cards. But the downsides are also obvious: you send away a prospective customer at the most critical point in the process.

Newer payment gateways/PSP's have made the hosted payment page (HPP) all but a distant memory in countries like the US. Javascript and transparent redirects provide the benefits of not handling sensitive data without sacrificing end to end control of the process. Ongoing global expansion of services like across all of the gateways that we support.

This offsite experience is still very much alive when it comes to meta/vertical search and affiliate-based online commerce, though. Sites like SeatGeek invest a significant amount of time and energy searching multiple API's to return a full range of results for an upcoming airline or hotel.

They then add another layer of benefit by ranking those results based on a full range of parameters to make recommendations. The end user hits "buy" and... experiences a redirect to another site to complete the transaction. There's a completely new UI/UX look and feel. You're forced to enter your card data in that cart/shopping experience. Occasionally you even receive an error when hitting that third party page.

It's not hard to imagine how this creates a significant drag on conversion hurting all three parties. Wouldn't it be great to never leave Hipmunk to do that?

SeatGeek Case Study


SeatGeek is a new Spreedly customer who helped us during our beta implementation and is now rolling Spreedly out across their site over the month of May 2014. Here's their homepage where you can search for event tickets:



Next, we look at SeatGeek's value add today. You can see that they've searched a range of different API's, presented prices, added a nice stadium map and rated deals based on how attractive they think it is.



But as soon as you select one of the pricing buttons you face the infamous redirect:


This process still works, but it creates so many new dependencies to completing the sale that it negatively impacts close rates. It's a completely different design flow and a new trust equation. It's also frustrating to spend so much time optimizing your own site only to then hand off to a third party who doesn't share your same design philosophies. (Notice the completely different look and feel of the Prime Sport page to the original SeatGeek site.)



Now, let's see what happens with one of the partners where they've leveraged Spreedly's Payment Method Distribution. You hit the blue button to purchase the tickets and...


Shazzzam! You're still within the SeatGeek environment solving one of the hardest challenges around meta ticket sites.

One of the nice things about Spreedly is that we allow SeatGeek to store payment methods. They could try and store those payment methods themselves but they'd be looking at 6 - 12 months and $50,000 to $100,000 in PCI certification and compliance costs. They could also try and store them at a payment gateway like Stripe or Braintree and avoid the PCI compliance costs, but that means the card is locked at that particular gateway and cannot be easily used to transact against other gateways. There's also no way they can retrieve it and pass it to a third party API. 

Once SeatGeek has stored a payment method with Spreedly we return a credit card token to them. The second piece of good news is that they can retain this data on behalf of the customer in case of future purchases, eliminating the need for that customer to re-enter their card data. This increases the likelihood of repeat transactions on the SeatGeek site by reducing the friction in the checkout process for subsequent purchases.

The final step in the process once the customer submits an order is for SeatGeek to route the request to Spreedly along with the credit card token by writing to a predefined template. We attach the underlying credit card data and pass all of the information along to the API endpoint (for those interested in greater specifics).

It's important to note that the order flow has not changed from a typical gateway transaction. The actual card charge still occurs at the end point API. What really changed is that a) SeatGeek retains the customer CC information and b) the customer is not sent off to another site to manually input all of the above information. They stay with SeatGeek and receive an update upon success (or failure).

The end user wins because they only enter their card information once on the same site vs visiting two or more sites to complete a transaction. SeatGeek wins by building loyalty and a repeat purchase situation while also controlling the end-to-end user experience. The end point/third party API wins because SeatGeek increases chances of a successful purchase. Even the card networks win as Spreedly reduces the actual number of locations that can store a card; We also give third party services like SeatGeek a secure and easy way to implement what they need.

There are no doubt many other interesting use cases for our Payment Method Distribution functionality. We're excited by the potential to help meta search and affiliate sites improve the commerce experience for all the key participants.

P.S Thanks so much to SeatGeek's CTO, who was instrumental in helping us launch this new offering.