A startup involves huge helpings of self belief. An outside investor increases the number of people that have vested “skin in the game” and share that belief. There’s strength in numbers, and we’ll put the funds to use continuing our mission of creating the best system for flexible, scalable, global payments.

Initially, some merchants make the mistake of thinking they should be able to receive their data via something like a .csv file. Due to PCI DSS rules that’s not possible. Yet in reality PCI issues are often used as a smokescreen to justify why you can’t get your data back. Credit card data can be transferred – it just has to be securely transferred from one PCI compliant service to another. Unfortunately, many services providers point to PCI concerns as a reason not to do any type of transfer. For a merchant, the thought of asking all their customers to re-enter their card data typically stops them in their tracks. Thus creating a frustrating lock-in cycle.

From Spreedly’s 2008 inception we supported moving your credit card data to another provider in a secure manner upon request. Braintree was the first payment gateway to champion this. Recurly embraced the concept too and Stripe also supports it. Some services can’t or don’t because they don’t vault cards for you independently – leaving the answer in the hands of whichever payment gateway you selected to work with their service. Still, globally, it’s the exception rather than the rule.

Credit card data portability reminds me of flood or earthquake insurance. People sort of assume they’re covered – if they think about it at all. Many never experience a natural disaster. Those that have suffered feel very strongly about the need for credit card data portability. Given Spreedly’s business we most likely talk with a disproportionate number of these folks.

Let’s also be honest. Even when you do support portability it’s a pretty clunky process. The card data has to be moved between two providers in a secure manner. Data has to be re-mapped. Your service has to be up and running for new transactions before you can shut off the older service (so you don’t orphan whatever signs up happen after the transfer is done) It’s substantially better than not being able to get your data back – but it’s hardly a seamless process. Also, some payment gateways charge fees to do this work so there can be an added cost as well.

Spreedly tackles this by vaulting your cards away from your payment gateway and giving you a payment gateway API to integrate. So you never have to ask for them back – we have them. You can simply change out your back end processor and never skip a beat. This model works really well in a couple of different  scenarios. One, where you find yourself working with a less than optimal payment gateway or – like development shops – working with a different payment gateway on every other project. The other scenario is where it’s a platform/service on top of a payment gateway/s. The platform has just one API to support to reach any or all of our 48 + payment gateway options.

However, what if you want or need to use the payment gateway API (vs Spreedly’s?) Well, one option not in place today is for a payment gateway to use Spreedly as an independent vault for customers who want their cards stored independently. Technically, it would fairly easy for a payment gateway to implement something like this. They could create a Spreedly environment on the fly for each customer that wants this, and vault into Spreedly alongside their own vault.  If the customer wanted to change, they’d just say “create a Spreedly account and we’ll move the environment over to it for you and give you a list of your currently active Spreedly tokens.” From there the customer has an independent vault that they could process against – either via the Spreedly API or by having a new payment processor point to the vault.

Investing development resources with the sole goal of making it easier for customers to leave is a difficult concept for 90% of companies to embrace – so we don’t expect a lot of pull from the payment gateways here. Which comes back to the opening title for this post – is there any real market demand for this from end users? (the push?) There’s nothing quite like Spreedly around so maybe it’s a lack of solutions/awareness. Or maybe it’s just the fact that most people think they have flood insurance as part of their overall insurance policy and so don’t ever think about it too deeply. It might be a financial mismatch. Feel free to drop us a line if you have feedback on this topic.

Choice is good, and I’d love to see a hundred different alternatives to credit cards bloom. But if you’re a merchant, just the thought of that many options probably makes your head hurt, since each one brings with it new implementation challenges – unless, that is, you’re using Spreedly.

We already support Dwolla and GoCardless, not to mention the old faithful PayPal. These can all be great alternatives to credit cards, and both merchants and consumers are seeking them out. While they have big benefits, the downside with each of these is that, unlike with a credit card transaction that can be run in one step right on your own site, you have to send your customer offsite to each of these providers to complete the transaction. And, if you want to do ongoing transactions on behalf of your customers, your transactions are locked in to whichever provider was originally used. You can do multiple transactions against a GoCardless account, but you can’t flip a switch and just start running those recurring transactions against PayPal – it doesn’t work like that.

But what if you could, when it makes sense, transact directly against a consumers bank account? Even better, what if you could do it in a way that, just like credit cards, vaulted the details of that bank account so that you could switch out the backend at any time and just keep transacting away like nothing changed? Well today I’m excited to announce that we’ve added a bank_account payment method to Spreedly, which is a fully functional sibling to credit_card payment methods.

Adding a bank_account is simple – the fields are different than a credit_card, but otherwise it’s just the same transparent redirect (or direct API call) as always. And once you’ve added a bank_account, you can treat it just like a credit_card account – retain it, redact it, and transact with it against any gateway that supports it.

Speaking of gateway support, we’re launching with bank_account support for Authorize.Net’s eCheck.Net service, which means that as soon as you get eCheck.Net enabled on your Authorize.Net account, you can start using bank accounts right away. There’s nothing new to configure on the Spreedly side – just add some bank accounts and go.

While bank accounts do not (yet) have an equivalent to PCI-DSS, Spreedly treats them with the same care we use for credit cards, so you and your customers can rest secure that the sanctity of their bank account is being taken very seriously.

The big question we’d like to have our customers answer: what other gateways would you start using with bank accounts tomorrow if you could? We want to start adding support where it makes sense, and our customers are always the best place for us to learn what’s going to be the most useful. And don’t feel like you’re limited to traditional credit card processors that happen to have an ACH or echeck add-on; we’re also open to reviewing services that only do ACH to see if they’d be a fit for adding to Spreedly.

Thanks, and as always, we can’t wait to hear your feedback on this new bank account support!

The problem is there is no Feefighters for failure and success rates by payment gateway. The other problem is, even if you realize that the grass is greener on the other side you often have to do a LOT of work to get there. If failed transactions are a concern then we might be able to help.

First things first. We don’t have a large enough pool of transactional data to start making concrete assertions. That would be reckless at this stage. We do have good data to share and are growing so we plan to constantly improve our data. In the future, we will be able to collect inputs like your selling price points, geographical locations of customers, one time vs recurring mix and then output a meaningful gateway  (and/or merchant account) recommendations that might decrease your decline rates from 1 – 5% of your overall transaction volume. This is our first step on that path and hopefully still useful.

Here are our April statistics. If you’ve seen our gateway list you’ll know this data includes payment gateways like PayPal Website Payments Pro, Braintree, Stripe, SagePay, Authorize.Net, and Wirecard. We selected these ones based on a combination of strong marketplace interest/and or good transactional volume. We drop some smaller ones (for us) given it might skew the overall data. Firstly, here’s the blended rate broken out between our one time offering and our recurring offering:

You can expect a higher success rate with one time transactions vs renewals for a number of reasons. Firstly, the card is unlikely to be out of date. Secondly, the customer is more likely to ensure they have adequate funds for the transaction in an immediate purchase. Thirdly, recurring transactions don’t have a CVV (no one is allowed to store those for PCI reasons) That should not be an issue but it seems clear that some banks and gateways just don’t like that fact as much.

Let’s break recurring out though by gateway. Here’s where it gets more interesting. I’ll just pick 5 common gateways:

So you can see they all trade within a narrow range. But within that range there’s a big difference. Customer on gateway A is seeing nearly 5 extra failures out of every 100 renewals than customer on Gateway E.

Let’s look at one time transactions across 5 gateways:

Success and Failures on one time transactions tend to trade in a much broader range. Here it seems the predicability of a recurring transaction actually helps. Maybe the card doesn’t have a CVV, or maybe your customer forgot to have enough funds to cover the transaction. However, on these one time transactions the gateways/merchant accounts are applying much stricter fraud filters (after all, you’re probably not going to be doing a bogus transaction on a monthly basis with a stolen card) Then the question becomes – are some doing a much better job than others? Or are some just accepting more fraud? Or is it the quality (or not) of merchant let in in the first place?

For Spreedly customers: We’re happy to drill into an individual situation if you feel it would be helpful. We discovered a customer who’s failure rates nearly doubled immediately after they were targeted for fraudulent transactions. We’ll also continue to build out the robustness of this data as we expand and have more data (but in the short term and over time) to compare performance.

If you have any other comments or areas of interest you can leave a comment on HN and we’ll reply:

Failed transactions are a serious issue. They result in lost sales and/or customer support contact, and that means they cost real money. Merchants are often very geared toward squeezing 100 basis points out of their CC processing rates. Yet changing gateways to shave off 100 basis points only to see a 3% increase in failed transactions doesn’t make economic sense.

The problem is data. Merchants don’t have absolute data and they don’t have relative data. You know (hopefully) what your decline rate is, but how does that compare to other merchants at your gateway? And how does that compare to a similar merchant at another gateway? Too often the answer for high declines from a payment gateway can be cryptic at best for a frustrated merchant. The payment gateways can be opaque due to the fact that many failed transactions relate to fraud/security filters, and they’re afraid of giving away too much if they describe how they reach some of their declines, However, they can also be opaque because they just don’t know, at least at the support/account management level.

Spreedly is a credit card vault in the cloud that works with nearly 50 different payment gateways globally. This gives us unique insight into performance within and across different gateways. It requires scale to be effective. We’re starting to hit scale, at least with the largest gateways, where we can help. One of the most powerful things we can provide is context. We can work with you to better equip you when discussing these issues with a payment gateway. In addition, if after all your efforts your gateway isn’t responsive then you’re free to change without fear of data or API lock in.

We were recently approached by a customer who was frustrated. They felt “in their gut” that their failed transaction rates were increasing. They weren’t getting helpful answers from their payment gateway. They were growing which made it hard to tell if it was linear or accelerated decline rates. So we took a look at their data. Here’s what we saw from a quick first pass.

We started with Q1 of 2011 and did a quick YoY comparison.

So the trend was definitely moving in the wrong direction. Next we looked at the most recent quarters in general (based on customer feedback) That was a lot more revealing:

We learned two things. There was a big dramatic jump between Q2 and Q3. Yet it also trended down a little in Q4 and into Q1.

Next we dug in on Q3 first and broke it down by month.

It’s no surprise the customer was super frustrated. We were also getting closer to finding the key date. We dug into August and saw that the mid point of August was the real culprit:

Now, our customer could have captured this data on their own. Where we add value is in the context.  We looked at all other customers working with that payment gateway across that same time frame:

Our conclusions were:

1. There’s nothing breaking/new between Spreedly and this payment gateway as other customers are not impacted (always important to rule out)
2. The customer knows that they’re now well outside of the norm for that gateway.
3. The timeframe for the significant change is very well defined. The customer needs to understand if there’s anything they’ve done to impact change (change price points, plan lengths, run any crazy specials)
4. The gateway needs to understand if they did anything differently in that timeframe to also impact that customer.

We could continue to drill down and compare end points, average transaction size, net new vs recurring etc. Due to customer privacy concerns we can’t share where we went from here for a resolution.

Our takeaway was we need to be more proactive (after all our customer approached us). We can effectively monitor our payment gateway partners like packets on a network for our customers. We can catch issues before they become long running. We can work with our customers and their payment gateways to do whatever is necessary to drive out “false positives”.

If you’re having challenges we’d like to work with you. For a direct site you’d integrate to our API vs the gateway. If you’re using your gateway via a third party SaaS offering (Freshbooks, Xero etc) they can add Spreedly as another gateway in their arsenal and we can begin capturing your data flow. Or just email us with comments and questions.

Eventually we’d like to get confident enough in our data to publish monthly performance metrics by gateways we work with, much like Netflix does for broadband providers. The more data we have the better we’ll be able to see where the real issues lie.

Up until now there were two broad choices when it came to vaulting your credit cards. Vault with your current payment gateway. If that didn’t work, you could go out and try and become PCI Compliant and vault your own cards. The mixture of costs around hardware, software and maintaining outside compliance – coupled with the time it took to achieve this goal – meant most people went with just vaulting their cards at the gateway.

Unfortunately that became a tool for lock in with your payment gateway and/or SCM partner. Quite simply, they would not return your customer credit card data if you wanted to switch to a new provider. Companies like Braintree, Spreedly and Stripe helped change that by agreeing to return your cards upon request. Yet it’s by no means a broad industry trend (yet).

We’ve set out to fix this problem by creating an independent vault that you can procure as a pay as you go service. Unlike prior efforts in this space, we connected it with more than 45 + payment gateways so you can process straight from the vault against one or more of these gateways simultaneously or over time.

The payments landscape is dynamic. There are new options springing up regionally with global aspirations. Mergers and acquisitions seem inevitable as the likes of Stripe, PayMill, Braintree and Pin Payments crash into the the established market participants. Acquisition might be the most cost effective way to reach new geographies or technologies and processes. All this presents a lot of opportunity for today’s online merchants to see rapid improvement in the level of payment services offered.

One area we think still needs improvement are SaaS and cloud services that let you bring a merchant account to their offering. Ecommerce, subscription, billing, accounting, health and fitness offerings all typically require/let a customer use their own preferred gateway/merchant account. Today their approach is really hit or miss. Many support multiple payment gateway options – but they’ve done a simple integration that involves passing your credit cards through to that payment gateway vault. That means you’re locked in to that payment gateway again.

Let’s say they add support for a new payment gateway choice. Imagine your disappointment to learn that even though you’re a paying customer on their service you can’t take advantage of that because they weren’t vaulting your cards for you. You’re stuck with a payment gateway with mediocre support and response times while net new customers coming onboard get the latest and greatest.

With Spreedly we’ve changed that dynamic. We hope more and more of these services work with us, or build their own vaults, so that you can stay nimble through all of the change in the payments space over the next decade.

Until recently, online payments in Australia were broken. Local systems seriously lagged what was available in North America and Europe. This meant that companies based here were at a disadvantage compared to their peers in other parts of the world. Not cool. I want to tell you about how Spreedly helped us to fix things so that Australian companies could compete online with anyone.

Startups need help. We’re a small new company, and our resources are limited. The only way for us to deliver a world-class contemporary payments stack was with help from specialists. We realised early on that we didn’t want to build our own credit card vault, because we needed to work on delivering features to customers instead. Spreedly helped us to attain a purpose-built secure storage environment, and to get our service to market fast.

Spreedly weren’t our only option for secure card storage. Some banks provide this, as do several fancy-pants enterprise vendors who are not at all startup-friendly. As we researched the space, Spreedly became the obvious choice for us, because:

1. Many of the alternatives were, frankly, too “enterprise” for us. They offered hardware, licensing that doesn’t fit startups, and plenty of handshakes, but not so much of the secure storage we needed. If you’re in the market for something expensive that fits in a 19″ rack for 5 years without actually connecting to your business, then you will find no shortage of options. This didn’t work for us.
2. Spreedly are up-front about their adaptability. We’re connecting to different systems as we grow, and it’s important that we can expand to new markets or re-architect systems as-needed, without having to fight for our data each time. Using Spreedly helps us reduce any operational risk of lock-in with a particular provider or architecture.
3. The technical fit is not really critical, but it’s a great bonus. We’ve been aware of Nathaniel’s (Spreedly’s founder/CTO) work with ruby for years, for example. Occasionally we’ll collaborate on a change to our product, and when we do it’s helpful to know we’re speaking the same language.

Thanks to Spreedly for helping us to fix payments in Australia. Justin and the team have been one solid piece of a pretty exciting puzzle (BTW Spreedly don’t pay us to write this stuff, we’re just happy customers.)

We believe programmable payments will become a standard requirement for businesses as e-commerce matures throughout Asia, and we’re pleased to have Spreedly helping to connect Pin Payments to the action.

Spreedly Metrics available today:

• Revenue ($)
• Refunds ($)
• Transactions (#)
• Trials (#)
• New Subscribers (#)
• Active Subscribers (#)
• Cancellations (#)
• Churn Rate (%)

In the next couple of months we’ll be adding the following:

• Support for Spreedly Core
• Lifetime Value (LTV) of Customer metric
• Benchmark values for churn rate and LTV for all companies using Spreedly
• Revenue and active subscribers per Spreedly plan

Because analytics tools are all a little different, let me quickly introduce you to a few of the features in DigMyData:

Metrics page

Quickly view metrics

Reports page

Combine metrics into report for comparison

Comments

Note special events like promotions or policy changes

Compare

How did you do compared to last week? month? year?

Forecast

Details

Custom Metrics

Combine metrics with +, -, x, and ÷

Fullscreen mode

Sharing Reports

Users

Share read-only access to DigMyData

Multiple companies

Spreedly signup at DigMyData

Email us at support@digmydata.com with any questions or if you just want to say hi!

Beyond Spreedly we also have integrated with the following:

Thanks everyone!

Any discussions or comments may be here

As we mentioned in a prior post, DigMyData is a separate third party service from Spreedly. We have reached a financial arrangement with DigMyData to provide this service to our subscription customers free of charge. There’s a possibility that at any point in the future we may no longer pay these fees to DigMyData. At that point you’d lose access to DigMyData – unless you enter into a agreement to procure their services directly from DigMyData at that time.

Ok. To get started simply go to this Spreedly specific page on DigMyData.
https://app.digmydata.com/spreedly-signup/

You’ll need your Spreedly short site name and API key. You can get those by logging into Spreedly going to your Dashboard ==> Configuration ==> Site Details.

DigMyData supports other data sources as well so check them out if you’re interested in getting better reporting from say PayPal or Authorize.Net.

Just a final note. This is just for customers using our Spreedly Subscriptions service. We are working with DigMyData for support for Spreedly in general. However, we haven’t had any discussions on whether we’d do something special to offer that reporting to our customers.

Enjoy the reporting. It would be great to hear what you think once you’ve had a chance to work with it.

Having said that, our lack of reporting within subscriptions has always been a pet peeve of mine. I’m happy to announce that we’ve now gone a long way toward solving that issue. And we’ve done so via “buy” vs “build”. Spreedly is partnering with DigMyData to provide reporting services to all Spreedly subscription customers.

DigMyData is a third party data analytics tool. They support a lot of data sources, including PayPal, Authorize.net, Google Analytics and Stripe. All of our subscriptions customers now have an account for their data. If you like using it with Spreedly, some of you may chose to pay a fee to upgrade to include other data sources that DigMyData supports.

Let’s get all “legal’ish” for a moment

Spreedly is paying DigMyData for our users to access their Spreedly subscriptions module. There is no cost to you our customer to access this service. Both sides worked hard on this agreement and don’t intend to end it anytime soon. However, there is a chance that at any time we may no longer pay DigMyData to provide this service to our customers. At that point, you’ll have the choice of paying DigMyData directly or no longer having access to the service.

Secondly, DigMyData is completely independent from Spreedly. That’s one reason why we are not doing a fully integrated single sign on/dashboard process. We want you to realize it’s a third party service and that you’ll be sharing your Spreedly data with them to utilize your reporting. You’ll sign up via a DigMyData page that’s specific to Spreedly customers.

Ok, now that’s out of the way…..

As Peldi from Balsamiq Studios says “DigMyData is an analytics dashboard for those who don’t have time for analytics.” DigMyData will help you with a graphical history around revenue, customer additions, cancellations, churn rates and more. You can compare time periods, and you can export data as a .csv file. Let me share some of our own data with you.

In October 2011 we raised our Spreedly prices substantially. Naturally this upset many customers and opened us up to some major criticism (Read: “Something must have been going severely wrong at Spreedly HQ”) Let’s use DigMyData to look at what happened to us with October 2011 being the starting point. First, customer churn:

As you can see, in both October and November our churn rate skyrocketed. (In February it went up too but that’s actually people migrating from our monthly to our new annual plan launched that month) Over time it settled back down.

Let’s look at what it meant for revenue.

Again, February was when we rolled out a new annual plan. Existing startups could opt out of the monthly and into the annual plan so we saw a spike in revenue there. (Annual vs Monthly plans are a post all in themselves.

So that’s some of the ways we’re using DigMyData on our own data. If you want immediate access to DigMyData email us at support@spreedly.com and we’ll send you the instructions to get set up. For everyone else we’ll email out the instructions to get you going over the next couple of weeks.

From the team here we hope you enjoy using DigMyData as much as we do!