Spreedly Blog

Failed transaction rates by payment gateways

Posted on May 8, 2013 by Justin

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:

Examining Payment Gateways and Failed Transactions

Posted on April 25, 2013 by Justin

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.

Vaulting Credit Cards

Posted on April 10, 2013 by Justin

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.

How Spreedly Helped Us Change the Payments Landscape in Australia

Posted on March 24, 2013 by Grant Bisset

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.

Spreedly + DigMyData = Subscriptions Metrics

Posted on March 18, 2013 by Justin

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:

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

Look into the future

Details

Group and sort the data underlying the metrics

Custom Metrics

Combine metrics with +, -, x, and ÷

Fullscreen mode

Display that one critical metric in the office

Sharing Reports

Embed reports on a webpage or link to a standalone page

Users

Share read-only access to DigMyData

users

Multiple companies

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 support@digmydata.com with any questions or if you just want to say hi!

Beyond Spreedly we also have integrated with the following:

Payments: Spreedly, Stripe, PayPal, Google Checkout, Authorize.net
Email Marketing: MailChimp, AWeber, Campaign Monitor
Spreadsheets: Google Docs, XLS, CSV
Web Analytics: Google Analytics
Advertising: Google AdWords
Tools: Gmail, Blogs/Feeds (RSS)
Social: Facebook, Twitter

Thanks everyone!

Any discussions or comments may be here

Spreedly, DigMyData and Reporting

Posted on March 18, 2013 by Justin

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

Spreedly

Reporting for Spreedly Subscriptions

Posted on March 7, 2013 by Justin

With our subscriptions offering the goal has always been to keep it simple. We wanted developers to have something quick and easy to work with to support digital subscriptions and avoid payment gateway lock in.

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!

How we worked with a competitor to win the “Netflix of India” business

Posted on March 5, 2013 by Justin

For those of you who don’t know, Spreedly was born from a consulting project that bogged down trying to implement recurring billing with PayPal as a gateway. Being developers we wanted a service that was easy to integrate and gave our customers freedom from archaic business and development practices found at many payment gateways. Over time, we realized that the infrastructure that we built to support our recurring service was applicable as a stand alone offering. So we broke that out separately from our recurring solution and offered it as a stand alone service. At that time we called it Spreedly Core although it’s now just Spreedly.

I was on AngelList some time back and noticed an Indian based startup focused on subscriptions called ChargeBee. It was probably something along the lines of “We now support Stripe!” So I contacted one of the founders (Krish) and said “You know, if you integrated to Spreedly you’d immediately be able to offer 45 different payment gateways. In addition, because you vault your customers’ cards away from the gateways, they have the ability to switch at any time. Stripe just launch in Europe? Sure you can switch because we’ve vaulted the cards.”

It was an odd marriage. Here we were selling a subscription/recurring service in the marketplace that in many ways directly competed with ChargeBee. It was just as strange for them as well! Trust a key component of your stack to a competitor? (Maybe we can convince Krish to write a post to explain how they rationalized it.) At Spreedly we thought – what if someone prefers ChargeBee over our subscriptions service but only chooses us because we support their gateway choice and ChargeBee doesn’t? Or because storing their cards away from the gateway is critical? I guess getting a win is a win. It seemed much cooler though to help all ChargeBee customers (and therefore ourselves) by offering them access to Spreedly’s new service.

Around 2 – 3 months after we began working together I got an email from Times Internet of India. They were planning to launch the “Netflix of India”. They wanted card vaulting, gateway independence and subscription/recurring functionality. We could have tried to go it alone but here was ChargeBee who was a) in the same time zone, b) better able to support the customer in terms of customizations and modifications and c) could supply all the goodness we could as they were on top of Core. So all three parties worked together and earlier this month BoxTV.com was launched. (It turns out when I mentioned ChargeBee both sides had already had some discussions so that didn’t hurt.)

It’s not just ChargeBee either. Fusebill, another subscription management offering is also using Spreedly. I was explaining Spreedly Core to their CEO on a call when he stopped me mid-sentence and said “Adding payment gateways on a case by case basis is a huge pain for us! How can we take advantage of what you’ve built?”

We’ve definitely driven business to our customers when they weren’t a fit for our subscription offering. In addition, we’re a stronger company based on the growth and usage we get as our customers grow overall. And we drive more independence into the marketplace as a whole.

Sometimes some of your best customers might be where you least expect to find them.

Heroku Add-On redesign: Impact to Spreedly lead flow

Posted on March 5, 2013 by Justin

Spreedly is a a credit card vault in the cloud that connects to more than 45 payment gateways. Vault your cards with us, significantly reduce PCI compliance headaches via a transparent redirect, and work with one or multiple payment gateways over time or simultaneously. We have also added alternative payment types like Dwolla, GoCardless and of course PayPal. (Read about our recent re-launch here)

Heroku’s add-on marketplace seemed like a great potential channel for us. Building an app on Heroku and want to accept payments? Stripe + Dwolla? Braintree + PayPal? Stripe + Braintree + PayPal + Authorize.net? Just select Spreedly as an add on and you’re good to go. Shortly after pushing our new offering live in March 2012 we turned to integrating with Heroku’s add-ons. July 2012 was our first full month in the add-ons store. The following chart shows trial sign ups from Heroku, from all other sources (Spreedly) and then the combined total.

Heroku July

So around 28% of all trial sign ups were coming from Heroku in the month of July. We had 3 customer begin on payment plans too – albeit our smallest most basic one. Still, any time you can add a new channel and increase your lead flow nearly 30% you’re happy!

September is a great month in the Northern Hemisphere. Everyone’s back from summer vacation and starting up projects. Smaller projects you put off over the holidays or enterprise projects you have in mind for the next calendar/budget year. We were still a bootstrapping service and relying on word of mouth but we were happy do 71 trial sign ups in September. It was our best month to date. But we were struggling with Heroku.

We’d gone from 28% of leads attributable to Heroku in July to just 14% in September. It seems we’d fallen into the “We were hot while we were the new kid on the block” and by September interest had cooled off. Worse, we didn’t add any new paying customers in the month of September. We were really happy with overall traction and interest in Spreedly – but Heroku was disappointing.

A blip or a trend?

November and December are both a bit problematic in the US. Thanksgiving is November in the US and then there is Christmas. So that can impact data. Still, here’s November (which did predictably drop off in the last week for all new activity)

Again, right at 15% of sign ups coming via Heroku’s add-ons. We’re now pretty sure we’re staying at this level for the foreseeable future.

Heroku then completely redesigned their add-on store. We were pushed live during the first few days of January 2013. (We needed to make changes to our profile to support the new design so we didn’t go live as soon as the new format went live) The response was immediate and impressive.

Heroku delivered 3 times as many leads to us in January as they did in November. That’s a big bump! In a relative sense they were also back to being 30% of all leads for us again.

I wanted to wait and see what happened with February. Perhaps it was just a blip again? Well through the first 3 weeks of February we were still on track at 30%

“Coffee’s for closers”

i) Leads aren’t sales. We did start adding new customers again in January – which really hadn’t happened much in Q4. It’s too early to tell if Heroku leads are worse/same/better quality than other sources.

ii) Pricing problems: Heroku’s add-ons don’t support metered pricing. So we have to create plans that sort of look like our pricing. However, they don’t map exactly and that matters to some customers. We’re pretty sure that some Heroku users prefer to sign up directly vs activate purely via Heroku. Sort of like “Shop in Orbitz and buy direct from the airline website” mentality (sorry Heroku if you’re reading this!)

iii) This last point makes us less concerned about the revenue that flows through to directly from Heroku. Again, while starting up, the exposure itself is fantastic.

iv) We’re the only option under “Billing” right now in Heroku. I’m sure that will change over time (after we publish this?) That will impact interest once it happens no doubt.

With our major re-launch and announcing funding at the start of March our March metrics will break from the previous trend. So this is a good point to take this snapshot and lay it to rest. In summation Heroku’s add-ons have been:

Great free marketing for a bootstrapped startup via the exposure
Ok on new customer wins
More weighed to “tire kickers” than folks who sign up on our site directly

Of course, our results will be directly impacted by how relevant we are to the Heroku audience and profile. We tend to find our best prospective customers are running larger, complex commerce/payment platforms.

Any comments might be here.

Spreedly – Funding, expanding our horizons, pivoting

Posted on March 4, 2013 by Justin

For those of you who don’t know, Spreedly was born from a consulting project that bogged down trying to implement recurring billing with PayPal as a gateway. As developers ourselves we wanted a service that was easy to integrate and gave customers freedom from archaic business and development practices found at many payment gateways.

And so the journey began: we built a vault to store cards away from payment gateways (critical for recurring). We integrated with as many payment gateways as possible, via ActiveMerchant, to give our customers maximum choice. We dramatically reduced the burden of PCI compliance with a simple elegant hosted payments page (and later via a transparent redirect). We took care of prorating, upgrades and downgrades, dunning emails and so on. We tried to find all the ways that doing recurring/subscriptions against existing gateways was broken and fix it.

Over time three trends converged. People who had no interest in recurring or subscriptions approached us, intrigued by what we’d built to work effectively with 45 + payment gateways. Secondly, newer payment choices like Stripe, Pin Payments and PayMill emerged which included basic recurring capabilities. Lastly, we watched direct competitors arrive in the subscriptions space such as Recurly, Chargify and then later ChargeBee and Fusebill.

To prosper, we had one of two choices. We could double down on our subscription offering by distancing ourselves from the competing basic gateway offerings, which would mean adding support for such things as taxation, invoicing, shipping, multi language etc. Or, we could remove our recurring logic and give anyone who was doing online payments direct access to our API’s to go build great services.

We chose the second option and launched Spreedly Core to the public in March 2012. Within 8 months we were processing more monthly revenue via Spreedly Core than 3.5 years of subscriptions. We hope to process $25 million for customers in our first year ending in March. We have a long way to go but today we’re here to announce that we’re “all in” on Core. We closed a small angel/seed round in December 2012 and went to work.

Spreedly’s aimed at developers and services that:

Want to vault their credit cards away from the gateway yet don’t want to be in PCI scope by managing that process themselves
Need to work with multiple payment gateways either simultaneously or over time
Want to develop against a consistent, modern API that will work with any gateway we support irregardless of that gateway’s own API and documentation
Want to support non credit card payment types like Dwolla, GoCardless, PayPal and more alongside credit cards

We know we’re not targeting everyone who wants to accept payments online. Services like Stripe, PayMill and Pin Payments have done a fantastic job of essentially making payments an afterthought – which is what they should be for many developers. However, if the inability to scale payments could be a drag on your business velocity then Spreedly is worth a look. It’s easier than ever to get a merchant account, and it’s not much more work to have the flexibility to change gateways or work with multiple gateways if that’s your focus.

Today, we’re announcing a new site and completely new pricing to reflect our new focus. We hope you enjoy it. Recurring and subscriptions are a critical component so we’ll continue to support our recurring customers today and going forward. It’s just that we’ve dramatically broadened the scope beyond recurring only. We’ve taken two sites and merged them into one. We’ve moved away from leading with subscriptions and now lead with our gateway flexibility story. Oh, and we’re pleased that some of those subscription competitors are now some of our most important Spreedly customers!

We’re open for business. Come solve scale related payments problems here.

Comments welcome here: http://news.ycombinator.com/item?id=5317894

PayMill, ActiveMerchant and Spreedly

Posted on February 16, 2013 by Justin

At Spreedly we work with more than 45 payment gateways. For the last two years we’ve watched developers in the US embrace Stripe while developers in Europe lamented their lack of a similar option. So the arrival of PayMill – a Stripe like competitor – has attracted a substantial amount of interest from our European customers and prospects. They also raised a lot of money very quickly – including annoucning a $13 million raise in January only to add another $5 million in February.The involvement of the Samwer brothers has made some less enthusiastic about PayMill than others. All we can say at Spreedly is that this is the most requested gateway since Stripe itself showed up.

Today we completed the pull request so that PayMill is now in ActiveMerchant. It’s also supported in Spreedly Core. We think Europe is about to experience the type of innovation and disruption in credit card based payments that the US has enjoyed over the last few years. Spreedly might be your port in the storm if you want to have the flexibility to take advantage of the change that’s coming.

Why Spreedly when I just need a single payment gateway?

Posted on February 11, 2013 by Justin

We get this question fairly often so let’s lay out the use case for why you might use Spreedly vs just going with a single payment gateway/merchant account.

Spreedly customers generally fall into one of two categories. The first category are services that need to work with multiple payment gateways simultaneously. Let’s say you’re building the next Shopify or Freshbooks. Or you’ve built an elegant mobile platform targeting florists/plumbers/restaurants/sports stadiums. These folks want to use your service but you need to support their existing payment gateway of choice if you’re going to win the business. You could build out those integrations yourself or you could integrate once to Spreedly Core. Therefore you might use something like Stripe, Pin, Braintree or PayMill by default if customers don’t have a payment gateway and then support those with a pre-existing choice – all within Spreedly.

Now to the question at hand though; you only need to use a single payment gateway. Why would you use Spreedly – especially given our fees are in addition to the payment gateway fees? (I’m going to avoid linking to our fees just now as we have some major changes in the short term works so will update this post when they’re live). There’s a very good chance you wouldn’t. Unless one of the following scenarios applies:

You believe you’ll want to change payment providers in the future. By working with Spreedly that process is really simple. We really like this approach for ambitious (read big revenue plan) startups. Understanding startup payments is hard (although we try and help here). Spreedly allows you to start with a payment gateway of choice that allows for immediate sign up and billing. So avoid becoming an expert in payments until you actually have some payments! Then if you do need to change that change is simple. Business drivers for change might be the obvious piece like better rates. Additional business drives though include moving your office to a new country. Or you might be waiting for a new payment provider to reach your shores and want to be able to switch then.
You don’t get to choose the single payment provider. You might be a consultant or this might be a larger organization that has negotiated some amazing processing rates from a provider. Here Spreedly allows you to work with a modern API and documentation (bypassing the antiquated one) while still doing all the processing against the designated payment provider. In particular if you’re a development shop you can default to Spreedly as your payments integration and save clients time and money by just dropping in their particular choice (and also allowing them to change at any time too!)
You want to support non credit card payment types like PayPal, Dwolla, GoCardless etc alongside credit card processing. Spreedly allows you to do that.

These are the reasons why you might use Spreedly with a single payment gateway scenario. If though you feel like you’re in a location with some tremendous modern options and needing to change gateways within 3 years doesn’t feel likely then we’d say integrate directly to your payment gateway of choice.

We hope that clears up any questions.

Spreedly Core passes $20 million processed

Posted on February 11, 2013 by Justin

After moving Core out of beta it took us 7 months to process $10 million on behalf of our customers. Now, a little over 3 months later, we’ve passed $20 million. We’ve got a long way to go to hit our goal of ensuring that payments are never the tail that wags the dog of your service - but we’re off to a great start. Thanks from all of us here.

Startup CEO – Understanding Online Payments

Posted on January 25, 2013 by Justin

If you are the CEO of a startup that plans to accept online payments the landscape can seem daunting. There are a lot of individual articles on PCI Compliance, Payment Gateway/Merchant Accounts and new emerging payment types of different size and length. This post attempts to tie the key concepts together into a brief overall primer to get you going. Given we’re providing services in this space I’ll also pitch Spreedly at the end.

Potential Pitfall 1: PCI Compliance

Your goal is to reduce your PCI compliance scope to the bare minimum. Too often I see comments saying “We use XYZ payment provider so we have no PCI responsibilities” That’s not quite true. Even if you do everything right you still need to complete a SAQ-A - essentially a one page self assessment questionnaire. Therefore your true goal is to aim for a SAQ-A vs falling into deeper scope and having to complete a much more complex SAQ-D. If someone is telling you that their solution means you have no PCI compliance requirements it’s a red flag that at best they are naive.

What does that mean in practical terms as it relates to your company? That you’ll either use a hosted payments page or a transparent redirect. The goal for both is the same. When it comes time for your prospect or customer to enter sensitive credit card data it won’t touch your servers at all. That will keep you outside of the more rigorous PCI compliance scope.

Payment pages come in two forms. The most “extreme” is the PayPal, Amazon, 2CheckOut type of approach. Here your customer leaves your site completely and lands on an alien page to complete their transaction. This definitely solves PCI compliance scope issues. It can also infuriate developers/business analysts because that’s a complete blackhole in your process flow. On top of that, some of these services try and motivate your customer to do something other than just complete the transaction – which can drive payment abandonment higher. There may be some benefits – especially if you’re a very small startup selling to consumers. The thought that a “trusted” brand like PayPal is where the financial transaction is occurring may help you close sales from wary customers. In general though try and avoid these “offiste” branded payments pages unless you have no other choice. (after seeing this post 2CheckOut tweeted to let us know that they’re actively making changes to their checkout process to reduce the issues highlighted here)

Then there are “gentler” payments pages. At Spreedly our subscription service uses a much gentler payments page. It’s designed to be simple, clean and elegant. We suspect in many cases people don’t realize they’ve left our customers’ site for another service. Many other services also offer their own payments page as part of their value proposition around PCI compliance scope reduction. The major drawback? Again, you don’t control the design of that page. There are other benefits beyond PCI Compliance scope. Higher conversions via an experienced service optimizing flow based on gobs of data.

Transparent redirects are in part a response to the constraints of hosted payments pages. They allow complete freedom in the design of your payments page while still keeping you outside significant PCI Compliance scope. Transparent redirects are a newer process so if this is critical to you then that’ll limit the number of payment gateways you can work with – which may be a good or bad thing.

Selecting a Payment Gateway

A Internet merchant account is the special bank account that allows you to capture and store money from other banks (via your purchasing customers’ accounts) In a retail store that data usually travels over a closed POS network in an all in one event. Transacting online required the creation of payment gateways to replicate the point of sale (POS) network. If you want to start accepting payments online you’ll need both: a merchant account and a payment gateway to connect to that merchant account.

You can purchase the two separately, and many businesses do, but the industry trend is toward buying the two together in a “bundle”. PayPal largely led the way followed by Braintree (who admittedly focused much more on the payment gateway end) and then Stripe. Europeans are embracing PayMill while Australians have Pin.net.au. Therefore “You need a payment gateway” typically means you need a payment gateway and a merchant account. For that reason many people find it easier to purchase them together.

If you go to your existing banking partner they’ll charge you to set up an internet merchant account. They’ll then usually bundle in a payment gateway with the package (most commonly Authorize.net in the US while Ogone seems very popular in Europe) You can call Authorize.net directly and they’ll bundle in a merchant account. Pro tip: If you’re going to take this approach I suggest working with the payment gateway as the primary. If a payment gateway sells you a merchant account they’ll let you switch the merchant account. If the merchant account sells you the payment gateway the payment gateway won’t let you switch merchant accounts – it’s a channel thing. Given you integrate to the payment gateway API’s those changes are more challenging in the long run.

The payment gateway/merchant account landscape seems to be splitting into two worlds. For 2.9% and 30 cents you can get set up immediately to begin accepting payments (see the list of combined payment gateways I mentioned above). You can work with an elegant, modern API. You’ll most likely get credit card portability included (more below). Support – both direct and online – will usually be good and prompt. Your developer/s won’t follow you out to your car late at night with a menacing look.

The other choice is to fill out paperwork, wait as little as one day or as long as a week for an approval. If you’re small or just starting out you might get rejected or asked for more details. Then you’ll find an API/documentation that your developers will be less than thrilled about. Depending on the provider, getting your credit card data back if you wish to leave might be impossible too. The reward for all this? Processing fees closer to 2% and 20 cents a transaction at scale. That’s approximately $100,000 + per year on a $10 million top-line store. (Check out Feefighters.com if you want to get into specific scenarios based on average ticket size etc)

One final note. Understand your business. Banks and merchant accounts are trying to assess the risk you bring. Risk is based on refunds, chargebacks and the chance you’ll go out of business. Are you going to have a high ticket (price) item? Are you going to do very little volume then suddenly burst into activity via a flash sale or event? Do you think your business lends itself to requests for refunds? If you’re going to look “erratic” then I strongly recommend talking to the merchant account first vs just using an immediate sign up service. It can reduce the likelihood of the dreaded “freeze” or hold.

Storing Credit Cards

Logically, you really have to store cards for subscription services. You don’t have to store cards in a one time commerce scenario but most studies show substantially higher cart conversion rates if you can prepopulate prior card information. Short answer – storing cards is usually either required or a good practice when it comes to sales and follow on sales.

Storing credit cards is a subset of PCI compliance. Let’s start by saying it would be great if you could store your own cards. That means you could change or add a new payment gateway at any time. No longer is a credit card tied to a particular gateway – it sits away from the gateway. This can help you with your initial payment gateway selection (make it less critical to pick the right gateway for today and for tomorrow). You can add gateways as you grow internationally or keep a gateway as a permanent “hot backup” should you experience issues with your primary gateway.

If your business model includes allowing your customers to process credit cards within your application then having your own credit card vault is almost a requirement. Let’s say you’re building the world’s greatest CrossFit gym membership solution. You’ll want to work with as many payment gateways as possible so that you can sell to cross fit gyms in Seoul, San Francisco, Sydney and Seville. Your customers – the people running those gyms – will want you to support local selections. If you don’t help them vault away from their gateway you’ll reduce their ability to change if they need to. You’ll also tie your hands on strategic payment partnerships in the future.

Yet storing cards puts you fully into PCI compliance scope. Even for a startup (small volumes) you would want to budget $75,000 to $100,000 per year to cover hard and soft costs around maintaining PCI compliance. It’s for these reasons that most people store their cards at the gateway. Spreedly aims to solve that problem – more on that near the end.

A form of lock-in that payment gateways have is not returning your cards to you (or in practical reality along to your new preferred payment gateway) Unless you doubt you’ll ever want to change payment gateways insist on getting an answer as to whether they support credit card portability. It’s rare but becoming more common thankfully. Credit card portability will help cushion the blow of changing gateways but it’ll still be a fairly meaningful project (API integration, matching tokens to existing users etc)

Alternative Payment Types

Lastly, there are alternative payment types to credit cards. PayPal as a payment type is probably the best known one. Newer payment types include Amazon payments, Dwolla and GoCardless. It seems there’ll be more to follow. You’ll want to accept these based on customer demand or a desire to drive down your transaction costs. For example, GoCardLess, which is UK based and expanding in Europe, is a bank to bank transfer and only charges 1%. So the appeal is obvious. Newer payment types aren’t typically supported by payment gateways (PayPal is the most frequent exception) so today they’re a separate effort to support.

Then there are regional payment types – especially in Europe. European’s tend to have more direct or debit payment types and they depend on the country involved. Dankort, ELV for Germany and more. If those markets are critical you’re going to have to add or start with a European gateway.

Summary (Yes and the Spreedly Pitch)

The good news is getting a payment gateway/merchant account continues to get easier while the services themselves get better. That’s a nice combination. If you don’t see yourself selling outside of your national market and staying under $1 million in revenue then picking any of the “all in one” options I listed should work. Stripe might be the most elegant. PayPal has the scariest reputation but moves you down from 2.9% to 2.5% as soon as you hit $10,000 per month. Braintree has an ever increasing international reach.

Or you could integrate to Spreedly – in particular our Spreedly Core service. We vault your cards away from the gateway. We offer a transparent redirect. We work with 40+ payment gateways and are adding support for non credit card types. We give you the independence to store a card and charge it against multiple gateways. We give you the ability to support the gateways that your customers need or want to use to process within your service.

If you’re interested check out Spreedlycore.com – which is soon to be combined with Spreedly.com into one single site.

Marketplace On-boarding

Posted on January 15, 2013 by duff

In Justin’s post Marketplaces and Payments, he mentioned that “marketplaces are going mainstream and payment solutions are following to accommodate their needs.” “Marketplace” is a fairly broad term. In general, when you build a marketplace you expect transactions to occur between buyers and sellers within your service.

Due to the difficulty of getting a merchant account, accepting payments has not been an option for many participants in a marketplace. Marketplace owners have had to hold and disburse funds, which is complicated. More recently, though, asking your merchants to accept payments directly is becoming easier thanks to companies like Stripe, Braintree, Pin.net.au and PayMill. There are still situations where you may want to hold and disburse payments, but now it’s a matter of choice rather than a necessity.

Justin also wrote, “Wherever possible offer support for multiple payment gateways – in particular the ones that allow for easy on-boarding of any merchants.” One of our goals for Spreedly Core is to make it even easier for businesses to create such marketplaces by enabling our customers to allow their customers to accept payments.

We’re thrilled to see companies like Stripe offering services like Stripe Connect. And it’s wonderful that GoCardless has a Partner API. Both of these are examples of payment providers greatly simplifying the merchant on-boarding process using an OAuth type approach.

We think it’s only a matter of time before other payment providers follow suit in providing OAuth type flows. In addition to super easy on-boarding of new merchants, the OAuth process also makes it easier for third parties to obtain authorization from a merchant to access their merchant account. And it makes trying third party services out much less risky for merchants since they can easily revoke access for a single service if they need to.

On the Spreedly Core side, the approach we’ve taken is to generally stay out of the OAuth flow for these payment providers. This gives you complete control in how you’d like your customer to go about seeking the authorization needed. OAuth includes a number of HTTP redirects and API calls and at this point, we don’t get involved there. At the end of the authorization though, you’re given an access_token. And it’s that access_token that gets used by Core when you’d like to create a gateway (Stripe example, Gocardless example). Once that gateway is created, you have the ability to interact with it and process payments just like you do with any other gateway.

Since Core vaults the credit cards away from the gateways, this means marketplaces can offer their customers the wonderful ability to change gateways whenever they’d like without needing their ultimate customers to re-enter credit card information.

Marketplaces and Payments

Posted on November 1, 2012 by Justin

Unlike traditional ecommerce/online sites, that have one seller and many buyers, marketplaces have many sellers and many buyers. In addition, any transaction involves three parties: the seller, buyer and the marketplace. This uniqueness has always created challenges for marketplaces wanting to accept online payments. “Too hold or not too hold the funds” – that is usually the question.

Recent trends in payments are slowly making things easier for marketplaces. While it’s hard to pick winners and losers one thing seems certain: marketplaces are going mainstream and payment solutions are following to accommodate their needs.

From the very beginning of the commercial Internet there has been an interest in the “digital” marketplace. Long forgotten early Internet startups like CommerceOne and Ariba planned to be massive B2B marketplaces. (Ariba survived then thrived after a pivot to e-procurement) Ebay, focused in on the consumer and small business, fared much better. This might be because they were capturing/creating an untapped market vs competing for an existing one.

Market places go hand in hand with payments. PayPal‘s initial focus was peer to peer payments via email. It was a perfect match with Ebay’s client profile. Ebay and others launched PayPal competitors but ultimately came to the “If you can’t beat them buy them” conclusion. Ebay’s acquisition of PayPal highlights the tight intertwining of payments and market places. Another example of marketplaces and payments going hand in hand? Kickstarter. Kickstarter is wildly popular but also only available in the US. Why? Payments: specifically Amazon’s payment services which are only available in the US. (Note – Kickstarter just launched in the UK!)

Just like Ebay before, marketplaces like AirBNB, Etsy and Fancyhands are creating many first time sellers. To accept credit cards online you need a merchant account/payment gateway. Traditionally banks only give those out to sellers who have an established business or history that mitigates risk associated with a merchant. Many marketplaces pull in new sellers who find the whole process of procuring a merchant account daunting and/or not possible. Significant friction around payments is a huge drag on marketplace growth meaning payment problems are strategic problems. Yet taking on the ownership of holding the funds on behalf of buyers is a major regulatory undertaking.

Etsy, Airbnb and TaskRabitt had to create their payment platforms from scratch. Many start off defaulting to PayPal only – but that approach can create end user animosity. Merchants want choice. So what should your approach be now if you’re starting a market place? Well there are changes in merchant accounts, payment types and dedicated services – all of which are making it easier to launch your offering.

Firstly, on the merchant account side. PayPal blazed the way with a single merchant account/payment gateway experience. Recently, Stripe has picked up where PayPal left off and dramatically simplified (at least if you’re a developer) the ease with which you can begin accepting credit cards online. Braintree arrived earlier than Stripe but has only recently followed suit with a similar pricing and approach in the U.S. Although Braintree has a much larger international footprint than Stripe the simplified merchant account offering is only available in the US and Canada. In Australia Pin.net.au - currently in “invite only” mode – plans to roll out a similar process. It’s safe to assume that the UK and then European countries should have a similar offering within 12 – 36 months either from established players or new entrants. Given the complexity of financial laws in each country local payment companies/startups have the chance to compete against the global players.

What does this mean if you run a marketplace? Even the smallest online seller should be able to set up their own account and begin to accept credit cards online. Stripe, Braintree and Pin.net.au are to online payments what Square is to the local Farmer’s market. The chances that you’ll need or want to control funds in escrow on behalf of your sellers is significantly reduced.

Stripe has even taken it a step further with Stripe Connect. Stripe Connect is aimed at easing the on-boarding process of new merchants that need to procure a payment gateway to work with your marketplace. It’s a smart move but it does contain risks for marketplace owners. You have a lot of eggs in one basket. Also, you walk a fine line between “pointing” someone to a third party service and “recommending” a third party service. The last thing you want is your merchants blaming you should Stripe ever fall out of favor (after all, PayPal was once popular with developers). For that reason we think Stripe Connect is a smart thing for marketplaces to offer but probably not exclusively.

As a marketplace owner in the US and Canada (and hopefully globally soon too) you now have some great options for even the smallest seller being able to accept credit cards from their customers. What about non credit card payment types? Well, here too there is a lot of innovation occurring.

Two examples of newer payment types are Dwolla and GoCardless. Let’s clear up a regular source of confusion right away. Neither Dwolla nor GoCardless let you accept credit cards. So it’s not an “either/or” option. Many of you will need or want to support payment gateways and these payment types. Braintree + GoCardless + Dwolla for example.

Dwolla and GoCardless are money transfers not credit transfers. In Dwolla’s case you basically drop an amount of money into your Dwolla account from your regular bank account and then use Dwolla to transact. You top it up when it gets low and start again. In GoCardless’s case it’s working with the existing ACH or the direct deposit process only striving to make it more elegant. Both of these payment types allow for person to person payments. Dwolla recently launched a “mass pay” option too called, well, MassPay that may be useful to marketplaces.

Why offer Dwolla or GoCardless along with credit cards? The most obvious = cost savings. There is no charge for a transaction under $10 with Dwolla and just 25 cents for any transaction over $10. GoCardless is 1% of the sale price. (A recent post by Braintree shows that back of the envelope around 4% of a transaction goes to credit card fees.) Then there are other costs like chargebacks, typically around $15 each, and involve a person saying “I don’t remember agreeing to this charge from this merchant”. $50 online sale? $2 to a credit card. 50 cents to GoCardless. 25 cents to Dwolla. Compelling economics.

The second reason could be cultural or geographical. The financial crisis of 2008 (and longer elsewhere) resulted in an increased pool of people adverse to the idea of “credit” payments. They are looking for alternative ways to pay. Secondly, in many areas outside the US credit card transactions represent a much smaller percentage of online transactions. Many regional European markets have a preferred – typically ACH or bank transfer – approach they use. If you envision a meaningful percentage of your merchants being outside the US you’re going to want to consider non credit card based payment types.

The last reason is price point. Even corporate credit card users typically have a max upper limit – say $5000. If you envision selling goods or services above $1000 it might be a requirement that you have a non credit card way to do that.

What are some of the drawbacks? Well, Dwolla is US only today and GoCardless is UK only. (Although I believe GoCardless has short-term expansion plans within Europe) Secondly the time for money to settle between two parties tends to be longer than with a traditional merchant account (although the newer merchant accounts I mention above also have substantially longer payout times than a “normal” merchant account – partly to manage risk and partly to reduce the need for a “reserve” on your account). In general both of these offerings are also very new so their success is not ensured. In short, we think they’re a great payment option to include alongside credit cards but don’t see them replacing the need for a merchant account any time soon. Again though, they are cheaper than cards and can facilitate peer to peer payment removing you from the headache of controlling funds.

What about “local” payment types like the Dankort, ELV and others? Here you’re going to have to support payment gateways in those regions that typically support popular local non credit card payment types.

The final group is “dedicated” marketplace payment solutions like BancBox and Balanced Payments. The general idea here is “Credit Cards + X functionality” and an awareness from the get go that there are three, not two, parties to every transaction. A merchant account/gateway is driven by the concept of a single merchant. These solutions are (or certainly should be) built from the ground up with the 3 party model in mind and know that you, their customer, is a marketplace vs simply a merchant. It’s a subtle but important difference.

It’s early for these offerings so it’s hard to argue around the advantages and disadvantages. One big drawback, similar to other solutions discussed here, is that they’re currently US only. One benefit might be their specialization in areas such as crowd funding or questions around financial and regulatory requirements (1099′s etc). The trick here, like many “complete” solutions, will be balancing the additional functionality you don’t need to develop with the flexibility to support your marketplace when relying on a comprehensive solution.

This leads us to our final recommendations and thoughts. (Note, perhaps unsurprisingly, much of this thought is what drives our development of SpreedlyCore so there’s definitely a product pitch element to this.)

Wherever possible offer support for multiple payment gateways – in particular the ones that allow for easy on-boarding of any merchants.
Ensure your merchants can change payment gateways at any time without fear of technology lock in. The best way to do that is to vault their cards away from the payment gateways.
Support as many non credit card payment types as possible so as to offer affordable, alternative settlement types compared to credit cards.
Think globally so that your niche marketplace has the best possible chance of hitting a critical mass of buyers and sellers.

The last piece to our product pitch is we want to give you a consistent API experience to develop against and in some cases enhance what is already there from the source gateway in terms of functionality.

That’s it. Good luck.

Justin

Comment here: http://news.ycombinator.com/item?id=4727158

SpreedlyCore and $10 million

Posted on October 31, 2012 by Justin

Today – funnily enough on the last day of the month – is the day that SpreedlyCore passed the $10 million mark. That is, we’ve now processed $10 million on behalf of our customers. Not bad given we made it publicly available back in March of this year.

As excited as we are to pass $10 million in 7 months we’re actually more excited about the next 7 months (and beyond) given the customers who are implementing and launching soon. It’s the nature of the beast with Core – typically Core customers are building pretty big, impressive, complex payment/commerce services. So that takes a little time to get ready and get right. Here’s to looking back and forward at the same time.

Thanks everyone and now we’ll go back to our regular program. Just thought we’d toot our own horn.

Team Spreedly

Spreedly Subscriptions – Manage Employees/Peers

Posted on October 29, 2012 by Justin

One feature request we’ve heard somewhat regularly is the ability to delete users from a Spreedly site, such as when a contractor or employee has moved on. Up till now removing a user has required emailing Spreedly support, since we don’t want a site owner to be removed by a disgruntled employee (or partner!). To solve this dilemma we’ve now deployed roles and the ability to manage users without any intervention from Spreedly support.

We’ve created two tiers of users:

Member: A Member has the ability to do all the things that they can do today with one major difference. They cannot add/delete or modify users. Only Owners can do that.

Owner: An Owner can do everything on your site that they can do today. An Owner can also add and delete Members . One key thing to note: an Owner cannot delete or change the status of another Owner; only Spreedly can remove or change the status of an Owner.

Go in and review your user settings. You’ll want to tell us right away if there are any users set up as “Owner” today that we should move to another status. Just send an email to support and we’ll make the changes. Once we get you set up with all the right roles you should be good from that point forward to self manage your team.

To review your users, just log in to Spreedly, click on “Configuration” in the green menu bar, and then go into “Site Users” from there to see/learn more.

One final note: we also have the ability to create an additional view that we call “Associate.” The main goal here is to give a user access to your account without them being able to view any of your company financial data. If this is something you might be interested in please email support to learn more.

Hopefully this makes managing your team easier; as always drop us a line if you have any questions or suggestions.

SpreedlyCore and GoCardless = Together

Posted on October 16, 2012 by Justin

Today we’re announcing support for GoCardless with SpreedlyCore. GoCardless is a newer payment company based in the UK with short term European wide aspirations. Focused on Direct Debit rather than credit card payments they’re able to offer a rate of just 1% on transactions – including a cap. That’s obviously superior to credit card fees. Also critical is support for recurring payments alongside the more traditional one time payments. We picked GoCardless due to its popularity in the UK and the fact that they have expansion plans beyond just the UK. Europe presents unique challenges from a payments perspective. Direct Debit type payments are much more popular for online transactions than in the US. Yet each region/country has it’s own preferred offerings. If GoCardless can take a single direct debit payment solution European wide the benefits for all parties will be fantastic for all.

What this announcement means for merchants interested in GoCardless is two fold. Firstly, you can work directly with the SpreedlyCore API to develop your payments application. SpreedlyCore will allow you to do the following:

Securely vault the credit cards
Create your own UI and handle credit card data via a transparent redirect
Work with your preferred payment gateway from our expansive list
Support newer payment types like Dwolla, PayPal and now GoCardless.

Still, you don’t need to build your offering from scratch to work with your preferred payment gateway and GoCardless. There are several services that have partnered with SpreedlyCore. Select one of these services and you can work with your preferred payment gateways and payment types.

Subscription and Recurring

ChargeBee: ChargeBee is a new Subscription Billing solution for SAAS and Web 2.0 applications. ChargeBee focuses in on specialized reporting and data along with support for third party integrations like Mailchimp and CRM offerings. ChargeBee currently provides integration with 30+ payment gateways via SpreedlyCore along with Dwolla and GoCardless integrations that are in-progress. Visit their site if you’re interested in learning more.

Fusebill: An automated billing company based in Canada, Fusebill is a venture funded and experienced team that solves “real world” billing problems. Their customers rely on them to reduce costs, speed cash collections, and extend customer lifecycles. They differentiate themselves by supporting not just credit cards but debit, e-checking, and ACH payments. That makes them appealing to a very wide range of services beyond just web startups. In addition, Fusebill emphasizes their 24/7 in recognition of just how critical billing is to an organisation.

Ecommerce

Zenbilling specializes in the selling of content online online, whether through e-books, online video courses, virtual class rooms, or even offline seminars and workshops. Zenbilling gives you everything in one system, from capturing your potential customers, charging for products, to delivery of contents. You can manage your courses all in one location and then deliver physical, or downloadable, content too.

Cloudswipe is a brand new offering from the team that brought you Cart66. Initially focused on the WordPress platform but with plans to expand to other platforms soon, Cloudswipe is a full service shopping cart for WP customers with a strong emphasis on PCI Compliance – something critically important but not always front of mind in enough ecommerce applications.

So the choices are build the next great payments application on SpreedlyCore or work with one of our existing partners. Let us worry about all the heavy lifting around payments while you zero in on building the true value added component.

Feel free to contact us at sales@spreedlycore.com if you have any questions.

Spreedly vs SpreedlyCore

Posted on October 11, 2012 by Justin

We get this question a lot. Just what is the difference between Spreedly and SpreedlyCore? There are a couple of different ways to answer.

Spreedly is designed as a lightweight, simple, subscription service. It appeals to developers and business development folks who want to have a dedicated subscription service coupled to a payment gateway of their choice. When you visit a webpage with “Choose from one our of 3 to 5 plans!” then there’s a good chance Spreedly could power that. Subscriptions, metering, open invoicing and trial plans. All in one simple service.

SpreedlyCore is a simpler API much more akin to payment gateway API. Customers that pick SpreedlyCore typically have more complex billing requirements such as support for multiple gateways, alternative payment methods to credit cards, currencies, or unique billing cycles/requirements. Core stores your credit cards in a secure vault so that you can charge them for additional transactions if that’s important. Imagine you want to sell an application to sporting stadiums so that their customers can order from the concession stand while sitting in their seat via their mobile phone. Stadium says “Love the idea! Now, we already accept credit cards today via Cybersource. You can support Cybersource right?” Of course, each stadium is different so it’ll help that you support nearly 40 gateways. If you built on top of Core your answer is “You bet!”. Then the stadium owner says “Hey some of the younger kids want to pay with this new service called Dwolla instead of a credit card. Do you know what that is?” Again, you support it.

Now because SpreedlyCore is a super flexible API you can do a lot of things with it. We’ve had customers build their own recurring logic on top of it. We have customers who would rather develop against it vs a legacy gateway API. It can do all those things too. It’s kind of an “up to your imagination” offering. We just want to point out the two most common use cases that we’re trying to solve.

What they both have in common is this. They both reduce your PCI scope dramatically – to just a SAQ-A in most cases. Spreedly does it via a hosted payments page. SpreedlyCore does it via a transparent redirect. The both allow for recurring transactions – it’s just that Spreedly defines when those are (anniversary dates like month and year) while with Core you determine when those are (typically spontaneous repeat purchases but can also be time based) They both store your credit cards away from the payment gateway for independence and flexibility. They both come with (we hope you agree) great documentation, an API and support.