Spreedly Blog

Hacking Payment Forms

One of the most important, if not unsettling, principles in security is that there is no such thing as absolute security. Given enough time and resources, all security measures can be bypassed. Look no further than the Snowden revelations which exposed the degree to which a variety of technologies previously thought to be secure had, in fact, already been compromised. The best that any organization can do is to increase the cost of hacking to where the expense doesn’t justify the reward, and to be as aware as possible to when breaches occur.

As an organization that deals with securing payment information, this reality affects how we design our systems and the tools our merchant customers use. We are ultimately governed by the broad guidelines set forth in PCI-DSS, the latest of which added the following requirement to the most common assessment questionnaire:

The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).

This wrinkle may seem innocuous at first, but it has important implications. I’d like to show how the payment form you may be using, even if from a respected gateway, potentially invalidates your ability to use PCI v3 SAQ A assessment and exposes you to undue risk.

Attack Vector

Specifying that sensitive payment forms originate directly from the gateway/third-party service prevents a compromise of the merchant’s servers from accessing user’s payment information directly. For instance, if a payment form is served from mystore.com, and mystore.com is hacked, the hacker will be able to place an unobtrusive javascript agent on the payment page which will have direct access to the user’s card information.

Only by rendering the sensitive fields of the payment form in an iFrame, themselves delivered directly from the gateway or processor servers, will a compromised merchant payment page not have access to the user’s credit card information. The browser’s security model prevents access to the DOM of an iFrame from the host page, eliminating that particular vector.

Any payment form that renders within the DOM of a merchant controlled page, even if it’s a javascript library served from the gateway’s servers, violates the spirit of PCI-DSS requirement and should only be implemented after an understanding of the increased risks.

One of the payment forms most susceptible to this type of attack is the self-hosted or transparent redirect payment form.

Self-hosted Payment Forms

Many companies offer a self-hosted solution to help merchants collect card information. Prior to PCI DSS v3, using this approach allowed you to use the SAQ A, the simplest form of self-assessment. The basic implementation is to add a payment form to your web page including input fields for the card number and CVV.  The form is then submitted directly to the gateway server which redirects back to the merchant site with a generated token. Only the token, which is completely safe, is stored on your server. This sounds like a good thing, right? 


I created a repo of hacked payment pages which contains a self hosted payment form page, `index.html`, and a page that uses the Spreedly redirect, `spreedly-redirect.html`. Every page in this repo contains a script tag which pulls in a malicious script, a basic Cross-Site Scripting (XSS) attack which mimics what an attacker can do should the merchant servers be compromised.

This repo contains a little server that serves a malicious script, `malicious.js` and accepts POSTs of siphoned off form data.  The script is very basic. It adds a keydown listener to inputs on the infected page. When a key is pressed, a function runs which goes through every input, grabs form values and sends them off to the malicious server. This script could be much more elegant, but this works for demonstration purposes. The main point of this demonstration is that the script does not care about the semantics of the payment form – if the form is in the DOM it can be siphoned.

When I submit the form to my server using either the self-hosted form or the transparent redirect form, no PCI sensitive data reaches my server. Unfortunately, the malicious script was able to successfully send all the information to the hacker’s server. Here is the log on the hacker’s server. It clearly shows that the number and cvv were compromised.

Malicious server received data:
{"first_name":"Miki", "last_name":"Rezentes", "card_number":"4111111111111111", "cvv":"123", "month":"01", "year":"2025"}

This illustrates that payment forms rendered within the host page DOM are vulnerable to silent attacks. There is no log evidence that the data is being stripped from the payment form and sent off to ne’er do wells. As long as the malicious script shares the same DOM as the payment form, the sensitive data is being breached and no one has any idea it is happening. It could go on for years. Even if the script is found, there is little way to figure out how long the attack has been going on or the extent of the damage. The lack of visibility into the attack is frightening from a security perspective. If there is no way to detect an attack, you are basically living on a wing and a prayer. Not a great strategy for keeping your customer’s data safe.

Let’s look at how an iFrame-based payment form, while still vulnerable to a host page compromise, offers additional assurances.

iFrame Payment Forms

If you’re a merchant hoping to rely on the simple SAQ A questionnaire to achieve PCI compliance you can’t rely on solutions that just render a payment form within your host page, even if it’s a javascript library that renders the fields inline (for the reasons described above – if the fields are in the host page DOM, they are vulnerable). To qualify for the SAQ A while still controlling the payment form UX you must use:

an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process

Unlike self-hosted solutions, using an iFrame based solution thwarts scripts on the host page from accessing sensitive data within the iFrames. The browser security model prevents the host page from accessing the iFrame DOM when the two pages aren’t shared from the same server.

By way of example, the hacked-form repo also contains a page that utilizes Spreedly’s iFrame solution, `iframe.html`. When I enter my information into the payment form using Spreedly’s iFrame, the input fields are protected from scripts on the parent page. Here is the hacker’s log after submitting customer information via iFrame:

Malicious server received data:
{"payment_method_token":"PmmqnOe5ccyM9i5xTyQZqdtvk8q", "first_name":"Miki", "last_name":"Rezentes", "month":"12", "year":"2017"}

The sensitive card data inside the iFrame fields could not be siphoned. Instead, only the values exposed to the host page were captured.

iFrame Vulnerabilities

It may appear that using an iFrame solution provides absolute security. But wait – didn’t we learn earlier that there’s no such thing as absolute security? In fact, there is a way to siphon cardholder data when using iFrame payment forms from compromised merchant servers.

Upon hacking the merchant’s host page, the attacker could replace our iFrame form with their own using javascript that removes and adds elements to the DOM. The user wouldn’t know any better since the compromised form is visually identical to the secure version. As the user enters their card information into the compromised form, the attacker can siphon the information back to their servers. If they stopped here, however, the payment page wouldn’t be fully functional (since no transaction takes place).

To cover their tracks the attacker would also send a real request for payment method tokenization to the gateway, which would preserve the expected workflow and delay discovery. From the card holder’s perspective, everything is normal, they are simply entering their card data. From the merchant’s perspective, everything is normal, since the result is a proper payment method token. From the gateway’s perspective, everything is normal. They are making and returning tokens. It appears all is well, but in fact, a hacker is sitting quietly on the compromised payment page, replacing the real payment form with a version that silently siphons sensitive data.

So does this mean that iFrame based solutions are just as flawed as same-DOM approaches like transparent redirects? Not quite…

iFrame Abuse Protections

There is no way to prevent all attacks. However, with an iFrame solution we can increase the likelihood of discovery and detection, which in turn changes the risk/reward calculation for the attacker.

First, if the gateway knows a merchant is using an iFrame payment form to submit payment methods, they can turn off other methods of submitting payment methods. This effectively prevents an attacker from using alternate APIs to mimic a legitimate flow in parallel to siphoning off the data. At Spreedly, we provide the following option to our customers:


Since the attacker is now forced to use the same endpoint as the iFrame payment form (due to the restrictions implemented above), the gateway can utilize the Access-Control-Allow-Origin HTTP header to prevent any POSTs to the iFrame endpoint that originates from another origin (this header is checked in a pre-flight request by all browsers before sending a cross-domain POST). This forces all requests to the iFrame endpoint to come from the iFrame itself – not a potentially compromised merchant page.

Finally, now that we’ve prevented the attacker from executing a valid payment method request from the user’s browser, their only remaining option is to send the card data to a server environment of their own control where they can spoof the iFrame request by explicitly setting the required HTTP headers. These requests will succeed, but they are now traceable back to infrastructure controlled by the attacker, increasing their risk. Additionally, these requests will come from a relatively few source IPs making their traffic pattern more easily identifiable assuming proper visibility and alerting from the gateway.

While there is is always a way for a compromised merchant page to expose card data, using an iFrame is the only way to reliably detect the intrusion and shift the burden of security to the gateway.


When it comes to PCI DSS, one principle is clear. Access to sensitive data increases your responsibility for security. Any non-iFrame payment forms allow access to the sensitive data and therefore disqualify merchants from using the SAQ-A. Be very diligent when using tools from your payment provider, and insist and verify that your payment forms are iFrame-based.

Is your payment gateway good enough?


By: Shoresh, Kwasi & Justin

If your company or business accepts online or mobile payments from customers, you are probably familiar with Payment Gateways (PG’s) (sometimes referred to as Payment Service Providers outside the US). PG’s play a vital role in payment processing: they can store and protect your customer’s’ payment information, usually work with several (but a limited number of) currencies, submit transaction information to payment processors, and report the status of the transaction, e.g. success or failure, to merchants, to name a few.

Considering the significance of a reliable payment solution and the critical role of PG’s in this process, it is important to do research before choosing your gateway partner. In fact, picking the right payment gateway (or gateways) is a crucial step in building a payment infrastructure that can meet your business needs. Otherwise, and in the absence of modern tools like Spreedly, moving from one to gateway to another is a challenging and time-consuming task.

Merchants seek an optimal combination of performance, efficiency, reliability, and cost. However, too often we see merchants solely focused on credit card processing fees and nothing else. Other areas, like success and decline rates, uptime, and currency support can have just as big an impact on your bottom line. Often only once in production do merchants begin to realize the significance these other factors can have on their business.

The payment business is highly competitive. We at Spreedly want to help unearth value based on data we provide. In the absence of a “Good Housekeeping Seal of Approval” in the marketplace, the next best thing is a data rich set of tools and information available when you’re shopping for a payment gateway.

The Payment Gateway Index, Spreedly’s early attempt to provide insights for merchants when choosing a gateway to meet their needs, launched in late 2013. Despite its discontinuation in May 2015, we still witness a considerable amount of visits per day to the Gateway Index, which emphasizes the market need to for a reliable source that is backed by data for gateway comparison. Moving forward, we are determined to use the power of market insight and data analytics to provide actionable insight and more coherent efforts to address a variety of challenges in the payment industry, including credit card decline rates.

In this post, we provide data for two important factors when it comes to picking the right gateway(s): the most popular gateways in top currencies in Spreedly’s vault and the average success and failure rates for top gateways. Two caveats: we do not include fees associated with selecting a gateway and we limit our analysis to 2015 data and only consider gateways that have transacted more than 100,000 payment transactions on Spreedly.


Most popular gateways by currencies

Merchants offer their services to customers around the world and need to accept payments in variety of currencies. What are the most popular gateways for each currency? To keep the list short, we only focus on identifying the most popular gateways for the top 5 currencies in our vault, namely, United States Dollar (USD), Great Britain Pound (GBP), European Union Euro (EUR), Australian (AUD) and Canadian (CAD) Dollars. (Please contact us if you’re interested in other currencies.)

Table 1: Top 3 gateways for most popular currencies in Spreedly’s vault


From Table 1 we see that

1. No single gateway tops the list in more than one currency.
2. PayPal is listed in every column except EUR. It competes with Stripe in GBP, AUD and CAD.
3. Merchants using EUR tend to use European-based gateways RedSys, Ogone and WireCard.
4. Top 3 gateways for AUD and CAD are the same but in different order.


Success and failure rates

A declined transaction can occur due to a variety of reasons that were extensively discussed in our previous article about credit card decline rates. Here we discuss the average success and decline rates for the top 21 gateways on Spreedly, presented in Table 2. There is a surprisingly large variation between gateways, and our goal here in sharing the averages is to at least give you a starting point to compare to your own declines rates. Spreedly customers can always contact us for data more specific to their transactions. If your gateways score well below Table 2, you might want to consider other payment alternatives.

Table 2: average transaction type success and decline rates for top 21 gateways on Spreedly



Choosing the right gateway that meets your unique business needs requires not only paying attention to the gateway’s fees, but also investigating other important parameters like currency support, success and decline rates and even the response time of the gateway. Comparing your gateway’s numbers with those provided above is an excellent starting point. In the future, we will provide a more in-depth analysis of gateway performance.

Credit Card Decline Rate, Part 2: Payment Processing Failures vs. Currencies


Shoresh Shafei, Justin Benson

With more than 100 million transactions processed across 100 gateways in 100+ currencies, Spreedly has access to a wealth of information about payment methods (credit cards, ApplePay, PayPal, etc.), transactions and gateways performance. Using this unique dataset, Spreedly is committed to using the power of data analytics to generate insights for all participants in the payment world.

In our first blog post [Spreedly blog, LinkedIn, Medium], we provided a general overview of the effect of expiration dates on credit card decline rates and reported our observation of longer expiration dates for American Express and Discover cards compared to VISA and MasterCard in the Spreedly vault. We suggested that the longer expiration dates might encourage subscription-based companies to facilitate American Express and Discover cards, despite the fact that they have higher transaction fees.

This article is a birds-eye view of transaction declines rates in currencies with the highest decline rates, in comparison with the transaction decline rates for the most popular currencies in our vault. Our most popular currencies are United States Dollar (USD), European Nation Euro (EUR), Great Britain Pound (GBP), Australian Dollar (AUD) and Canadian Dollar (CAD). For these currencies, as well as those with highest decline rates, the decline rate over time and amount, and the average amount of declined transactions, are studied and compared.

In a payment’s journey, when the customer makes a first time purchase, we do Spreedly-side tokenization then submit the transaction information to the payment gateway of the merchant’s choice (Figure 1) which is then sent to a payment processor, credit card company, merchant and customer’s banks, etc. To learn about online payment processing, we recommend two articles, one published in CardHub, and the other by Chase.

There are several things including technical problems that may go wrong after the transaction leaves Spreedly, all of which could result in a decline. On the customer’s side, and according to BankRate, making an international purchase, exceeding the credit limit, expired cards, and even missing credit card payments can stop the payment from going through. The transaction may also get declined in the processing stages due to, for example, fraud prevention. First time purchases from a new merchant, unusually large amounts, international transactions and transactions from high fraud zip codes can all cause a legitimate transactions to be declined. All these errors, reported to Spreedly by gateways, are categorized as payment_processing_failed in our database. The goal of this article is to to study the payment processing failure for different currencies.




Zero’ing in on Currency

One of our popular use cases at Spreedly is merchants going international. There are two approaches: trying to find a single gateway that will take you global, or striking up new relationships in certain regions. Adding new currency support can expand your target customer base. However, international transactions carry new challenges too. We decided to drill in deeper and look at decline rates by currency. For the sake of simplicity, we focus on Purchases in transaction types.

Table 1 shows the percentage of successful and unsuccessful purchases among all currencies in our vault. Since not all the possibilities like pending purchases are considered, it does not add  up to unity. The 25% decline rate in overall purchases in the past couple of years is a significant number. To investigate the possible underlying reasons, let’s breakdown this number for different currencies and transaction amounts.

Table 2 represents the currencies with the highest ratio of failed to total purchases. With 73% of failure in processing purchases, South Africa is the top country list. Columbia, Mexico, Brazil, Peru and Guatemala belong to Central and South America. In Asia, on the other hand, only Indonesian Rupiah (IDR) makes it to the top 10. The presence of European countries like Switzerland, Norway and Denmark sounds surprising and need further analysis. The largest number of transaction failures, however, belongs to Mexican Peso (data not shown).




In fact MXN is the only currency with more than a million failed transactions. Comparing our list with the list of Forbes’s countries with most credit card fraud, Mexico, Brazil, South Africa, and Indonesia appear in both lists. High fraud typically means strong fraud controls, and strong fraud controls can result in a lot of false positives in terms of failures.

On the other hand, with only 6% failure, United Arab Emirates currency (AED) has the lowest failed to total transaction ratio. New Zealand’s Dollar (NZD) is the second after AED with 11% failure rate. (It should be noted that in this analysis, only currencies with more than three thousand transactions are considered, which most of the currencies lie well above.)

The popular currencies in the Spreedly vault, including USD, EUR, GBP, AUD and CAD, Table 3,  do a good job in keeping the decline rates low. Among them, CAD, with only 13% failure rate, does a better job compared to the other competitors. EUR has a 25% failure rate while for GBP it is only 15%. After EUR, USD with 20%, has the highest failure rate.


Payment systems are dynamic systems impacted by internal and external events. Seasonal shopping holidays and very large individual breaches at a large merchant are just two examples that can impact success and decline rates. To see how the decline rates change over time, we plotted the ratio of failed vs. total purchases every three months from June 2012 to July 2016. Figure 2 will help us understand the potential improvements or regressions in payment processing over a four year time period.

For the South African currency, ZAR, as the currency with largest percentage of failed vs. total purchases, the decline rate experiences a substantial reduction from > 90% in late 2013 to around 15% in mid 2016. Therefore, while ZAR owns the overall largest declines, its decline rate has dropped down to the decline rate of the best currencies in our database. Therefore it is safe to say ZAR has become a reliable currency for making purchases. On the other hand, as seen in Figure 2-left, the failure ratio for currencies of Peru (PEN), Mexico (MXN), Norway (NOK) and Switzerland (CHF) are upward, indicating that the ratio of successful purchases is decreasing in these currencies over time. GTQ has a short lifetime in our vault so we cannot make any conclusion about it. Also currencies like DKK or BRL fluctuate and do not have a definitive trend in positive or negative directions.

The decline-over-time for popular currencies has a different story. USD, GBP and CAD experience very little fluctuation over time. While EUR and AUD start with a spike in their failure rates, they both drop down quickly and remain stable. All these currencies fluctuate well below 0.5, as seen in Fig. 2-right. The little fluctuations could be due to the existence of excellent infrastructure for these currencies compared to less popular currencies. Also, Spreedly has a much larger data pool to draw on with these major currencies, meaning no one individual large merchant can impact our overall country experience. That may not always be the case with some of the other countries on our list. Among high failure transactions, Swiss Franc has the most similar behavior. The only difference is it fluctuates around 0.5 which is way higher than what more popular currencies experience.

Does “Basket Size” impact failure rates? 

Are there any meaningful relationships between transaction amounts and failure rates? One may expect that the higher the amount of the transaction, the higher the chance of failure. To investigate this, we plot the ratio of failed over total purchases for amount in the ranges of 0 to 10, 10 to 100, 100 to 1k, 1k to 10k, 10 k to 100k, 100k to 1m and finally from 1m to the maximum values for the top 10 currencies with highest failure rates and 5 popular currencies (Figure 3). k and m denote one thousand and one million, respectively.

For most of the currencies in Fig. 3, the failure rate increases for higher transaction amounts, confirming what we expected. This increase is, however, more evident for the currencies on the right side of Fig. 3, except AUD. This in turn could imply that declines in popular currencies are more likely to be related to fraud activities while in 10 currencies with highest decline rates, it will be due to other reasons including technical problems, gateways failure, lack of enough funds, etc.

Finally, it is interesting to calculate the average amount for failed transactions in different currencies (Table 4 and 5). To get a better idea about the amounts in different currencies, the right column in Table 4 presents the average blues in USD. The amounts are well below 100$ for all the currencies in Table 4 except Danish Krone (DKK). In contrast, we have very large values for USD and EUR in table 5. By performing statistical analysis, and using methods like boxplot, we can show that these large numbers are most likely outliers. However, we keep them here to show the reader an idea about the range of values stored on the database.




In summary,
1. A variety of technical and non-technical reasons can lead to a decline of a transaction, after it is submitted to a gateway payment.
2. Most of the currencies in Spreedly’s vault with high decline rates belong to countries in Central and South America.
4. The time evolution of decline rate diagrams of top-declined currencies are different from popular currencies. The former has more fluctuations and can be related to technical issues while the latter are mostly flat and can be related to fraud preventions. The average amount of declines is another evident for this hypothesis.
5. In general, AED, and among popular currencies in Spreedly’s vault, CAD had the lowest decline rates.
6. In most of the currencies studied, the higher the amount, the more likely the transactions to get declined.

Expanding your prospective customer base by increasing the currencies you support is a great way to drive additional revenue. However as you branch into new markets, your overall experience could be greatly impacted by such factors as which currencies you support and the average ticket size of your sales. Our recommendation is that when evaluating which new markets to enter, add a section around understanding the dynamics of online credit card processing in that region to the more commonly researched factors such as cultural fit, language support and customer support hours etc. If you’re a Spreedly customer, we’re happy to help you with that research. If you’re not, hopefully your payment gateway can share some specific data with you.

Cover photo: Flickr.com

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.



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



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.


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:


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:


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.


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.


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.


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!