Here’s an article covering our latest activity including our recent raise.
Spreedly began life as a digital subscription service before selling the service to Pin Payments. That allowed us to focus full time on the “new” Spreedly; helping companies that have to work with more than one payment gateway obtain all the benefits that someone working with a modern payment gateway’s receives.
One of the unexpected outcomes of selling the subscription business and focusing in our new offering was we changed camps overnight. When I recently ran into the CEO of one of the better known subscription services at Money2020 he said “What gives? I thought you exited the subscription business yet we still occasionally hear someone is comparing us to Spreedly.” I had to explain that while people may still compare our two companies it’s now with a completely different view in terms of Spreedly. We’ve gone from offering a digital subscription service (out of the box) to a simple, powerful credit card vault and set of API’s. From buy to build if you will. To make matters more confusing we have subscription services like ChargeBee and Fusebill who have integrated/layered on top of Spreedly to offer a large range of payment gateways.
So based on i) previously running a digital subscription service, ii) having digital subscription services run on Spreedly today and iii) having “roll your own” recurring services on Spreedly here’s the advice I give when asked ”what’s better, build vs buy?”
The first important question is do you need recurring functionality or subscription management? Recurring charges are simple repeat charges. For example, on the 28th of each month your rent is due for $500. Or your utility bill is due for variable X amount. Your total number of services (or sku’s/plans if you will) is never greater than 1. The date is fixed. At most the amount might vary month to month but it too is often fixed.
Subscription’s are more complicated than recurring. Customer’s might subscribe to more than one plan that you offer. They may downgrade and upgrade frequently and thus need prorating. You may have one time sales along with subscriptions. Some plans might be a fixed monthly fee and then you add “overage” fees based on usage data. Some plans might be all based on usage and thus are “metered” plans. How do you handle failed renewals and access to your service? What about discounts and coupons? Do you have affiliates that sell your plans? The list goes on.
Generally I see services fall into 3 camps where category two is by far the largest group:
- Simple recurring only needs with no real possibility of getting more complex
- Relatively simple subscription plans today with the probability of more complexity over time
- A high degree of complexity today and going forward. How you get paid is deeply tied into how your service is offered.
Category 1: Go with a payment gateway only. (assuming you have access to a good modern one).
Category 3: Also go with a payment gateway only.
Category 2: Start out with a subscription based service while maintaining the ability to bring it in house with the least amount of effort.
The reasoning behind category one should be self explanatory. There is an extra cost and management layer when using a third party subscription billing service. That’s tough to justify if your needs are super simple.
For category 3, our experience is you’ll spend as much time trying to modify a third party service to fit your needs as you will building your own. If you have a high degree of complexity you’re probably going to need to create in-house expertise so the value of a third party is diminished.
Now for category 2. If your needs are relatively modest today but could/will become more complicated over time then start with a third party service and leave your options open to bring it in house in the future.
Why do it this way?
- Time to market. Don’t spend effort building out basic subscription functionality when you can quickly and easily get it from a service like ChargeBee, Chargify, Recurly, Pin Payments etc.
- There’s a chance that the service you select will continue to make enhancements that match your more sophisticated requirements as you grow. Naturally if you can avoid the headache of bringing the project in-house that’s nearly always the best outcome.
- When you are ready to build your own you’re likely to build a much better solution based on your time spent using a third party service. Not because you’re “stealing” ideas from them (although maybe you do that too!) but because you know what elements are really unique to your business and focus in on solving those.
Some of you in category 2 are probably wondering why not just go with a payment gateway with solid recurring/subscription API’s rather than a third party service. If you have access to something like Stripe or Braintree you may want to rely on their subscription functionality. The only real downside is that they aren’t dedicated subscription services so there’s only so far they’ll go to support a subsection of their customer base. To put it another way, you have a greatly diminished chance of having the benefit of the second bullet point above.
Here are some key questions to maximize the ease of bringing it in-house if/when you need to. How easy is it to leave your subscription service? Do they return credit card data for you? Are they storing it independently of the payment gateway or passing it into the payment gateway to be stored there? PayPal’s acquisition of Braintree and Google Checkout closing down are just two recent examples of why payment gateway independence is worth considering. Will either the subscription service or the payment gateway help you migrate your credit card data to a new provider? Ask them to spell out that process and cost. Do they support third party reporting tools? If you can continue to have your reporting reside in one location post moving it in-house it’ll dramatically reduce the impact of the change.
In addition, assume you’ll likely want to change payment gateway’s if you are bringing it in-house. There’s a couple of reasons for that. Firstly, if you’re using a third party subscription service initially it reduces the importance of a payment gateway with great API’s and documentation (because you’re not coding against it) That won’t be the case if you bring it in-house. Secondly, if you’re brining it in-house you’re probably now doing some really nice volumes. This opens up a range of more sophisticated merchant account options (rates/currency support/fraud/foreign exchange rates etc) than are typically offered to smaller startups.
P.S Note that I’m not focused here on the “enterprise” third party services like Zuora/Aria etc. By all accounts they are at substantially different price points and expect a fair degree of professional services/customization to get you launched.
The news broke today that PayPal is acquiring Braintree Payments.
We’ve seen more traffic to Spreedly by 9am Eastern than all of yesterday.
If you’re a Braintree customer and you’re concerned about how this might play out over the next few months we want to make a specific offer. We have our standard $50 (Freedom Plan) that let’s you store up to 5000 cards and pay 4 cents a transaction. What we’re also going to do is have our next plan, the Traction Plan, have the same parameters as our Scaling plan. To put it simply, if you’re a Braintree customer, you can store up to 100,000 cards for $150 per month. We’ll also then charge you 2 cents per successful credit card transaction.
With Braintree we can “dual vault” too so you can keep your cards at Spreedly and at Braintree. The idea being that if you feel comfortable in 6 – 12 months with Braintree you could drop Spreedly and just process directly against Braintree again. If you’re not comfortable you have an independent vault that you can take somewhere else – or just keep using Spreedly against one of the other 50+ gateways we support.
We would need to move your vault from Braintree to Spreedly initially. And you would need to integrate to our API. So there is some work to do.
Email support or sales at Spreedly if you have any specific questions, larger volumes or to sign up.
Back in April we wrote about declined transactions. Many declined transactions are easily understood; insufficient funds in an account, inaccurate input of the data. Many however, are not. They involve fraud filters and payment gateway idiosyncrasies. Local transactions vs international transactions. “False positives”, as we sometimes refer to them, can cost a sale and/or result in a costly support call.
In this particular case it was a customer who had suffered from card testers (fraud) for a 48 hour period. Almost immediately they saw overall decline rates skyrocket – and stay that way for months. Someone somewhere turned on additional fraud filtering on this customer’s account. They never told them and never turned it off. They ended up changing payment gateways; something that we make easy to do. However, they suffered for months prior to that switch. That didn’t seem right or fair.
We realized there was a mountain of data to compare the price of payment gateways. However there was nothing to compare their performance. We wanted to do what we could to help payment gateways and our customers. However, as a startup, we needed more data than what we alone were seeing. On a trip to see Shopify over the summer they too were intrigued by this question of payment gateway performance. Shopify agreed to share pool their firehose of data and we were off to the races.
So here is our Payment Gateway index. We hope you find it useful. We know you’ll have feedback and we do intend to improve it as time goes on.
Spreedly is a payments platform for (primarily) online commerce. We’re a set of API’s around a credit card vault and/or working with multiple payment gateways. One thing we don’t do is act as a merchant account or payment gateway directly. This leads to a lot of head scratching from some people. Why Spreedly?
Maybe a good place to start is “Why anyone?” when it comes to payments. What are the basic building blocks for any online/mobile payment application?
- No credit card data touching your side of the equation. You want your payment provider to capture that before it touches your environment to minimize PCI scope
- A way to store credit card data for additional/repeat/recurring charges
- An API and documentation that your developers will enjoy vs curse
- Complete control in terms of end to end design flow or experience.
Things like fees, currency support, local payment types, disbursements and recurring might be important but they vary in significance from person to person. The above 4 are the fundamental building blocks.
Good news. Every day there’s a new payment solution entering the space that addresses the above requirements. Or an existing payment provider enters your market and brings you choice. (A payments developer in Australia noted via Twitter that after years of a fairly static environment they’ve added Stripe, Braintree and Pin Payments in just 12 months!)
So why Spreedly? Well, there might be several reasons why you can’t work with a single, modern payment gateway. Once that happens you’re really either forgoing your own credit card vault or investing in building one – not cheap, fast or easy. Spreedly provides the basic building blocks listed above and then lets you process and have the merchant account of your choice/requirement.
One way to explain why Spreedly is to look at our customers/prospects by vertical and how they’re using Spreedly. We recently launched a customer case study page. Below are some more text based examples:
- Financial/Payments vertical: We have payment gateways and payment methods deployed or developing on Spreedly. They use our vault and our gateway connectivity and build a range of value added services on top that solve a geographical or vertical challenge. Here we really are infrastructure for payment services.
- Transportation: We have black car, taxi and bus focused services deployed or developing on Spreedly. These are sometimes direct services or sometimes aggregation services. By aggregation services I mean someone who provides a service that lets you book from a range of choices underneath. It could be a mobile app that allows you to get a taxi fare from 3 or 4 competing taxi services in your area then book right there. The app can charge your card on file against the payment gateway choice of that taxi service. Quick, clean and simple!
- Food and Beverage: Let’s say you build a better mobile app for ordering from a restaurant. Every restaurant is going to already accept cards. Or maybe you’re out to convince sporting stadiums to use your mobile app so people can order from their phone in their seat vs stand in a 27 minute long line. A single integration to Spreedly helps you support existing legacy choices in the marketplace.
- Ticketing/Reservations: There are a lot of 3rd party services that aggregate buyers and connect them with sellers. It’s much easier to not be in the money flow in these situations (disbursements, chargebacks/disputes). So if you’re building the ultimate vacation rental website or college ticket website Spreedly might be the way to go.
- Fitness/Wellbeing: Maybe you just created the world’s best online member management platform to tap into the exploding CrossFit market. That’s great! Spreedly helps reduce the friction in your sales cycle by not having to also convince them to use your specific payment provider.
- SaaS/Recurring services/Ecommerce: Third party full blown recurring services can use our vault and payment gateway infrastructure. We also have individual subscription sites – usually with pretty custom specific needs – utilize our vault and payment gateway/s. Newer ecommerce platforms can support the choices of their customers for their preferred payment provider.
- Single Payment Gateway: There might be financial, geographical or legacy reasons for why you don’t get to work with a more modern gateway. Spreedly gives you much of the goodness of a modern payment gateway while still letting you transact against a legacy choice (often with incredibly low processing rates)
Very early on in any sales conversation we’re always asking ourselves: “Could these guys just go with a single payment gateway to solve this problem?” If the answer is yes we save everyone’s time and send them in the right direction. If you’re in a situation where going with a single modern gateway just isn’t feasible then you’ll immediately understand what we do.
Lastly, about 2.5 years ago I read “What’s Mine is Yours” by Rachel Botsman – a significant person in the world of collaborative consumption. It completely changed my outlook on how I viewed goods and services. Therefore, one of the things I really enjoy is when we help companies that are helping change the world via a sharing economy. We want more of you! :)
You don’t fit into the single, elegant, payment gateway box. That’s why Spreedly.
Marketplaces are all the rage, fueled in part by a boom in collaborative consumption business models. Interest in them has only accelerated since we wrote a post around marketplaces and payments back in November 2012.
For a multitude of reasons the default payment assumption when approaching a marketplace is “I need to collect money from the buyers on my site, keep some sort of fee for myself, and then disburse or payout the rest to the seller.” Sounds easy but turns out to be very hard. Collecting and disbursing money gives you a lot of control as a marketplace. However, it also opens up a whole range of regulatory issues from whether you’re a money transmitter to how you mange things such as fraud and chargebacks. Balanced embraced the challenge to help marketplaces strive. Stripe recently added disbursement capabilities and discussed processing $500,000 per day. Still, many markets outside the U.S remain underserved or try to get by with PayPal’s adaptive payments API.
We saw a competing trend and wrote about that last year. It is becoming significantly easier for anyone to get a merchant account and thus accept cards. What Square was doing for the POS world Stripe was doing for online sales. Braintree played catch up and now supports instant onboarding in some markets. New providers like Pin Payments in Australia and PayMill in the EU showed up. It struck us as the better model for many marketplaces to allow/make your sellers get their own merchant account to collect funds for the sale of their services or goods. Using Spreedly, marketplaces can see all of the transactions moving across their platform. If a transaction takes place, look at the amount, calculate your % and then you directly charge the card on file for that particular seller. We’ve seen vacation rental marketplaces be the first early adopters of this model but it’s happening with others as well.
The news recently by TaskRabbit and Braintree reinforces the validity of this model. TaskRabbit allows buyers to purchase services from sellers within the TaskRabbit marketplace. Those “services” are a range of things from walking a dog to buying roses and hand delivering them to your sweetheart at the office. In the old model TaskRabbit had to collect money for the service, hold those funds, take a cut, then pay the TaskRabbit out upon completion. The relationship with Braintree now means in effect each individual TaskRabbit has a (sub) merchant account to accept cards. I’m not sure of all the nuances of the $$ flow and commissions etc – but it is a seismic shift. In this case TaskRabbit has enough control that it can dictate to the TaskRabbitter that they work with Braintree so a single relationship makes sense. If you’re a vacation rental site working globally though you’re going to to have to work with a lot of options – especially if you want to work with rental properties who already have a processor relationship. Either way though the important point is you’ve removed yourself as the middleman for holding the funds.
There will always be a segment of the market that wants to hold and disburse funds. What’s different now is the availability of a new model. It’s a model that we think will become the more predominant one as the ability to accept payments becomes easier. We expect more and more sites to follow.
Over the years, we’ve spent quite a bit of time creating HTTP API’s for our services, allowing programmers from all over the globe to vault credit cards and charge against them in their programming language of choice.
Ruby is one of the languages we’re quite fond of at Spreedly. This is one of the reasons we’re thrilled to now have a shiny new gem for Ruby coders to benefit from. If you’re writing Ruby code, our hope is that the gem will make your experience with Spreedly even better.
There are many approaches one might take in designing a library to interact with an API. You’ll notice in the philosophy section of the README that we didn’t want to be too clever. We wanted the gem to be a thin and simple layer over the API. We wanted it to help with the ssl communication, the urls it’s talking to, the parsing of responses, and the handling of error conditions. It’s essentially a ruby’ish way to interact with your Spreedly environment.
We hope you like it!
Hi, I’m Adam! I’m relatively new at Spreedly, and I’m excited to announce some progress on the first ongoing project assigned to me.
Now that we are focusing more and more on providing a platform for all sorts of payment solutions, we need to provide more ways of connecting your systems to our API. We want to both enhance end-user experiences and provide options and conveniences to developers who integrate with Spreedly.
Three calls are open right now using CORS requests (Cross Origin Resource Sharing):
Many of our customers are drawn in by the ability to offer multiple payment gateway choices as they onboard their own customers. This will allow your customers to create a gateway in your Spreedly environments. The gateway will be in a cached state – similar to how payment methods are – until your server retains the gateway.
Allows for adding a payment method without leaving the page as a transparent redirect would do. This accomplishes the same PCI goals, since the payment information never passes through your servers. If you’ve utilized modern payment gateways like Stripe, Braintree, PayMill etc. to implement payments, then this approach should feel very familiar to you.
We have documented these changes so you can get started right away. If you’re working with multiple gateways in Spreedly and are interested in trying out the first iteration of our JS library, please do get in touch.
It’s been a busy 100 + days at Spreedly. Around March 1st we switched from emphasizing our subscriptions offering to focusing on Spreedly (Core). In May we successfully raised a seed round via AngelList. In July we announced the sale of our subscriptions business to Pin Payments.
There’s one recurring theme at Spreedly we find fascinating. Putting aside people that perhaps don’t understand payments at all, we have two types of prospective customer interactions.
Prospective Customer A: I understand what you do but I don’t understand why anyone would use you. Why wouldn’t they/I just go with <insert> payment gateway? They also vault cards and can accept multiple currencies etc.
Prospective Customer B: This is fantastic/awesome/wonderful! Where have you guys been hiding?
Naturally we saw enough of the B type to go all in on our new offering. However, we grapple with what we do with Prospective Customer A. What’s most interesting is there hasn’t been any real shades of gray. Even when Prospect A understands how we are different they rarely become a customer. At best we can hope for is somewhere down the road they refer someone to us when they hear the problem that we solve. Conversely, with prospect B we don’t do a lot of “traditional” selling. It’s not “Can you tell me in 3 – 5 ways why you’re different to these 5 competing services?” It’s straight to implementation and pricing questions. It’s fast track or no track.
We’re partly to blame for this conundrum. Every time we thought we’d seen all possible use cases new ones would arise. So we backed off diving in hard on defining exactly what we were. We *still* happily get emails from really smart people who outline their problem and how we can solve it and we all look at each other and say “Yes, I think he/she is right. It could work that way”. That’s really enjoyable. However, we’re also getting close to understanding how we can describe ourselves in a useful but not limiting way. Again, some of it comes from prospective customers. “You remind me of IP Commerce in their early days” or “You’re like PAY.ON only you’re focused on merchants and services as customers not payment gateways as they are”
So what are the types of use cases we see? Need to vault cards on behalf of a third party? Need to vault cards and run them against more than one payment gateway? Sell a service to third parties that may already have a payment gateway and want you to support their existing choice? Operate globally but want/need to transact on the ground/locally? Want to build your own payment gateway? We can be the answer there too.
A few things became consistent. We’re nearly always a critical infrastructure component. We’re not interested in being an end user brand. We’re a B2B offering (usually but not always our customers are B2C). So we arrived at Payments as a Platform.
I think our true prospective customer will always immediately get what we do. By emphasizing that we’re a foundational platform upon which one or multiple payment gateways sit to work with your service we can help other folks self qualify.
Today we’re announcing that Pin Payments has acquired our subscriptions based service and customer base. Spreedly itself isn’t going anywhere. We’ll be focusing on what was our Spreedly Core (now just Spreedly) service.
The transition will be a gradual one, with the Spreedly team continuing to be involved with all support until the end of September at the earliest. We’ll be carefully maintaining all the API endpoints our customers are using today, so that even as the service moves to Pin’s domain existing integrations will not be affected. Also, if and when any IP addresses change, we’ll notify customers whose gateways do IP whitelisting so that they can add the new IP’s well in advance. Our goal is to ensure uninterrupted service through the transition and then enhanced services as Pin Payments takes over the service entirely.
Spreedly began back in 2008 focused on solving the problem of payments for digital subscriptions. As developers we were dismayed by the lack of simple, elegant options for managing online subscription billing. To give our customers ultimate flexibility we created an independent credit card vault that worked across multiple payment gateways. No longer would your livelihood be tied to some antiquated payment gateway.
Subscriptions though is a subset of a much larger online commerce market. Soon we were approached by companies interested in the benefits of our vault and multiple gateway capabilities. They wanted access to a non subscription set of API’s. It fit well with our overall goal of enabling developers to create really cool new services where payments were no longer the bottleneck. Thus we launched Spreedly Core. With 30% month over month growth rates we now had two related, but distinct, services competing for our development resources.
When Pin Payments, an early customer on Spreedly Core, approached us interested in acquiring the subscriptions business we knew it made sense. The functionality was a natural extension to their newly launched payment offering. Culturally, they’re also a developer focused payments company trying to make life easier for their customers. And their global aspirations lend itself well to supporting our diverse customer base.
We know that any type of change can create concern for customers. Understand that Spreedly and Pin Payments have a sustained ongoing relationship which creates strong incentives to ensure this transition goes as well as possible. Perhaps most importantly for the long term success of the service is Pin’s plans to invest and enhance the service going forward.
A quick note to say we’re happy to be selected to present at FinovateFall in New York this coming September. For those of you who don’t know Finovate is a 2 day event held in different parts of the world focused on the very latest technology emerging around banking and finance. (Website link if you’re interested)
If you’re attending the event it would be great to see you there. Also, if you’re in the NY area and want to meet up while we’re in town just let us know. Oh, and we’re also really excited about what we’ll be unveiling/presenting at the event.
Today we’re pleased to announce that we’ve successfully closed a seed round with E-Merge, our second seed round after a previous round in December of 2012. E-Merge is the perfect partner for Spreedly with their strong focus on payments (they were an early investor in Ogone) and having already invested in a Spreedly customer (Cabify). A Belgium based group probably wouldn’t be investing in a Durham, NC startup without AngelList so we’re also really thankful for the resource they’ve created for the startup community.
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.
When accepting payments online (Authorize.Net, SagePay, Braintree etc) you can elect to store your customer’s credit card data. It’s an obvious requirement for recurring payments and potentially a good practice for one time payments (by pre-populating a shopping cart for a returning customer). So what happens to your customer’s credit card data if you decide to change payment providers? The answer is “it depends”.
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.
One of the parts of working on Spreedly that gets me personally excited is the fact that we empower merchants and consumers to explore payment options beyond credit cards. Now don’t get me wrong: the credit card network has a lot of benefits. For one thing, it’s virtually ubiquitous, and for another the speed and ease with which money can be moved by it is really handy. But it also comes with downsides, such as the fact that it’s not exactly a hotbed of innovation, and that it’s ridiculously expensive.
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.
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!
Spreedly is a credit card vault in the cloud that allows you to work multiple payment gateways simultaneously or over time. As such, we’re in a unique position to see transactional data across payment gateways for our customers. Failed transactions are an ongoing concern for all of our customers. At best they equal a costly customer support intervention and at worst lost sales. So while many merchants spend time on sites like Feefighters trying to optimize rates paid others understand that failed transactions are potentially the same or more important than the fees they pay.
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 part of life when accepting credit cards online, with insufficient funds and expired cards being two obvious examples of what can go wrong. However, often the reason for a failure is not clear and can be quite perplexing. Many merchant’s accepting online payments know the frustration where after many months of successful renewals a recurring charge is suddenly declined for a customer who swears there are sufficient funds. Or there might be a specific country where failure rates seem higher – but are they? Or a potential customer may have a failed transaction on your site while telling you they just used their card ten minutes earlier successfully on another site.
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:
- There’s nothing breaking/new between Spreedly and this payment gateway as other customers are not impacted (always important to rule out)
- The customer knows that they’re now well outside of the norm for that gateway.
- 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)
- 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.
In general, vaulting credit cards is a good thing. It’s basically mandatory if you want to do recurring billing. It’s also helpful if you’re a more traditional shopping cart. Re-populating a shopping cart with even partial data increases closure rates.
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.
Pin Payments is Australia’s only all-in-one programmable multi-currency payment system. Grant Bissett is Pin Payments’ co-founder and product manager. Below he explains how Spreedly is helping them to change the payments industry in their corner of the world.
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:
- 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.
- 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.
- 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.
DigMyData is a third party analytics service that Spreedly offers, free of charge, to our subscription service customers. Adam is DigMyData‘s CEO. Below, he shares his thoughts on DigMyData for Spreedly customers.
Remember that time when your investor or partner asked what your churn rate was last month? Did you have an answer? How hard would it be to calculate? Where would you get the data? How long would it take you to format and group the data to run the metric formulas?
Our service, DigMyData, takes all the headaches out of the data management and production of metrics for your Spreedly data. As Justin has just announced, the Spreedly metrics in DigMyData are now available for free – courtesy of Spreedly.
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:
Quickly view metrics
Combine metrics into report for comparison
Note special events like promotions or policy changes
How did you do compared to last week? month? year?
Look into the future
Group and sort the data underlying the metrics
Combine metrics with +, -, x, and ÷
Display that one critical metric in the office
Embed reports on a webpage or link to a standalone page
Share read-only access to DigMyData
Track different companies separately but access them with a single user
As of today all Spreedly customers can now get free Spreedly subscription metrics on this special Spreedly signup: https://app.digmydata.com/spreedly-signup (to get Spreedly metrics free you need to signup on this page).
Spreedly signup at DigMyData
Email us at firstname.lastname@example.org with any questions or if you just want to say hi!
Beyond Spreedly we also have integrated with the following:
Today we’re happy to announce that all Spreedly subscription customers (if you can log in here then that means you) have access to DigMyData as their reporting tool. You’ll be able to track new users and cancellations, revenue amounts and transactions all within the DigMyData UI. On top of that you can export the data in .csv format. Yes, there is even reporting for “churn”!
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.
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.