Spreedly Blog

Security Update: The Heartbleed Bug

A vulnerability known as The Heartbleed Bug was discovered in recent versions of OpenSSL. You may already be aware that this library is used by a substantial number of services on the Internet. We use it at Spreedly. We’re happy to report that we have deployed the changes necessary to mitigate the vulnerability.

We have taken the precautionary step of deleting all browser sessions. We want to recommend that you consider taking the following steps:

  1. Reset your Spreedly password.
  2. Generate new Access Secrets. These are used by your applications to connect to our service.
  3. Generate a new Signing Secret. These are used by Spreedly to sign requests made to your servers when working with offsite gateways.

If you need assistance, please contact us at support@spreedly.com.

Thank you for using Spreedly!

Visual: Credit card success and decline rates changing over time

In September 2013 we launched the payment gateway index (PGI) with help from Shopify. 

Each month since we’ve updated the page to present the latest data on a static page. Over time we saw large changes for some gateways.  Some large enough to make us question whether we had broken something on our end. Yet customer’s confirmed via conversations with their gateways that fraud filters at times were turned too high and were subsequently adjusted.

So we created a view that showed changes over time. In fact, we created a couple of different views. Today we’re announcing PGI “Labs” to allow you to explore the data and watch change over time. For Spreedly customers we’re going to look to ways where we can start giving you more “real time” notifications – most likely in the second half of the year. You could then engage your payment gateway in real time and/or route traffic through another payment gateway until the situation settles down.

We hope you find it valuable. We’ve just updated it with the most recent data from March 2014.


JSON and JSONP Support

Spreedly has just made support for JSONP publicly available for adding payment methods. While we have had support for CORS for some time now, the addition of JSONP improves options for developers.

The transparent redirect is still a great places to get started for adding payment methods with Spreedly. It is a simple form that doesn’t require any custom client side code. However your needs may be more advanced. For example, you may have a single page app that needs to remain active so you don’t want a page refresh. CORS and JSONP can give you that flexibility by using JavaScript’s asynchronous request capabilities.

We’ve also updated our documentation for CORS to use JSON as the data type rather than XML since it is the natural choice for web and mobile apps. Rest assured that XML will remain fully supported.

If you choose to do mobile development in a native language with a networking library, you can choose to use our consumer API to add payment methods. It is an endpoint that is friendly to JSON that you can work with directly for creating payment method tokens.

With all of these options to choose from, it can take a little bit of analysis to choose which one is best for your needs. Our adding payment methods page outlines the different options and assists you in making a decision.

SAQ-A-EP: A big shakeup for online merchants

The new PCI DSS 3.0 Self Assessment Questionnaires (SAQ) were released recently but will not go into effect until January 2015. However, as the new requirements stand, the impact for merchants transacting online seems to be potentially very significant.

Up until now, many payment gateways (or PSP’s) have offered a hosted payment page for smaller merchants. In return for using a hosted payment page the merchant was only required to complete a SAQ-A (about 13 questions in length). It now looks like merchants who use hosted payment pages will be required to fill out a SAQ-A-EP. This is 139 questions long or 10x the length of the old form! It looks like there will be more than 100+ technical controls for any merchant to validate. They’ll also have to do a quarterly scan and an annual penetration test against their site. For smaller merchants that’s a significant jump in both time and cost.

To be clear, this applies to merchant who host (or use a third party) to host their site and then hand their customers off to a hosted payment page (HPP) for completion of the order. What the PCI SSC is effectively saying here is that bad guys can take over that hosted site and redirect the HPP to a location of their choosing and therefore capture the card details. So your hosted site is really *in* scope. At the very least, it needs to be more secure than a SAQ-A requires.

It should be stressed that it is still early in the adoption process and the new requirement won’t be enforced until January 2015. There is still the possibility that the PCI SSC will tone down it’s approach over the course of the year and the final requirement could be significantly different to the current proposal. However, *assuming* it doesn’t change significantly there are going to be some clear winners and losers:


i) The scanning companies. There are  literally millions of merchants that will now need quarterly scans and annual penetration tests

ii) Completely hosted platforms: thinking of hosting your own Magento instance on Heroku or using Shopify? We suspect that Shopify now becomes much more compelling due to the fact that the entire store is in their PCI compliant environment. That’s most likely still a SAQ-A for the merchant. Hosting your own instance of Magento (or any other shopping cart) on Heroku will require the SAQ-A-EP.


i) Cloud billing and booking platforms that themselves are not PCI compliant and have relied on hosted payment pages from PSP’s/payment gateways to “offload” PCI compliance. If your competitor is fully PCI compliant they’re going to drive home the message that merchants using your platform need a SAQ-A-EP while merchants on their platform need the simple SAQ-A

ii) Per the above any SaaS service that is in itself not PCI compliant will be at a competitive disadvantage to those that are. Imagine Heroku vs raw AWS where the latter environment is already PCI compliant.

At the highest level, it appears that the PCI SCC is trying to close a loophole – they probably never envisioned so many merchants being able to use HPP’s and thus only needing a SAQ-A.  Clearly they want these merchants to have a much better understanding of what is required to ensure they have a secure site and as part of that are mandating checks by an outside third party on a regular basis. However, this is a significant change that affects a very wide audience. It’s hard to comprehend what will happen if/when this comes into contact with the real world and how many merchants will be adequately prepared for the heightened compliance requirements.

The next few months will be interesting. Like many, we’ll be waiting to hear more as the situation evolves.


Credit Card Vaulting: Direct Merchants vs Cloud Platforms

Modern payment gateways allow you to tokenize a card and stay outside of PCI compliance scope. Spreedly is unique in that we allow you to tokenize the card and then pass the underlying PAN to the payment gateway of your choice. The card never gets locked in or tokenized at any one particular gateway.

Why not just try and use a single global payment gateway? Great question. If you can, you should. For one, you’ll save on Spreedly’s fees. However, if you want to benefit from in-country transactions which are generally superior to cross border, then Spreedly can be a great choice.  There’s a couple of reasons why you might want to consider this approach:  decline rates tend to be lower within a country and processing costs are also much often lower. It also provides you with the additional benefit of being able to easily charge customers in their local currency and manage foreign exchange and remittance challenges separate from the payment gateway – this is an area where gateways tend to be feature-lite and fall outside their core area of expertise.

Spreedly customers such as Cabify initially collect and store a card from their customer and run that payment information against a Spanish payment gateway when that person orders a black car locally. But when that customer gets off the plane in Mexico and takes a car to their hotel, Spreedly gives Cabify the ability to then also run that same card against a Mexican payment gateway with no additional information or action required on the customer’s part.  The process is seamless and provides a superior customer experience, while also significantly lowering the processing cost incurred by Cabify by eliminating the need for a cross-border transaction (which tend to be riskier and incur higher decline rates).

From an App/developer perspective, Cabify has a single point of integration and one secure location for all their data. That doesn’t change whether they’re supporting 2 countries or 20.  From the business side, they can quickly add a new payment gateway when they enter a new region. If the gateway doesn’t perform as expected, or after being in the country for a while they realize there is a better option, they can easily switch. This dramatically reduces due diligence when selecting your payment gateway.

Cloud Billing/Booking platforms

Let’s say you come at the market from a slightly different angle. You have a mobile app that allows customers to quickly and easily book a taxi. So you want to securely store that card, get a token and stay out of PCI compliance scope. However, in your model you pass the final charge through to the participating taxi company. In this model, you have the payment gateway credentials for each taxi company set up in Spreedly. Now you’re passing the final charge against the payment gateway of the particular taxi they booked. Here again you want the retain that card and never have it locked in to a gateway. However, you also want to work with a range of payment gateways. Yaxi is a Spreedly customer doing exactly that right now, but we have many others doing something similar.

Another interesting mobile example is BusBud. They take the hard work out of booking a bus ticket by integrating with multiple bus companies behind the scenes. So they go out and buy the segments against the different payment gateways for their participating bus company partners.  Now, we have some really cool things planned for bus and other travel companies that will expose a booking API rather than being limited to solely transact against a payment gateway as is currently the case. But more on that soon – we’re still in beta.

Now you can see why we talk about creating a Stripe/Braintree type experience but *across* multiple payment gateways. You know who you are and now you know that we’re here for you – we love hearing about new user cases we haven’t even thought of yet!






Introducing the Spreedly Changelog

One of the many benefits of using a managed service is that new functionality, updates, and bug fixes are deployed without your involvement. The flipside is that it can appear, at times, to be a bit of a black box with changes going into production without your awareness. We understand your business relies on its ability to process payments and benefits from an awareness of changes to the Spreedly service. Starting today, any and all such changes will be documented in the new Spreedly Changelog.

The Spreedly Changelog documents functionality changes that are:

  • Externally-facing: noticeable to users of Spreedly
  • Generally available: available to all users of Spreedly and not in closed testing or limited release
  • Part of the Spreedly service: new and updated product features, not changes in documentation or marketing-related changes

We hope the Changelog gives you visibility into the changes we make on your behalf on an almost daily basis, and increases your confidence in our ability to maintain and operate a service on which your business relies.

Mexican payments and “Why Spreedly”

Today we added Mexican payment gateway OpenPay to our list of supported gateways. Last month we announced that another Mexican payment gateway,  Conekta.io, had joined the Payment Gateway Index page. If we include Cybersource, we are now up to five supported payment gateways for Mexico. That’s some pretty exciting change and innovation happening for Mexican payments over the last year or so. (Full disclosure: Conekta.io is also a Spreedly customer)

Why Spreedly?

We have Spreedly customers who have launched their services in Mexico over the last year. For a range of reasons they’ve concluded that their initial payments selection isn’t the right long term answer. Pre-Spreedly, switching payment providers is substantially harder to execute thus increasing the amount of friction required to make a change. With Spreedly there are no API changes and no begging for your cards to be returned. I can tell you it feels good to help customers grow faster by reducing payment friction. And I enjoy watching payment providers compete and win based on the providing the most complete services vs via archaic “lock in” business practices.

Is Spain next?

Spain is typically number 6 or 7 on our monthly list of which countries visitors are from. There’s a lot of really interesting startup activity including Spreedly customer’s Cabify and Bidaway. Yet up until very recently the local payment providers have been “challenging” to work with. We’re excited by the overall change in the payments landscape in  Spain. In particular we look forward to helping Pagantis launch over the weeks and months ahead. We encourage our Spanish customers and prospects to take a closer look.

Where’s Brazil?

Mexico’s advancement has us continuing to scratch our head on Brazil. Brazilians continue to express frustration about the lack of payment support in their country (check out this thread on Shopify as one example). It’s difficult for us to know, and unfair for us to judge, from so far away. Still, we’d love to see someone do for Brazil what is happening in many other regions of the world. As Pin Payments, Conekta.io and others show Spreedly can be a critical building block in helping advance that cause.


Payment Gateway Index for January

Hi everyone,

We’ve added January data for our Payment Gateway Index. A couple of interesting observations:

  1. Conekta, a payment gateway startup from Mexico, shows up for the first time.
  2. We wondered if processing speeds would be better compared to December (where gateways are under full holiday season load), but surprisingly we didn’t see much change across most of the gateways we track.
  3. Oddly though, despite the increased December volumes, a number of the larger gateways actually performed better in processing speed performance over the holiday period than they did in January but also experienced the biggest month-to-month swings in success and failure rates.

As always, enjoy the data and please share it amongst your contacts.

Thanks again to Shopify for pooling their data with us.




Did Balanced just (inadvertently?) kick off a price war with Stripe?

Balanced Payments recently made public its volume pricing schedule.  This open display of pricing transparency may simply be a blip on the radar in the competitive world of online payment gateways, or it could signal the end of a very short period where pricing wasn’t the dominant factor behind a processor decision.  Whatever the impact, the move by Balanced was an interesting one that should be of interest to all payment gateway users.

Before we dive into the potential implications of Balanced’s announcement some background/context might be useful.   Accepting credit cards requires having a merchant account. That used to be a laborious process involving a painful back-and-forth with risk averse compliance teams who loved nothing more than drowning potential customers in a sea of paperwork that took days (and sometimes expensive lawyers) to review.   Assuming you could decipher the documents, you then had the privilege of deep dives into your company financials that would lead (if you were lucky) to multi-page pricing tables.  Needless to say, the process was pretty oppressive for a regular business and outright intimidating to a startup (and humiliating when you were rejected for…….well……having no history!).  Add to that horribly complex API’s and bad documentation. It was ripe for change.

Then PayPal came along and assumed the role of industry trailblazer.  It created a seamless process where companies could sign up for a payment gateway and merchant account at the same time. However, a complete lack of competition for early stage companies led to a predictable outcome. Poor API’s and documentation, as well as a reputation for very poor service. Enter Braintree with (for a very long time) a classic bootstrapper model.  It published great documentation and offered support on the front of an OEM’ed payment gateway. It’s approach was simple: treat developers with respect and have clear pricing.  Braintree quickly became the default choice for many startups and experienced rapid growth as a result.

Yet there were still holes in the Braintree experience. You had to apply for a merchant account independent of the gateway sign-up process. It tried to make it as clear as possible but it was time consuming and rejection was a distinct possibility. Then Stripe came along and changed the game.  It offered almost immediate on boarding together with super simple and transparent pricing. Add an amazing API and documentation and the results were predictable; developers swarmed to Stripe as their go to platform for online payments.

Stripe’s pricing was brilliant for a multitude of reasons.  It was very easy to understand and did away with set monthly fees – for the first time you had the option to pay-as-you-go. It included all card types (AMEX is the most common example of something that is typically priced much higher but there’s a whole range of other ‘reward’ cards).   Perhaps most importantly though, it was 100% transparent with prices published in plain site on the Stripe website.  It didn’t require (or help!) if you knew the ins and outs of how rates are determined. If your developer friend was using Stripe you knew he was paying the same amount for processing as you were. At some point there was a vague small asterisk about huge volumes and better pricing but you had to look hard for it.  Looking back, it’s hard to believe just how revolutionary the Stripe pricing model was at the time.

Stripe’s published pricing, however, starts to become expensive once your volume reaches scale. PayPal for example will drop your processing rate from 2.9% to 2.5% as soon as you pass just $3,000 in monthly sales. They’ll drop you again to 2.2% at just $10,000 per month (although there is still that pesky fixed monthly fee).  So why did Stripe flourish? I think for three reasons.

First, the financial relationship it was proposing was very clear to it’s target audience. It was along the lines of: “we (Stripe) have done a *lot* of work to make life easier for you. Immediate onboarding and short development times. Smart, responsive support if you need it. The sort of thing that can save you hours and hours of time on your side and/or help you get to market faster (monetizing more quickly). In return, we’re going to charge you a premium over other providers for that extra value we provide.” It was brilliant in that that you didn’t start paying for that premium *until* you were actually really capturing revenue. Developers understood the value proposition. As Apple has shown, developers don’t mind paying a premium for excellent engineering and design.

Which leads to the second reason they flourished. “Expensive” is a relative term. Software and SaaS services are margin rich. At scale they should be 70 – 90% margin businesses. So Stripe is arguably 0.5% or 0.8% more than PayPal based on list prices when you’re doing $1 million per year. It’s not very hard to tweak a support process to capture those type of operational efficiencies. It’s not hard to tweak your trial/onboarding process to capture that in incremental revenue. It’s also quite possible that the good things Stripe does actually become the reason you can capture that additional revenue. Someone trying to sell/re-sell hardware online in a super competitive market and are making 5 – 8% margins might balk at Stripe. Many developers though aren’t looking at that scenario and can justify paying for a premium service.

The power of Stripe’s pricing is most evident in the market reaction. All the newer companies that followed adopted 2.9% and 30 cents. Even the market incumbent Braintree threw up their hands and adopted the same process. Most importantly though, everyone *matched* Stripe. No one launched after Stripe and tried to use a lower price to capture market share.

(That’s the third reason I think Stripe flourished. Everyone in traditional payment companies thought no one would pay those high rates. They just keep waiting and waiting…..)

The challenge Stripe faces is that their success is ultimately replicable. The model is clear and transparent to all users. Immediate onboarding, great API’s, good documentation and wonderful support.  The problem is the early mover advantage that Stripe has with newer entrants having zero or much less brand equity than Stripe.  So being “the same as” Stripe won’t cut it. They need to look for ways to differentiate themselves within the market.

Balanced did exactly that by focusing in on marketplaces within payments. That seems to have been a wise decision. One way to gauge their traction was that Stripe and others responded within 12 months or so by enhancing their own marketplace functionality and story. The problem is that you are again getting driven towards parity from a features and functionality perspective. The more that happens, the more price comes into play.  So far that hasn’t been an issue because all advertised pricing was/is the same. But then Balanced just published volume pricing.

Whenever someone publishes volume pricing it tells buyers the following: “we can make money at these prices or else we would not be publishing them”.  Many folks take volume pricing at face value. Others, however, see them as little more than an initial opening in a two-way negotiation process. Unless Balanced has an absolute no negotiation policy in place, people who are at say 70% or more within a tier are going to push hard to get the next tier rate. This will erode a cornerstone of the new pricing; a critical sense of fairness.

Secondly, it opens up conversations around what *drives* pricing. Stripe’s initial response is that it can, and in fact does, do better than Balanced’s published pricing but needs to understand your account specifics to develop a competitive package (including things like card mix and debit options etc).  Customer’s now face the following dilemma:  they either become experts in credit card processing so that they can engage in the process and obtain the best pricing/product package, or they choose not to and accept that will likely end up paying higher rates because they can’t or won’t take the time to understand their mix and do what they can to optimize that mix.

If this all sounds familiar, it’s because it is.  We’ve starting to come full circle to the point where today’s payment gateway customers have to review, understand and optimize their payment data to ensure that they’re getting the best price.  Sure, the documentation and sign-up experience should be much more user friendly than the early days, but to be a savvy customer requires research and a solid knowledge of the current payments landscape.

The next few months strike me as potentially fascinating. Stripe has the “Amazon or Apple” question to answer. Do you use brand/market reach to drive down prices so hard that you make it unattractive to incumbents and newer entrants to compete for your developer audience? Unfortunately interchange puts a hard floor below all providers so that approach really wouldn’t work. Do you continue to charge a premium relative to others based on the perceived or real superiority or your offering? Or perhaps you go in a completely different direction with a payment type like PayPal or become the payments network a la the Shopify agreement. Whether deliberate or inadvertent, I believe Balanced’s move signals the gloves coming off (or at the very least, unlaced) in the fight to attract start-ups with aggressive pricing tactics.

At Spreedly we think it’s a great reason to retain independence and options for your customer base. After all, that is one of the reasons we do what we do.

Payment Gateway is down on your busiest day? Just keep processing…..

Here’s a great story from a Spreedly customer. Show Grounds is focused in on the equestrian market. One of the things they do is help Equestrian centers more effectively bill their customers. They awoke early Sunday morning, often the busiest day for equestrian centers, to discover one of their largest customers couldn’t accept payments. Their payment gateway was down and not responding. Enter Spreedly + a 10 minute sign up for Stripe and a six figure day was saved. You can read the full blog post over at their site. 

Show Grounds and our other platform customers invest in payments by integrating to Spreedly. Ask your third party site to handle your billing if you can switch payment gateways in 10 minutes without impacting how your cards are stored or your application works. The answer is yes if they’re running on Spreedly.


Payment Gateway Index December

We just updated the payment gateway index with December data from Spreedly and Shopify. That’s our 4th month of data and there are some interesting trends evolving.

We created the payment gateway index because failed transactions vary so dramatically on a gateway by gateway basis. Yet no data was out there to help merchants with their decisions. We explain our thinking in more depth here if you’re interested.

The data we share is solely from Spreedly and Shopify. It’s a decent size pool to draw from but it is a limited pool. You should keep that in mind when reviewing the data. For example Shopify in particular does a lot of one time transactions vs recurring or subscription transactions. Recurring transactions tend to have a much higher success rate (based on the fact that the original one went through successfully and there were no issues) The more global a payment gateway the greater the chance that they’re doing cross border transactions.Cross border transactions tend to have a higher failure rate (fraud filters) than in country transactions.

We enjoy your feedback so keep it coming and we hope you find the data useful.



SaaS Billing Platforms: Which gateways should you support?

Spreedly is focused on two markets:

i) Direct merchants and FinTech startups that love using the vault and working with a handful of gateways.

ii) SaaS based services that include allowing their customers to do billing online – primarily via credit cards.

If you’re in the second group you know how important it is to support a diverse customer base and their existing gateways if you want to maximize market reach/traction.

We provide support for over fifty different gateways. However not all of our customers in the second group wish to start out supporting all fifty. Thus we are often asked “What are the most important gateways for me to support at launch?” We pulled some of our data to help make this decision. This list is probably most beneficial for English speaking SMB focused SaaS solutions.

First Data Source: The Payment Gateway Index

The Payment Gateway Index is something we jointly launched with Shopify’s help (you can read more here if you’re interested). It’s focused on that murkiest of areas; credit card decline rates. For our purposes here we focused solely on web visitor traffic data as a proxy for market interest in gateways. Here’s a list of the top 10 gateway’s that visitors to the gateway index drill down on:


The next source of data is Spreedly’s own technical documentation. We have an individual page for each gateway we support. Here are the ten most popular pages over the last few months.


For our third and final data point we looked at our production data for the year (since March when we launched into production). Given the time it takes for people to implement you would expect this data to trail the other data a little so keep that in mind.


Finally, we added in anecdotal information to come up with our final “must have” list. This data included newer gateways that are attracting a lot of interest. We also bumped down a little gateways that we know are difficult to work with and/or have poor support. We’ve seen first hand the amount of time lost for one customer on a problematic gateway. So here is our Top 10 list for launching an English speaking SaaS service targeting SMB customer’s who will process credit card transactions within your service.

1. PayPal

2. Braintree

3. Stripe

4. Authorize.Net

5. SagePay

6. PayMill

7. WorldPay

8. DPS/Payment Express

9. Pin Payments

10. Wirecard

An honorable mention is due Balancedpayments.com and eWay.

I hope that helps. We’ll revisit periodically to see if there are substantial changes.




Digital Subscriptions: Roll your own or a third party?

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:

  1. Simple recurring only needs with no real possibility of getting more complex
  2. Relatively simple subscription plans today with the probability of more complexity over time
  3. 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?

  1. 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.
  2. 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.
  3. 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.


Braintree Payments: A port in the storm

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.



How well does your Payment Gateway perform?

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.



Why Spreedly?

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?

  1. 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
  2. A way to store credit card data for additional/repeat/recurring charges
  3. An API and documentation that your developers will enjoy vs curse
  4. 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.





Braintree, TaskRabbit and the future of marketplaces

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.


New Spreedly Gem

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!

Storming the JavaScript Castle

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.

Up to now, we have not allowed cross-origin requests using JavaScript in a browser, preferring the arguably simpler and more reliable transparent redirect. This has never meant we do not see the power of JavaScript. However, once JavaScript is introduced on a page, the number of concerns increases along with the likelihood of failure, such as errors in client-side code and unsupported browsers. However, as we have seen our customer base grow, we have seen the demand for JavaScript solutions grow, too. The first step we’ve taken is to lay the groundwork for a number of JavaScript solutions we’re working on for our customers.

Three calls are open right now using CORS requests (Cross Origin Resource Sharing):

POST /v1/gateways.xml
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.

POST /v1/payment_methods.xml
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.

POST /v1/payment_methods/:token/recache.xml
If you are adding payment methods with JavaScript, you may need the complementary ability to re-cache sensitive information, such as the CVV number.

If you’re wondering about JSONP, I want to tell you we chose to focus on CORS first because we intend to support modern approaches as well as solutions which are designed to work around old browsers. Adding CORS support has allowed us to focus on the JavaScript tools we’re building before worrying too much about old browsers. Keep an eye out for JSONP support, as we do understand it is very important since every person who wants to pay you is an important customer, no matter how old their browser may be!

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.

Happy coding!