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

The second option is
, 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. 

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

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.

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

Now for a more complicated case. Spreedly customer

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.

‍

Download the Payments Orchestration eBook Below