Spreedly Blog

Universal Credit Card Fingerprinting

One of the many benefits of tokenizing credit cards is that you never have to manage, or come in contact with, sensitive card data. This minimizes your PCI compliance scope and gives you more time to focus on what’s important to your business. However, this comes at the cost of less visibility making it hard, if not impossible, to know when the same card is being used across multiple transactions. Today we’re happy to announce the release of our Fingerprinting beta which provides a greater level of visibility into your card data.

Fingerprinting assigns a randomly generated identifier to each unique credit card number and exposes this value back in the API. Anytime a card is added you can use this value to determine if you’ve ever seen the card before. This lets you build such features as loyalty programs, basic fraud detection, and omni-channel recognition – all without increasing the PCI scope of your application or service. Even if the card has been redacted from your Spreedly vault its fingerprint will remain, letting you mine your transaction history for relevant business insight (all cards that are currently retained, or have been added, as of December 2nd have been assigned fingerprints).

Additionally, card fingerprints are constructed independently from the gateways you transact against. The fingerprint for a card you use against Stripe will be identical to the same card used against Paypal. Spreedly provides a global view into your cards instead of having silos of data isolated within each gateway. These fingerprints are truly universal, allowing for unprecedented flexibility and portability.

If you’re interested in using card fingerprints, you can do so immediately. Read more about getting fingerprints from the Spreedly API in the docs and let us know if you have any questions at support@spreedly.com.

Spreedly for Classic Applications

If you’ve ever been incredibly excited about a new piece of payment technology followed quickly by the onset of depression because you know the payments infrastructure in your application won’t allow you to use it, this article is for you. I don’t really like the word “legacy” since it has such negative connotations, and something turning over six figures a month is actually pretty awesome regardless of how it’s coded or how old it is. Someone at the office suggested we call them “classic” applications and I think that’s a great way to put it. But just because it has sweet lines, if your classic car is a leaded gasoline guzzler, and you want to use it for a daily driver, you’re going to need an engine upgrade.

The same thing goes for a classic application – if we want to drive adoption of better payments technology in existing organizations, we’ve got to find the most direct route to upgrade them to a modern payments stack. How do we do that?

I want to make a three-part argument: first, that the vault is at the heart of every payments stack. Second, that Spreedly is a modern vault that is not only rock solid, compliant, and flexible, but also super easy for all the classic applications of the world to adopt. And finally, that once businesses are on a modern payments stack as exemplified by Spreedly, adoption of the whole ecosystem of payments is unlocked.

The ❤️ of the Payments Stack

It’s bold to call the payment method vault the heart of the payments stack, but I don’t think it’s in any way an overreach. Let me address one caveat up-front: you might be thinking, “The majority of merchants only run a single transaction with no long-term storage, so what do they need a vault for?” I’m using the term “vault” in a broadly defined way to mean “a safe place to store sensitive payment information for as long as the business needs it,” and even for an immediate purchase there’s a need to hold the payment method long enough to bundle it up with the rest of the transaction information and send it on.

Therefore a vault is pretty simple: on one side there are ways of getting sensitive payment information in, the more ways the better. On the other side there are ways of getting sensitive payment information out, of making use of it. And in the middle is secure storage – whether it be for 3 seconds, 3 days, or 3 years – of that sensitive payment information.

But why is this “safe place to store sensitive payment information” the heart of the payments stack? And if it is, why doesn’t everyone just build their own? It all comes down to security and flexibility. Security (and more pointedly, PCI-DSS) dictates that this information be treated with extreme caution, and that it is isolated from other systems. On the other hand, that payment information is the lifeblood of an organization’s commerce, and the easier access to it and use of it is, the better the customer experiences, the better the margins, the better the fraud protections, etc. These two goals are in conflict with each other – lock sensitive data down while also maximizing the use of it – and that means that the capabilities of an organization’s vault (again, broadly construed) become the gating factor on all commerce innovation in that organization.

Before I move on, a bit of editorializing: this is why security is hard, and adoption of best practices like PCI-DSS is so slow. It’s easy to look at all of these breaches and think, “Why don’t these people get their act together!” But if all that was needed was to collect payment information and ensure nobody ever got access to it, security would be pretty trivial. The challenge is that everyone needs to make use of that payment information, and security increases the friction of using it. A cure that kills the patient isn’t much use.

Spreedly: A Modern Vault

Hopefully I’ve sold you on the vault being the heart of the payments stack, now: what is Spreedly? Spreedly is a payments infrastructure company that provides a modern vault that is easy to adopt. We make it super easy to get payment information in, keep it safe, and make use of it however is needed.

By definition a classic application is fairly inflexible, which is the challenge with upgrading how it does payments. But Spreedly provides a lot of ways to ingest payment data, and one of the methods that Spreedly provides probably matches up with how a given classic application is already operating. Lets do a quick walkthrough of the options.

First, and often easiest to implement, is Spreedly Express. This “payment form in a box” can be dropped into an existing payment flow to do all the collection of payment data and just return a final tokenized form of the payment method. It looks like this:

spreedly-express

The second option is Spreedly iFrame, which captures only the credit card number (PAN) and card verification value (CVV) fields when embedded into an existing page, and swaps them in place in the payment form with a Spreedly token representing their values. The advantage of Spreedly iFrame is that it can be plugged into an existing flow without any consumer-visible change.

Both Spreedly Express and Spreedly iFrame de-scope the classic application from PCI requirements according to current PCI-DSS rules. There is one further option if the classic application already operates in a PCI compliant environment, and that is to use Spreedly’s direct API, which allows direct submission of payment data via an authenticated Spreedly API from the server side. This allows ultimate flexibility and is often the least intrusive modification, but has to be weighed against it’s PCI implications.

So there are a lot of ways that an application can be retrofitted to get payment data into Spreedly, and to make use of those cards for basic transactions. But of course this is all pretty elementary, even if it is optimized for adoption by classic applications. There’s one key difference with Spreedly that makes us a game changer, though: Spreedly is a software company, an infrastructure company, and not a processor. Let me reiterate that: at Spreedly, we don’t care where the processing happens, since that’s not how we make our money.

Why does this matter? Simple: Spreedly is completely agnostic as to what our customers want to do with the payment information we’ve helped them capture in their Spreedly-hosted vault. So long as the usage of that information is safe – security is a fundamental part of the service we provide – we’re ready and willing to enable our customers to use that information however they’d like.

Contrast this with a fully integrated stack, like Stripe or PayPal. While all of these integrated stacks are great companies that provide impressive tech, their fundamental alignment is with doing all the processing within their ecosystems. And who can blame them? That’s how they make their money, and more power to them. But at Spreedly we believe that real innovation and adoption of that innovation is only going to come when merchants can make decisions about what technology to adopt independent of what any given processing stack does or doesn’t support.

Unlocking Payments Innovation

Lets look at three examples of how a modern vault, owned by the merchant, can unlock payments innovation in an organization. You can whip any or all of these out when an acquaintance or a prospect wonders why they should spend time moving to a stack like Spreedly.

Cabify

Lets start with something super simple, where someone tells you: “we’re selling in Europe a lot now, and seeing a lot of declines.” If the merchant owns their own Spreedly-backed vault, they can send card data to any of the over 90 payment gateways we support. Unlike the scenario where their credit card data is locked up in a single payments ecosystem, now they can grab a merchant account in Germany, or in the UK, or wherever they determine is best for their situation, and start running local transactions locally. And their technology now supports them in doing that, instead of making it more difficult. A great example from Spreedly’s customers on this one is Cabify, a transportation service in Spanish-speaking countries, who uses Spreedly to vault cards and then run them in the country of transport, for instance if the customer just flew from Spain to Mexico.

Seatgeek

Now for a more complicated case. Spreedly customer Seatgeek moves a whole lot of tickets for all kinds of events. The challenge they have is that ticket inventory is often held by brokers, and those brokers take credit card information and do the whole transaction. Seatgeek used to have to send customers off to the broker sites, which was often a horrible user experience with crippling purchase abandonment, but using Spreedly’s ability to send payment data to any PCI-compliant API, they now pass credit card data right from the Seatgeek Spreedly-powered vault to the broker API’s, and the whole transaction happens at the broker.

The final example I’ll leave you with is the identification of the same card, used in multiple channels. Every time you add a credit card to the Spreedly vault, we calculate a persistent fingerprint for that card that never varies. Some gateways do this too, but many of the merchants that this would be the most useful for are either on a gateway that doesn’t do it, or use multiple gateways but need the same fingerprint regardless of where the transaction is run. Spreedly has this universal fingerprinting in closed beta today with anticipated release any day now, so while I don’t have an example customer for you yet, we have a lot of merchants lined up to start using it as soon as it’s generally available.

These are just the tip of the iceberg; you can see how a fraud tool could leverage the Spreedly vault to rapidly ingest the sum total of a merchant’s transaction history across any and all gateways the merchant uses, or how a means of disbursing funds to a bank account could be rapidly adopted by Spreedly-powered merchants since those merchants can start sending their collected bank account information to the new disbursement service with a couple lines of code.

I hope I’ve convinced you that the vault is the heart of the payments stack, that Spreedly exemplifies a modern vault that is backend agnostic, and that this puts payments innovation in reach of classic applications and merchants everywhere. The next time you see some great payments technology, remember that Spreedly is a powerful tool in your belt that can make innovation usable in your context.

JSON API Support

Today, we’re excited to announce the release of the Spreedly JSON API beta, combining the benefits of our battle-tested XML API with a modern serialization format. JSON has many benefits, including a more concise serialization format, better human and machine readability, and is, in general, the preferred format for modern APIs. JSON parsers are well-supported in any language making implementing a JSON API client trivial.

We encourage everybody to upgrade to the JSON API and provide a very simple upgrade path: each endpoint’s XML and JSON version is interchangeable. A transaction created with the XML API can be retrieved by the relevant “show” JSON API endpoint and vice versa, allowing you to incrementally upgrade at the pace and path you feel most appropriate for your service.

We’ve also taken the opportunity to update our reference documentation to a more concise format. You can find them here.

With this addition we’re continuing our goal of providing a modern financial platform for our customers, letting you quickly integrate with a variety of backend payment processors. Please participate in our public beta of the JSON API today and contact us if you have any questions.

iFrame Payment Form v1.0

In January of this year, Spreedly released the beta version of the iFrame payment form. The iFrame payment form allows merchants to collect payment information in accordance with the new guidelines of PCI-DSS v3.0 while still retaining control over the look and feel of their checkout page. Today we’re happy to announce the release of iFrame v1.0  – the result of several months of beta testing and customer feedback.

iFrame v1.0 builds on the great feedback we received during the beta period, letting you now independently position each PCI-protected field (i.e. the card number and CVV) as well as use your own custom web fonts and other style customizations. We recognize that the UX of your checkout flow is critical to your business – iFrame v1.0 is an extremely customizable solution and we encourage everybody requiring a custom payment form to give it a try.

Maintaining a PCI-compliant application is an arduous task. Spreedly greatly reduces this burden by maintaining a secure credit card vault and providing robust tools to store your customers’ payment information. iFrame v1.0 is the best way to build a payment form consistent with your brand’s UX while still receiving the full benefit of reduced PCI scope. Contact us if you have any questions about iFrame or any of our other payment tools.

Marketplaces and Stripe Connect: Does one size fit all?

The shift from desktop/web to mobile/app is creating new opportunities for commerce. Everything from the way we book travel to have our groceries delivered is up for grabs as commerce moves to mobile. When building an app or service that connects suppliers and consumers you quickly run into the issue of collecting payments on behalf of your merchants/sellers. There are three major challenges: PCI compliance, who will act as merchant of record, and sharing/splitting revenue.

Stripe Connect (and other platform offerings from Braintree and WePay’s white label) has a really impressive approach to solving this challenge along with one major drawback.

On the positive side, Stripe helps minimize your PCI compliance scope with card data never touching your environment. It also provides the ability for sellers to each have their own unique merchant account (under the marketplace’s overarching umbrella) so that a marketplace can route payments made from buyers directly to each seller without ever touching the funds. Perhaps of most value though is the fact that Stripe’s API allows you to split a payment into two while only showing as a single transaction on the cardholder’s statement. This allows marketplaces to deduct a fee and deposit it directly into their own account with the rest routed into the seller’s account all in a single transaction.

The major drawback is that every seller in your marketplace has to accept a Stripe account. This can be an unwanted drag on adoption/usage of your service (unless you rely on revenue share from processing as your primary revenue stream). And it only gets worse the bigger the opportunity; larger sellers are generally more attached to their existing payment processor for a variety of reasons including often substantially better processing rates.

There’s a lot of simplicity in working with just one payment provider. At Spreedly we support Stripe Connect so there’s really no “right” answer. Someone launching a new service may decide to only work with Stripe Connect and believe the simplicity of one solution outweighs the lost sellers who have an established processor relationship. Or you could work with Spreedly and Stripe Connect from the very beginning and incur Spreedly fees as an “insurance policy” so that when the moment comes to add that new gateway there is no technical gating factor to winning the seller/supplier.

Lately we’ve seen an uptick in interest from existing Stripe Connect marketplaces and platforms wanting to support more choices. It makes sense too; the longer Stripe Connect is around the greater chance some of those earliest customers are reaching a size where they are ready to support more than just a single payment choice. Whether you decide to go with just Stripe to begin with and change later or have options up front we’re happy to support.

 

Spreedly Raise

We’re excited to announce that we have recently closed an additional funding round of $2.5 million, working with our existing investors E-Merge and also adding one of the founders of Ogone to our list of investors. E-Merge has provided us tremendous support over the the last two and a half years with their valuable insights based on the strength of their experience working with startups across a range of different verticals. This new round brings our total raised capital to just under $5 million.

When we (re-)launched Spreedly two and a half years ago we believed traction was the single most important thing. It’s proof to the outside world (“people really use us!”) and it motivates your team through the early slog via critical validation (“people really use us!”). With that in mind we focused our efforts on greenfield opportunities: startups and new projects where we didn’t have to worry about a team switching out an old solution for ours. We also invested heavily in technology (developers and infrastructure) to build out a fully featured product as quickly as possible.

That strategy has proven fruitful. Today we have 9 developers and 3 business folks managing around 300 marketplaces and platforms generating nearly $2 billion in annualized processed volume spread evenly across a wide merchant base – up from $1 billion just a few months ago. We have strong organic revenue growth enabling us to stay firmly in control of our future.

Yet a lot has changed in the last two and a half years. When we launched we were ahead of our time, not in an iPhone way, but in an, “I just don’t get it – why would anyone need Spreedly?” way. Patience is a virtue and the market is now coming to us, and with that are larger opportunities with different expectations.

We decided that we need to invest further in the business to maximize our ability to capture the opportunities the market is presenting. We need sales and business development people to manage the inbound flow and utilize the lessons learned to create outbound opportunities, and we need to add marketing skills so we don’t remain the best kept secret in payments. Now world class infrastructure is more critical than ever because nothing is more important in payments than availability, and more support and development resources need to be added because they’re competitive differentiators for us.

All of this is great news for our existing customers and our future customers and we hope you’ll see the positive changes as we increase our resources. And of course, we’re going to be looking for talented people for this next phase of growth so please contact us if you have any interest in working for Spreedly.

Spreedly Express: The Easiest Way to Collect Credit Cards

Merchants using Spreedly to process payments currently have several options when it comes to collecting credit card data. If you are already heavily in PCI scope and want to manage the addition of cards yourself you can use the direct API. If you want to limit your PCI scope under PCI-DSS v3.0 with the some ability to customize your payment form then our iframe payment form is the best way to go. Today we’re happy to announce a third option: Spreedly Express. Express minimizes scope and development work making it the fastest, easiest way to collect credit cards.

One way to think of Spreedly Express is as a Hosted Payment Page. It is a drop-in payment form designed for quick and easy integration into any checkout page, all while exposing you to the least amount of PCI scope possible. The sensitive data is accepted, transmitted and stored through Spreedly and never touches your environment.   Immediate form validation, visual feedback such as credit card brand icons and tooltips, and a simple design make the form intuitive and predictable to users. The Express experience also scales from large screens all the way to mobile devices, letting you capture the increasing percentage of mobile commerce.

IMG_0150IMG_0153IMG_0152

Spreedly Express is the quickest way to securely accept payments in your app. Participate in our public beta today and integrate Spreedly Express into your payment page by following our quick start guide or taking a look at the sample app.

Marketplaces and Platforms: The Rise of Payment Methods

Not too long ago it was accurate to see separate challenges facing U.S. marketplaces versus those in the rest of the world. In the U.S., a marketplace targeting an installed merchant base had the daunting task of supporting a very large number of payment gateways, but the compensating benefit of nearly universal penetration of credit and debit cards greatly simplifying what payment methods they needed to support. In Europe and the rest of the world the available payment gateways (PSP’s) were much more limited and regional, but there was a big challenge around supporting all the non credit card, typically regional payment methods that consumers prefer. In the German market alone, bank to bank payments make up more than 50% of transactions that happen online, which is a huge contrast to the US.

Things are beginning to change in the U.S., however. Inputting card data into a web browser is relatively easy, but a mobile browser is a different story, and that’s making all participants in the ecosystem more interested in using “one click” payment buttons. In just the last two years we’ve had Apple Pay, Android Pay, Samsung Pay and Visa Checkout, and just this month American Express jumped into the fray with AMEX express checkout.

In addition to the challenge of mobile payments, PayPal is changing the payments landscape in the U.S. (again). Newly liberated from eBay, PayPal now has free reign to pursue its own agenda, and is in the unenviable position of being a threat to nearly everyone. The card networks dislike PayPal as they encourage transactions that avoid the card network rails, with the Visa CEO recently noting on an earnings call: “…that PayPal uses Visa transactions as a vein to “mine from” and possibly disintermediate the relationship between Visa and clients and is something that is “not sustainable for the long term.” Mobile OS providers like Apple Pay also view PayPal as a threat because PayPal as a payment method is cross platform and thus removes tie in to any particular mobile OS or phone. (Total aside: if Apple Pay ever gains real traction from a transaction perspective I could see Google buying PayPal – if it’s still on the market at that time.) Further, PayPal also owns and controls Venmo, one of the fastest growing peer to peer payment methods, which is yet another threat to many of the other payments players.

So the arrival of mobile is changing how consumers actually pay, which is creating the sense that it’s a unique time when there will be real change in consumer payment activities, and thus the potential for a wholesale re-drawing of marketshare. The threat is a newly independent PayPal might be able to capture a good chunk of that given their head start in running their own ecosystem, combined with their cross platform and channel abilities. It all adds up to a surge in interest around non credit card payment methods.

To be clear actual adoption of these new payment methods is currently extremely low and there’s no guarantee they’ll succeed. The switch from web to mobile is moving people from the browser to apps and that in turn could dramatically reduce the number of times someone has to enter their credit card. Three or four years ago you would have used a web browser on SeatGeek to search for tickets and then clicked on the referral link to go to a third party site where you added your credit card and bought the tickets. If you used SeatGeek six times a year to search for and buy tickets that was six different times you put card details into a website. Now on SeatGeek mobile you set up your payment details once and never have to re-enter them again as they’re routing the payment for you behind the scenes. It’s not hard to see in the future having your card on file with a handful of the vertical apps you use most (some basket of Uber, HotelTonight, SeatGeek, Zomato, etc.) and a few dominant horizontal apps (Google, Amazon, Pinterest, etc.). So while mobile makes it harder to input card data, mobile app usage is greatly reducing the number of times per year we input card data at all.

Up till now, U.S. businesses have largely stuck to just accepting credit cards wherever possible. It will be interesting to watch and see if the advent of new payment methods force merchants and platforms to adopt non credit card payment methods in a meaningful way, and if they do, I suspect the first one most would add would be PayPal.

Spreedly aims to help our customers by adding those payment methods that gain real consumer traction through ever more friendly mobile and self checkout tools. We’re extremely interested to see what the payment method landscape looks like in three or more years from today, and can’t wait to continue supporting our customers in their effort to stay relevant as the territory changes.

Passing $1 billion in annual payment volume

We’re pleased to announce that in June 2015, 28 months after launching our new service and pivoting away from subscriptions, we’re now seeing more than $1 billion handled by the Spreedly platform annually. For context, in June 2014 we were running at an annualized payment volume of just over $300 million.

Since Spreedly is software as a service, we don’t directly take a percentage of revenue. Nevertheless, as a payments company this is a key milestone that reflects the value we provide marketplaces and platforms via a universal credit card tokenization offering that works with a world of financial partners.

Thanks to our all of our customers, from the earliest to the most recent, for trusting us with your business and enabling us to hit this milestone. We understand our criticality to your business and hope you draw additional encouragement from our growth.

Next stop: $10 billion!

Spreedly Disbursements Beta

Marketplaces, services that allow two or more groups of people to conduct commerce, come in a variety of forms. Consider service-based marketplaces like Uber or TaskRabbit, product-based marketplaces like Etsy, and event marketplaces like StubHub. While these marketplaces all serve different purposes, their common thread is in the need to federate the transfer of funds from a buyer to a seller. Collecting payments from buyers with Spreedly’s support of almost one hundred gateways has long been possible. Today we’re pleased to announce support for the other side of the marketplace equation: disbursements and payouts.

Disbursements and payouts are synonymous and are the compliment to collecting payments. While many traditional e-commerce businesses are only concerned with collecting funds, online marketplaces require the ability to distribute funds as well. Spreedly Disbursements is designed to do just this – allow marketplaces to disburse funds to individuals across a variety of services. When used in concert with our existing payments support, Spreedly is the perfect platform for facilitating marketplace commerce.

Our private beta starts today with initial support for payouts to PayPal accounts. Over the coming weeks we look forward to hearing from interested customers as we add support for a wide variety of disbursement endpoints. Please let us know if you’re interested in using disbursements for your marketplace and what additional providers you’d like to see.

Introducing support for third party tokens

One of Spreedly’s core features is the ability to generate a universal credit card token that will work across any of the 100+ endpoints that we support today. This helps platforms and marketplaces create a frictionless payments experience by separating tokenization and card data storage from the gateway processing the transaction. This is powerful because it allows buyers on your platform to purchase from different sellers without re-entering their card data.

When a new merchant signs-up to a Spreedly-powered platform or marketplace, they’ll typically ask their third party vault to do a one-time export of their existing card data and we then re-map that data to a universal Spreedly token. But what about cases where that’s not possible? Perhaps the third party vault doesn’t believe in data portability or charges prohibitively expensive fees for a merchant to get their data out. Previously there was no good solution, but now with our ability to support third party tokens a merchant can continue to process transactions using their existing gateway-specific tokens from within their Spreedly environment. Then, as new customers are acquired (using our PCI compliant payment forms) or existing ones update their payment details, the merchant can progressively move their entire customer base to Spreedly’s universal token solution that will work across any of our supported gateways or API endpoints.

While the third party token will only work against a specific endpoint, it’s a great way for Spreedly customers to rapidly onboard new merchants to their platform that are happy with their existing gateway for the foreseeable future. Support for third party tokens is available for the list of gateways where we support third party vaulting.

Mobile, Marketplaces and Platforms

The transition from web to mobile includes a consumer behavioral change of using mobile apps instead of a web browser. This transition is changing the way commerce happens online, since consumers are less likely to enter their CC data into a mobile app due to the form factor. Further, redirecting users to a third party site for a transaction was workable in a web browser but can be a disastrous user experience in a mobile/app world, with many third parties having poor flows on the web that are horrific on mobile. A poor purchase flow hurts all 3 parties involved – consumer, merchant, and payment provider – as it results in much lower conversion rates.

One point of proof of this change was the announcement this week that Google is going to roll out a “Buy Now” button.  Just a few years ago consumers ready to buy a product would pull up a web browser, search on Google, click an ad and go to the website, enter in their CC and all their address information and purchase the product. In a mobile world they now open their Amazon app, search for the product, click buy and get free shipping via Prime. Google sees this as a major threat since it pulls away searchers intent on buying, who in turn are the consumers that advertisers are willing to pay to reach.

This new type of consumer buying behavior creates several risks and opportunities for merchants. The first thing is the “marketplaceization” of online commerce (yes I totally just made that up). For ease and security reasons consumers will only want to work with a finite number of apps on their mobile devices. Those apps will need to include search (choice) and payment (security and ease). The result of these pressures will result in 3 to 4 very large cross vertical marketplaces – Amazon, Alibaba, and Google if they can pull it off – and a host of focused vertical marketplaces: travel, business services, transportation, ticketing, donations, healthcare, etc.

If I’m making an impulse buy to purchase two tickets to the Durham Bulls baseball game tonight I’m going to want to open SeatGeek, search quickly, get a recommendation on the best value seats then click the buy button and be done. There’s a chance I’ll download the Durham Bulls or MLB mobile app, get comfortable with the UI, enter my card data and address and then buy, but the conversion percentage drops dramatically especially in the context of an impulse buy. That’s why these marketplaces can work for all 3 participants. The consumer is happier, the marketplace is driving incremental sales (discovery) and/or higher conversion rates than a stand alone app, and the merchant moves more product.

Spreedly is focused on enabling the payments component for platforms and marketplaces. Discovery and search apps ready to enable commerce need to securely store a card once and then allow the consumer to buy multiple times across all the different merchants on their platform or in their marketplace. That could mean using Stripe Connect or WePay to create a merchant account for sellers (a common approach we see new startups just launching take), but larger merchants tend to already have a merchant account and feel strongly about being the merchant of record and are adamant about not using something new. And there may be a need to transact against existing 3rd party API’s – Expedia, StubHub, Walmart, etc. – to pass in orders, a use case traditional payment providers don’t support. Spreedly is a tool that marketplaces can leverage to support all 3 choices in any combination they need, and improves the experience for all parties involved.

To be sure, web/browser based commerce isn’t going away soon. However as online commerce grows within mobile apps the winners of each vertical will tie together discovery, selection, payment, and customer satisfaction. Merchants may fear the power of their vertical leaders but they may also see reduced development costs and incremental revenue by effectively outsourcing their development and advertising efforts.

Credit Card Portability

It wasn’t too long ago that nearly all online payment gateways refused to return your credit card data when closing your account. It was the ultimate case of lock-in; you can change to a new merchant account and payment gateway but you’ll be asking all of your customers to re-enter their credit card data.

Braintree really deserves the credit as the first payment company to reject this approach. They even helped create the Credit Card Data Portability group. It was probably helped that at the time they were the new payment provider on the block seeing a lot of potential customers locked to their old providers.

At Spreedly, we’ve embraced the concept of card portability from the very beginning. Now we’re taking it a step further. You no longer even have to ask Spreedly to get your data back. Via our API, you can securely move card data from your PCI secure Spreedly environment directly into that of a PCI compliant gateway. The caveat is that the gateway has to support the concept. You can learn more about it here in our docs. 

If your preferred gateway isn’t supported we’ll still do a manual export upon request. However over time we expect to be continuously expanding the list of supported gateways over time. Our goal here is the ultimate flexibility and peace of mind.

Spreedly Releases Universal Apple Pay Support

Spreedly helps minimize PCI compliance scope and reduce development costs for platforms and merchants that work with multiple payment gateways and/or third party order processing API’s. We do that via a universal credit card token that you store once but use anywhere. We want that story to remain the same as we add support for mobile platform payment services like Apple Pay. We now support the ability to use Apple Pay payments across compatible endpoints, without being locked into a single gateway. Here’s how it works:

  1. You provision your Apple Pay certificate from Spreedly instead of any single gateway.
  2. To execute a transaction, send the Apple Pay payment token to Spreedly along with the gateway you wish to execute against.
  3. Spreedly decrypts the payment token using your Apple Pay certificate and passes the decrypted card number and cryptogram to the gateway, which processes the transaction.

Having Spreedly manage the Apple Pay decryption has several benefits including: 1) the flexibility to process against more than one gateway within the same iOS application, 2) the freedom to change gateways without re-provisioning your certificate and having to release an app update, and 3) the ability to execute against non-gateway payments APIs.

The main requirement for Spreedly’s Apple Pay support during this beta period is that the endpoint’s API supports network tokenization (basically, that it accepts a card number and corresponding “cryptogram” which provides additional security and verification to the transaction). The introduction of Apple Pay has many providers adding support for network tokenization so please contact us if your gateway or endpoint is not yet supported by Spreedly.

Crossing $50 million per month

At Spreedly we’re challenging the status quo that a single payment stack is the right way to scale for web and mobile payments. December 2014 was our 22nd month since we (pivoted) launched Spreedly as a service that solves for the development and data ownership/PCI challenges in digital payments and maximizes the ease with where and how you transact with your data.  As the blog post title states our customers processed $50 million in credit card transactions on our platform for the month of December 2014.

Many of our earliest customers took a big gamble on relying on such a small startup to help power their payments. So we want to let you know that we’re making great progress and plan to be here for a long time in the future. And better still if you’re one of those who’s been on the fence come on in the water’s fine.

Using an iFrame Payment Form with Spreedly

PCI-DSS v3.0, which went into effect on January 1st of this year, mandates the use of an iFrame-based payment form for merchants wishing to minimize PCI compliance scope (defined as the ability to self-assess using the SAQ A questionnaire instead of the more onerous SAQ A-EP). We previously wrote about maintaining PCI compliance in light of the new PCI-DSS requirements and invited customers into our iFrame payment form private beta program. Since then we’ve worked with several customers to integrate the payment form into their payment page and are now making the iFrame payment form available to all customers as a public beta.

As a public beta, the iFrame payment form is functionally complete and available to all customers wishing to integrate it in their production systems. Although changes are expected before general availability, the iFrame form is implemented in a way that avoids breaking changes unless an upgrade is explicitly initiated.

We’ve created a sample app showing the iFrame payment form integrated into a typical checkout page, highlighting the ability to maintain a consistent UX even when using content served by Spreedly. As you begin the process of reassessing your PCI compliance in 2015, please review our iFrame payment form documentation and integrate it into your systems to lessen your PCI burden.

PCI-DSS v3.0 for Online Merchants

Nothing strikes fear in the heart of an online merchant quite like PCI-DSS – the set of “technical and operational requirements designed to protect cardholder data” put forth by the credit card networks (Visa, MasterCard, etc…). If you accept credit cards online, even if you’re not storing or processing those cards yourself, you need to be aware of its requirements and prepared to invest some time into compliance.

The recent upgrade of PCI-DSS from v2.0 to v3.0 introduced some important changes, making now a good time to review your steps to compliance as well as highlight what’s changed.

Do I have to get PCI certified?

If you accept credit cards from your customers then, yes[1].

Many gateways and online payment processing solutions will claim their drop-in credit card widgets exclude you from PCI compliance or make you PCI compliant. This is not true. Even if a third party is handling the collection, processing, and storage of protected cardholder data, you must still go through the PCI assessment process. What these type of solutions do, including Spreedly’s, is reduce your compliance burden. You still have to certify, but can often do so with much less effort than if you were processing and storing the card data yourself.

How do I get PCI certified?

PCI certification takes two forms: Self-assessment (i.e. do-it-yourself) or hiring a third party QSA (Qualified Security Assessor). Though there are obvious advantages to self-assessing, including effort and cost, your ability to self-asses is dependent on your annual transaction volume and is reflected in the resulting level of PCI certification (1-4) you attain.

The following table describes the relationship between your transaction volume, required assessment approach, and level of certification:

If you have… then you can… to achieve
less than 20,000 online transactions per year self-assess PCI Level 4 certification
between 20,000 and 1 million online transactions per year self-assess PCI Level 3 certification
between 1 million and 6 million online transactions per year self-assess PCI Level 2 certification
over 6 million online transactions per year hire an independent assessor (QSA) PCI Level 1 certification

Note: While PCI-DSS outlines the requirements to become certified, there are subtle differences across payment networks (the table above was created from the Visa merchant guidelines). It is ultimately up to your merchant/acquiring bank to determine what is required for your compliance. Please be sure to check with them before beginning the compliance process.

How do I self-assess?

If you are processing less than 6 million online transactions per year it’s quite likely you can self-assess. This is a good thing, but you’re not out of the woods yet. Depending on your level of involvement in handling card data, you may still need to complete a lengthy questionnaire and perform an extensive internal review.

Self-assessment for online merchants usually occurs by filling out one of three self-assessment questionnaires (SAQs). Listed in increasing order of scope they are SAQ A, SAQ A-EP and SAQ D. By way of comparison, the SAQ A has fourteen questions listed while the SAQ A-EP has over one hundred across almost thirty pages. Assessing under SAQ A is, for obvious reasons, the goal of most online merchants.

So can you use the SAQ A? It depends on your technology and provider choices, both of which dictate how card data passes from the consumer, through (or around) you, and onto your gateway:

If your systems… then use
do not touch, process or store cardholder data, and do not serve any card collection forms SAQ A
do not touch, process or store cardholder data, but do serve card collection forms SAQ A-EP
do touch, process or store cardholder data SAQ D

SAQ A-EP is a new questionnaire, as of PCI-DSS v3.0, and its distinction from SAQ A is a subtle but important one…

SAQ A vs. SAQ A-EP

Prior to PCI-DSS v3.0, merchants that used Javascript libraries or transparent-redirect forms from PCI DSS compliant third-party service providers were able to self-assess using SAQ A. These two approaches let the merchant host the payment page, with the sensitive card data being passed directly from the user’s browser to the gateway, bypassing the merchant all together.

With Version 3 of PCI, however, merchants can no longer even host the payment page if they wish to qualify for SAQ A. In order to qualify for SAQ A you must use a payment form that is hosted by and submits directly to the compliant third party. In pure browser technology terms this means that you must use an iFrame-delivered payment form or a hosted payment page from your payment processor[2].

Having a payment form that is served by and submitted to a compliant third party reduces the attack vectors by which a malicious party is able to gain access to a user’s entered credit card data. For instance, an attacker that gains access to your merchant systems can no longer compromise your payment page and siphon off card data before submitting it to the intended processor. The card payment form is protected from such intrusions by web browsers’ cross-domain security policies which limit the ability for pages on one domain to access the content of pages on another domain.

While there are always risks of compromise for any approach, PCI-DSS has determined that an iFrame or hosted payment form is less susceptible than an in-merchant form.

Spreedly customers wishing to switch to an iFrame-based payment form can contact us to take part in our iFrame beta program.

Proof of compliance

Once you have self-assessed using the appropriate questionnaire you will need to fill out an attestation of compliance, or AOC, to formally declare your PCI compliance results. If you have gone through a review led by an independent QSA, you will be issued an AOC.

In addition to the AOC, which needs to be reviewed and re-issued on an annual basis, you will need to sign up for a quarterly security scan of your systems from an outside provider. Together with the AOC, the quarterly scan verifies that you are maintaining your PCI compliance. An example of both the AOC and scan can be found on Spreedly’s PCI page.

Summary

PCI is not for the feint of heart, but it can be managed. When evaluating your compliance, keep the following in mind:

  • What level of compliance you need is determined by your merchant bank, informed by the number of annual transactions you are processing.
  • Self-assessing is less costly and time consuming, but is only an option for merchants seeking less than a PCI Level 1 certification.
  • If self-assessing, using a PCI compliant service provider that provides an iFrame or hosted payment page results in the least compliance burden.
  • An AOC, together with a quarterly scan, is your proof of PCI compliance.

Good luck out there!

Spreedly and “Buy Buttons”

For many years sellers on the Internet set up their website, hooked up a payment gateway and started selling, and buyers came from search engines, either via SEO or paid search. With the rise of social sites like Facebook, Twitter, and Pinterest merchants found a new avenue of traffic from social media. All these different channels employed advertising models to generate revenue while the merchant focused on e-commerce/payment/subscription models. Things were simple.

However, the rise of mobile at the expense of web has major impacts for “where” online commerce happens, with many online experiences moving from the web to device-based apps. In addition, Amazon has created a closed loop of mobile app, search, one click buy, deliver that is threatening Google’s dominance of search. This is creating enough of a threat that now Google might build a “buy now” button to try to protect themselves.

New startups, focused on social and search, have embraced optimizing the app experience – indeed some have ignored the need for a traditional website at all – so the rise of the mobile app is impacting the traditional flow of converting advertising to realizable commerce. Today, while end users are still being redirected to merchants to make the final purchase, often these experiences are starting on a mobile app with the end user being redirected to a more traditional web browser session to complete the process. Or perhaps they’re instead moving from an extremely good mobile app experience to a relatively poor one, which can be a jarring experience that impacts conversion rates. Either way, users – particularly social users – hate the disjointed experience and are frustrated by the inconsistent flow, often blaming both the merchant and the social platform. This has created demand for social platforms to optimize the e-commerce experience and ensure the checkout flow is as seamless as possible given they now have skin in the game.

More specific to search (vs. social), the rise of Amazon has become a real threat to Google. Again, this is mostly app vs web, with mobile users opening a well designed Amazon app and searching for a particular product. The ease and simplicity of one click payments and shipping makes for a completely closed loop. The natural response is for Google to be pulled into controlling e-commerce that originates across its search platform, yet it’s unlikely that merchants, even if they’re feeling the pinch from Amazon, are excited about moving more of their relationship to Google. While there will always be tension in this model over “who owns the customer,” the combined Amazon and Google threat creates a very viable opportunity for vertical search and social solutions to thrive. Google and Amazon will inevitably compete on price (the lower the merchant price the better), but optimized vertical search services on the other hand often bring in a different, less price sensitive buyer that merchants find desirable. A good example of this is Wanelo, who leverages it to achieve 10 – 15% in referral fees.

There are several core components to a “Buy Now” button:

  • The end user wants an Amazon or Uber like one click experience. They need their payment method stored securely and easily accessed for repeat purchases. In addition, support for newer payment methods like Apple Pay, Google Wallet and Paypal need to be seamless choices.
  • Ideally the end user stays within the originating mobile app but the commerce still happens with the merchant. By staying within the mobile app conversion can be optimized. By transacting against the merchant’s existing payment infrastructure the money flow is not interrupted. This is key in terms of customer support, refunds and returns etc. This also helps solve the dilemma around customer ownership, since it’s now explicitly shared.
  • Merchants have to allow third parties to freely access and present accurate inventory real-time.

Spreedly helps social and search services securely store and tokenize payment data, and this truly universal token can be used across multiple merchants over time giving complete independence. Then via our wide range of pre-existing integrations to gateways and third party API’s we help ensure the end user can stay in app while the transaction processing still happens via the merchant’s existing processing relationship. What we don’t solve today is supporting the entire product or inventory management component; we at least help by acting as a passthrough, but the development work falls on the social/search platform and merchants to get the integration up and running. That may be why areas like ticketing (SeatGeek) and hotel inventory (Top10) have been early Spreedly adopters: the concept of supporting affiliate sellers was already in place, so optimizing payments and checkout flow was the final piece of the puzzle for them.

The next wave of mobile apps, which startups like Wildcard are helping create, will only increase the desire from end users for a complete end to end search, share and buy within a singular experience. We look forward to helping solve the payments related challenges.

Spreedly’s Take on Apple Pay

For those of us in the payments industry, the announcement of Apple Pay in September was one of conflicting emotions. We found it both exciting and, yet, unfulfilling. Exciting in that it represented a compelling evolution of digital payments, but unfulfilling in that we had so many more questions than were answered in the initial announcement. How does it really work? How does it integrate with the existing card payment process? Can it be unlocked to work with any payment processor?

In the two months since that initial announcement, and the weeks since Apple Pay was actually released, Spreedly has learned a lot about Apple Pay. I’d like to give an update on our plans for supporting Apple Pay and why we’re excited about the opportunity.

How does Apple Pay work?

Much of Apple’s marketing around Apple Pay uses new or existing payment terms in non-standard ways. While this simplifies the consumer message, it makes it difficult to understand how the technology works. Now that we’ve had some time to dig deeper, we understand what’s going on beneath the covers and can talk in more detail about the process.

Apple Pay is unique to Apple and its devices. However, it is enabled by an existing payment specification called the EMV payment tokenization spec. This specification governs how real credit cards are turned into channel-specific alias numbers (PANs), which offer a greater level of fraud protection. Apple utilizes this tokenization process, while adding its own process for getting the alias PAN from the device to the merchant’s gateway.

You can visualize the payment flow, from when the card gets added to iOS’s Passbook through to the transaction hitting merchant account, as follows:

Please feel free to share this diagram

While Apple Pay represents a new, polished, consumer experience, it leans heavily on the existing EMV tokenization spec, which dictates how the alias credit card numbers are issued, identified and converted within the payment process. While it’s likely Apple had a hand in constructing this specification, it is not unique to Apple and can be used by other vendors.

What is unique to Apple Pay is how the payment token is constructed and the role of gateways in decrypting the payment token to expose the alias PAN. At the time of transaction, Apple uses the certificate provisioned by the merchant to encrypt the alias PAN and associated data. This encrypted token is then passed directly to a gateway that supports Apple Pay (and has the certificate’s private key) which knows how to decrypt and unpack the payment token. From this the gateway extracts the alias PAN, which looks just like a normal credit card number, and passes it off to the rest of the payment process for approval.

How will Spreedly support Apple Pay?

Spreedly is not a gateway. It is a credit card vault that integrates with dozens of gateways and other PCI-compliant APIs. So how can Spreedly play a role in the Apple Pay payment process?

If you’ll notice, the responsibilities of a gateway, as it relates to Apple Pay, are minimal. A gateway is really only doing two things: 1) Managing the private key associated with the iOS app’s certificate and 2) decrypting the payment token at transaction time to access the alias PAN. As it turns out, you don’t need to be a gateway to do those things.

If Spreedly assumes the role of the gateway solely in managing the Apple Pay certificate and decrypting the Apple Pay payment token, it can provide a single Apple Pay experience on top of any of the over 70 gateways we support. Additionally, because a payment token looks and acts like a real credit card number to the majority of the payment stack, it can be sent to non-gateway providers like ticketing, travel and other vertical APIs.

Notice how Spreedly’s support of Apple Pay differs only minimally from the conventional, gateway-specific, flow:

At Spreedly, we enable new payment technology across the widest range of payment targets possible, and that’s how we’re approaching Apple Pay.

When can I use Apple Pay on Spreedly?

For customers on one of our current pricing plans, we’re targeting a GA release in the first quarter of next year. We are already hard at work on it and have a few existing customers working with us as we move towards a private beta. If you would like to be included in the beta, please let us know. We’re always interested in understanding your specific use-case and hearing your feedback.