Spreedly Blog

Transaction Debugging on the New Spreedly Support Site

Today, we’re happy to announce the release of a dedicated support site, providing you with a single location to get help when you run into an issue using Spreedly. Beyond providing answers to common questions and connecting you with Spreedly’s excellent support people, we’re particularly excited to provide a transaction searching and debugging tool for you to more quickly diagnose why a transaction failed.

spreedly-support-site

 

Although our API provides endpoints to retrieve transaction information as well as the transcript of our communication with your payment gateway,  we’re making it even easier to pull up and view a transaction in a web interface. This is especially helpful in the case of a transaction failure when you’re trying to diagnose what might have happened. At times there are issues on the payment gateway side where some settings might need to be adjusted, but other times Spreedly may need to step in and help with the error returned. We’ve made it clear as to what the next steps should be to find out how to deal with a failed transaction.

To get started using transaction debugging, head over to https://support.spreedly.com. If you want to search for a transaction, just enter the token of the transaction you’re curious about and click the “Search Transactions” button. You’ll need to be logged in to your Spreedly account to view the transaction information.

We’ll be continuing to build out features and functionality in the coming months, so stay tuned. Let us know what you think and if there’s other information you’d find helpful in diagnosing your issues by emailing us at support@spreedly.com. With the addition of the new support site, we’re continuing to work hard to provide you the very best support possible.

Batch Export Beta Release

In 2014, Spreedly released Payment Method Distribution, the ability to send card data to external APIs such as Expedia.com and TicketMaster, and in doing so made your universal vault much more flexible and powerful. Today, we’re happy to announce the beta release of PMD batch export, which lets you send multiple cards in a single call to third party endpoints via SFTP. Ever since the release of PMD, this has been a commonly requested feature, and we’re excited to extend PMD to support this new use-case.

Batch export

Many third-party APIs accept a single PAN to do things such as reserve a travel itinerary or purchase tickets, and for this use-case Spreedly’s deliver endpoint lets you deliver any API call you want using a simple templating syntax. But for APIs that process many thousands of cards at a time sending cards one by one can be onerous and slow. Some examples of batch APIs are loyalty programs run by MasterCard and Visa, and even building ACH settlement files to charge against bank accounts.

With the new export API call, you can now specify a list of payment methods that should be added to the request body and Spreedly will automatically send them out, in the format you specify, as a single call. This makes interacting with batch APIs possible, and makes practical a whole new class of functionality for your business.

SFTP endpoints

Almost all the batch APIs we’ve been asked to integrate to rely on SFTP to upload a file to a secure server, and our initial release lets you export multiple cards at once using SFTP. Simply provision an SFTP receiver, and then invoke export using that receiver token. A file will be created per the template you specify and uploaded to the SFTP endpoint. All the same PMD request variables and functions that are available when delivering to an HTTP API are available when exporting to an SFTP endpoint, providing you with complete flexibility over the file format and data.

Try it out

Batch Export is currently a beta release, meaning it’s suitable for production use but may be tweaked before General Availability. If you’d like to take part in the beta program, please let us know by emailing support@spreedly.com and including which batch endpoint/API you need to integrate with. The functionality is self-service and publicly available (as all our functionality is), but we’d like to understand your use-case and support you closely during the beta period.

We’re excited to get this in your hands and can’t wait to see what you’ll make with the Batch Export API!

Reducing credit card declines: expiration dates

Credit cards in a row falling - credit card debt concept

Shoresh Shafei, Justin Benson & Nathaniel Talbott

We are excited to start mining Spreedly’s data – we have quite a lot of it – to surface interesting insights, trends, and if possible actionable results for merchants, payment gateways, and even consumers. While perhaps not as flashy as data science at a dating company, it should be safer to read at work, and we suspect there are a lot of kindred souls that find payments data as interesting as we do. Who doesn’t like getting better at making money?

As an independent credit card vault that allows our customers to route payments to their preferred payment partners, Spreedly facilitates online payments via more than 100 payment gateways and third party API’s in over 100 countries. With greater than 10 million credit cards stored, and working with hundreds of customers in different industry segments across the globe, Spreedly has unique access to a database of vaulted payment methods and executed transactions that can be used to start exploring important questions in the payment industry in order to help us all make smarter, data-supported decisions

card_countsIn a series of blog posts, we will use data analytics to address challenges our customers deal with that might also be of broader interest to the e-commerce and payments industry. What is the average lifetime of a credit card? Should companies, particularly subscription or “one click payment” e-commerce services, care about card types (i.e. Visa vs. MasterCard)? What can companies do to keep their vaulted payment methods clean and up to date? How do you reduce credit card decline rates?

Our first foray is in an area near and dear to subscription-based companies: customer churn related to lost, stolen, or expired cards. Services like Visa’s North American Account Updater can help with the problem, but they don’t cover all brands in all regions. So, what measures can merchants take to reduce credit card declines to improve their churn?

There are a number of different approaches, but for this post we want to focus on one particular area: the average expiration expectancy of a credit card once it hits the Spreedly vault. Expiring cards are a big driver of revenue churn and customer support/sales costs – no one likes chasing down customers for an updated card – and so understanding how cards expire may help us design for renewal success from day one.

As a startup, the pace at which cards are being stored in Spreedly is accelerating rapidly. In fact, 70% of all the cards stored in our vault have been added in just the last 12 months. That means we should represent a pretty “fresh” batch of cards when looking at our vault. One notable exception we’ll caveat is that we do imports from other payment providers on behalf of merchants; in such cases we’re inheriting a set of data into our vault that is of unknown age.

In Spreedly’s vault, Visa is the dominant card type (Figure 1). Visa cards comprise 63% of credit cards stored. MasterCard has 29% with American Express (denoted as AmEx in figures) at 6% and Discover card 2%.

exp_years_visa_mc

exp_years_amex_dis

Even with our “fresh” vault, millions of these cards will expire in the next 24 months. Figures 2-a and 2-b demonstrates the total number of cards in the next 4 years: just in in 2017 and 2018 alone more than 4 million cards in Spreedly’s vault will expire.

The bad news for our merchants is that not all cards are created equal! In fact the bulk of Visa and MasterCard brands in our vault expire in 2017 and 2018. MasterCard expirations peak in 2017 while Visa peaks in 2018. So the average expiration expectancy of a MasterCard stored in Spreedly is ~14 months while for Visa it’s ~ 21 months.

We can see a much longer expiration expectancy for the other brands we’re evaluating: ~ 34 months for American Express and ~35 months for Discover. This indicates that merchants should be less concerned about interrupted subscriptions due to expiring cards with customers using those brands. Meanwhile, merchants with more Visa and MasterCard branded cards may want to consider action to guarantee continued and uninterrupted service to their customers.

One of the most interesting things we found out of this specific analysis is that it calls into question the common belief that merchants should encourage customers to use credit cards with lower fees. For example, many merchants discourage usage of American Express cards due to the fact that there are higher processing fees associated with those cards vs. the more common Visa and MasterCard. Subscription or repeat commerce services that have employed that strategy may wish to revisit it – after confirming with their internal data – since those lower processing costs could be coming at the expense of customer churn.

We think it’s important to point out that to the best of our knowledge there is not a fixed range between issuing and expiration dates and the expiration dates for credit card companies are determined based on a variety of parameters including the applicant’s credit worthiness. Consequently, one cannot deduce a general rule that American Express and Discover have longer life expectancy than the other two; rather, we’re only noting interesting trends in Spreedly’s data set.

Having looked at how long until an average card expires, we wondered if there might be any other trends around expiration that could help merchants better manage their vaults. What we found is that there are distinct patterns around which months cards expire in. For each credit card type, figure 3 shows the ratio of the total number of that type expiring at a particular month per its total number in Spreedly’s vault. It appears the expiration months tend to peak twice a year at 6 month intervals: Visa and MasterCard both peak in March and October, while Discover peeks in May and November. The least fluctuation in expiration month belongs to American Express which drops down from ~ 9% per month for the first couple of months to less than 8% for May to December.

exp_month

Another noticeable fact is the downward trend of cards expiring in December. While 11% of Discover  cards expires in May, this ratio bottoms down at 4% in December. We observe a similar trend for Visa and MasterCard: the smallest percentage of expirations takes place in December.  Does this reflect a credit card issuer strategy to avoid masses of expired cards in the biggest shopping season of the year? We hope to further examine this question as Spreedly’s dataset continues to grow.

The data in Figure 3 suggest that first, subscription businesses – particularly venture funded startups and public companies – should consider seasonal and/or monthly adjustments to their churn based on the underlying activity of expiring cards. Second, services that proactively work to reduce churn should consider allocating resources differently, for example, for the month of March vs. the month of July. Both of these points are particularly true if there is a large percentage of Visa and MasterCard data within your vault.

***

If you enjoyed this post, please do share it on social media! Meanwhile, our data scientist would love to hear from you directly via email: shoresh@spreedly.com will land right in his inbox.

Photo courtesy of cover photo: BostonCoachBlog

RevolutionParts and Spreedly

One of our customers, RevolutionParts, has a nice post on migrating to Spreedly. Many of our customers are implementing a new payments service. RevolutionParts were different in that they were already with another provider and needing to make a change.

You can read the post over at their site if you’re interested in learning more. This would be most applicable if you sell a SaaS based service into a group of diverse merchants.

The end of social commerce 1.0?

Intent: “A determination to perform a particular act or to act in a particular manner for a specific reason; an aim or design; a resolution to use a certain means to reach an end.”

I recently saw the news about CosmicCart being acquired by PopSugar  (full disclosure, CosmicCart is a Spreedly customer). That came on the heels of PayPal acquiring Modest last August. Consolidation appears underway in the social commerce technology space. In addition, there’s been stories about disappointing traction for Pinterest’s commerce initiative (buyable pins), with large retailers reportedly seeing less than 10 transactions per day. Social commerce initiatives at Twitter and Facebook have also experienced stop/start existences (mostly stop?). Messenger apps like SnapChat flirt with commerce but, given the lack of traction experienced by others in the US, seem to be wisely holding back. So what went wrong?

It seems to be driven by one major tactical and one major strategic consideration. Tactically, managing payments and inventory is hard. Companies like Spreedly, Stripe and PayPal are trying to help solve the payments piece. On the inventory front, the launch of Stripe Relay, and PayPal’s acquisition of Modest, are designed to help solve a wide range of issues around displaying and fulfilling inventory across sites. It’s too early to tell if they’re going to be successful or not, but the challenge is certainly very large.

The second critical reason, and harder to solve than even hard tactical challenges, appears to be intent. The explosion of mobile use vs desktop might be a bit of a head fake when it comes to social commerce. Ben Thompson at Stratechery covers this well “Secondly, though, while using a PC required intent, the use of mobile devices occupies all of the available time around intent. It is only when we’re doing something specific that we aren’t using our phones, and the empty spaces of our lives are far greater than anyone imagined.”  All that time on mobile on social sites equates to browsing, creating tremendous advertising revenue opportunities for social networks. Purchasing, even with wonderfully frictionless single click checkouts and mobile payments, requires intent. And intent appears to be no more present (and due to the challenge of small screens perhaps less so?) on mobile than desktop. And mobile + social, at least today, appears to be very unconcerned with intent to purchase.

One way to test this theory is to look at mobile apps that are doing well with commerce. Uber, one of the earliest and best mobile payments experiences, starts with a very clear intent to purchase a service. SeatGeek? Clear intent to purchase tickets. Amazon, clear intent to purchase…well just about anything. Apps focused on intent to purchase from the very beginning, and thus branded in the mind of mobile users as designed for such, are currently succeeding at mobile commerce. Perhaps starting with meta-search (vertical mobile apps focused on optimizing search results) and then branching into commerce is also a viable road given how close search and buy intentions can be.

What does that mean for social commerce 2.0? The continued adoption of simplified payment options like Apple and Android Pay will help improve conversions. Solutions like Relay or Modest might help ease the challenges around inventory management. Without intent though, none of that matters very much. The way Facebook does payments well is if Messenger (its stand-alone messaging app) becomes a significant player as a customer service tool (“how would you like to pay for the plumber visit tomorrow?”). Or if Twitter can create a stand alone service with the customer support that is already happening in a massive way on its platform. These examples all rely on new apps or services from existing social players to drive or capture intent. Without it, there’s just a lot of browsing which, at best, might result in an Amazon price search and one click buy.

Papers, Please: Auditing SSH Access at Spreedly

As a PCI L1-compliant company, securing our Cardholder Data Environment (CDE) is central to what we do. The PCI Data Security Standards specify that all users accessing CDE systems must be uniquely identified–i.e., no shared user accounts. This is pretty standard, best practice stuff. You want to know who accessed what, when, and from where. These are necessary, but even more important is understanding ‘why’ a system is being accessed.

Although default auth and ssh logs will indeed inform us when systems are accessed, and by which user, these log entries lack important contextual information that might indicate why the system is being accessed, at all:

  • A deploy?
  • Configuration Management?
  • A quick informational query?
  • A long-running interactive session?

It can sometimes be difficult or impossible to infer these things from the raw logs.

Also, the default logs are not easy to audit for patterns of use:

  • How long is each session duration?
  • Are there days-old tmux sessions running?
  • Are deploys or configuration management runs getting faster or slowing down over time?

This kind of useful information simply isn’t baked into the logs by default.

Ideally, we’d like to understand the intent behind every system access while looking at a stream of log events. We’d like to force ourselves to think about why we are accessing any CDE system, and to log our expressed intention for the access. And, we’d like increased visibility into our patterns of access.

In this post, we’ll examine the system we’ve implemented to improve the audit posture of our SSH logs beyond PCI-DSS requirements, and make higher-level analysis of our SSH log data easier.

Just the Facts, Ma’am.

First, we need to talk about some relevant bits of our Cardholder Data Environment.

SSH everywhere

All CDE systems run either FreeBSD or Ubuntu Linux. All access to CDE systems occurs via SSH. SSH sessions come in one of two basic flavors: interactive and non-interactive.

Interactive Sessions

Interactive means attached to a TTY, almost always with a shell process. It’s what you get when you log into a remote system with ‘ssh user@remote‘. For logins, the default shell process to invoke is specified in /etc/passwd for each user.

Non-interactive Session

A non-interactive SSH session lacks an attached remote terminal and sends the result of some command to your local terminal directly. This type of session is what you’d get if you added a command argument to your ssh login: ‘ssh user@remote somecommand‘.

Non-interactive sessions are not just for ad-hoc command use, however. We use Ansible for configuration management and Capistrano for deployment. Both of these tools generate lots of non-interactive SSH sessions.

We want to quickly see which SSH sessions are normal configuration or deployment activity, so we’ll need a way to identify these types of ssh ‘clients’.

Centralized Log Processing

We use rsyslog to forward all system logs on each host to a central log aggregator. This host, in turn, emits centralized log events to our event processor, Riemann.

This flexible log processing pipeline allows us to do many things: deliver messages to Slack, issue PagerDuty alerts, perform basic anomaly detection, collect and send system telemetry data to Librato for graphing, and more. We also reap the benefit of a clear separation of concerns: local processes don’t have to know or care about what is being done with the log data they emit, and centralized processing of the aggregate log data allows us to do things we can’t do piecemeal on each host: things like global anomaly detection, or batching calls to external services with rolled-up data to avoid API rate limiting.

Logs All the Way Down

Every connection to the CDE should generate a log event. These log events should detail:

* connecting username
* connecting ip address
* the command being executed
* non-interactive client type (if applicable)
* why the CDE is being accessed

Getting Fancy with Logging

The first hurdle is getting all the data we need onto the remote CDE host.

Passing Data to SSH

It turns out that most of the information we want to log is already available to the ssh process via the USER and SSH_CONNECTION environment variables, but our auditing mechanism still needs a way for users to pass along two fields: their stated intent for accessing the system, and what kind of client is connecting (e.g. Ansible or Capistrano).

This data passing happens via the AcceptEnv directive in /etc/ssh/sshd_config. Customarily, this mechanism is used to export the local user’s language/locale settings to the server: environment variables like LANG, LC_CTYPE, and LC_ALL are common. The ssh client configuration, however, supports sending arbitrary ENV variables via the SendEnv directive in a user’s ~/.ssh/config. We’ll use this mechanism to forward special environment variables we set locally on our machines to the CDE servers when we make an SSH connection.

We’ll call our environment variables RATIONALE and RATIONALE_CLIENT. This means that configuring SendEnv RATIONALE* on the client side, and configuring AcceptEnv RATIONALE* on the server side gets the job done. It is important to pick variables that are not used by any known system on the server, as we’ll be setting these remotely for the duration of each users’ session.

The following demonstrates the ENV mechanism with these changes in place:

Teaching SSH to Log

We initially experimented a bit with modified .bashrc and profile scripts, trying to get them to emit a log event upon every shell login, but this proved to be brittle, error-prone, and circumventable.

We need a solution that will work portably across all our hosts, and regardless of which shell a user might be invoking. It would be best if we could coax SSH itself into emitting our log events properly.

To do this, we make use of another really useful trick SSH has up its sleeve: the ForceCommand directive in /etc/ssh/sshd_config.

From the man(5) sshd_config page:

ForceCommand

Forces the execution of the command specified by ForceCommand,
ignoring any command supplied by the client and ~/.ssh/rc if
present. The command is invoked by using the user’s login shell
with the -c option. This applies to shell, command, or subsystem
execution. The command originally supplied by the client is
available in the SSH_ORIGINAL_COMMAND environment variable.

With ForceCommand, it is possible to do arbitrarily interesting things to your SSH sessions. We’re not doing anything too complex, so we’ll implement the logging mechanism via a small Bash script that:

  • determines the client type, if RATIONALE_CLIENT is not specified
  • extracts the connecting ip address from the SSH_CONNECTION var
  • prompts for a RATIONALE if missing and the session is interactive
  • logs the client type, ip, username, rationale, and the requested command with the logger command
  • uses SSH_ORIGINAL_COMMAND to actually perform the requested command (invoke a shell, run an ad-hoc command, etc)
  • logs the command duration upon completion, again with the logger command

This script has a few other niceties, like signal traps that prevent common keyboard interrupts, but the basic idea is to decorate any command passed to SSH with calls to logger.

Integration with Ansible and Capistrano

Interactive sessions are great from an audit viewpoint: they provide access to a terminal, so even if a user chooses not to export a RATIONALE variable locally, we can still prompt them for one before allowing login to continue.

Non-interactive commands run over ssh by definition do not give us the ability to prompt for a RATIONALE. In the best case, a user (or, more likely, a script or tool) can choose to export RATIONALE and RATIONALE_CLIENT variables.

It turns out that Ansible uses OpenSSH under the covers, and thus supports the SendEnv configuration we set in ~/.ssh/config. All we need to do is ensure that RATIONALE is exported when Ansible fires.

We already use wrapper scripts to invoke Ansible, so this was a natural fit: we ensure that RATIONALE is set locally before the ansible or ansible-playbook tools run, and automatically set the RATIONALE_CLIENT to ‘ansible’ for these.

Capistrano uses the net-ssh gem, which sadly does not respect ~/.ssh/config. Supporting a RATIONALE export for Capistrano requires a bit more work: in each Capfile, we do:

This provides useful deployment information to our central log stream with each deploy action, across several apps.

Et Voilà!

Now, when SSHing into a CDE host over our VPN, authorized users who have not exported a RATIONALE environment variable are challenged with the following prompt:

This prompt is persistent and must be satisfied before the user’s shell is invoked. The mechanism results in log entries like:

Getting from default SSH access logs to parsable, actionable log entries with clear descriptions of the intent behind each access took a little work. The RATIONALE: prompt during interactive SSH sessions adds an extra step that must be thought about, but we think that’s a feature, not a bug. Lots of interactive sessions in production are an anti-pattern, and this auditing mechanism helps us to better understand our patterns of use. In practice, it really hasn’t been too onerous. We think the results are worth it!

100 gateways!

Spreedly Gateways 2015-12-11 09-46-20

We crossed a big milestone with the recent addition of support for Payeezy from First Data; support for 100 gateways! I’m not sure we realized back when starting Spreedly that we would end up supporting quite so many gateways. Yet here we are passing more than 100 supported and several more in the pipeline.

It’s a big achievement and part of our ongoing vision to decouple the development experience from the financial stack to better serve all constituents in the payments ecosystem.

Spreedly iOS SDK Beta

Today we’re happy to announce the release of the Spreedly iOS SDK beta, enabling you to easily tokenize payment data from within your iOS app. Over the last few months, we’ve been excited to see an increase in the number of mobile apps integrated with Spreedly and felt that the time was right to provide full native support. So if you’re building an iOS app or are thinking of switching to Spreedly, it’s now easier than ever to get up and running.

In addition to credit cards, we’ve made it trivial to tokenize Apple Pay payment methods so your users can have a frictionless payments experience while you get the benefits of tokenization. Once your user has authorized a payment via Apple Pay in your app, just pass that payment authorization to the Spreedly iOS SDK and we’ll take care of the rest.

For more information, check out our updated mobile development docs.

We’ll be continuing to build out features and functionality in the coming months so stay tuned. With this addition, we’re continuing our goal to provide a wealth of options for you to easily get payment data into Spreedly. Please participate in our public beta today and feel free to contact us if you have any questions or something’s not working as you’d expect.

Interested in an Android SDK? Stay tuned…

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

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.