We're a transparent startup founded by Aviel Ginzburg and Damon Cortesi building solutions in the social media and public relations spaces.

Follow along as we share the ups and downs of building a startup.

Follow Untitled Startup on Twitter
Tweeps Who Like Us
davidhoangdudeman718kevinmarkslouisgrayjoannalordmsaleemshaunacauseysh3n3rdpistachiorsarvereddavemcclure

Accepting Payments on the Real-Time Web

Feb
01
By Damon Cortesi

I just spent the weekend in payments hell researching a number of different recurring billing systems.

Here’s the thing – I build products. Lots of them. And I want to charge for them. I don’t want to have to drive tens of thousands of uniques per month before ads even start to think about paying out. I’m tired of visiting websites and having ads about people’s ugly teeth be the first thing I see. Dave McClure had an interesting, if curse-word-infused, post on the future of subscriptions. The basic gist is that startups have focused on growth and advertising-based revenue models in the past decade and that now we are heading more towards a subscription and transaction-based model.

His spot-on rant is ridiculously close to what I almost ended up posting this morning, and I’m glad I didn’t, as I haven’t quite earned the the respect to swear online like that yet. But here’s how it looks from the ground floor as a developer on a 2-person team that is trying to avoid the CPM/CPC model and instead focus on building useful products that people want to pay for. A crazy concept, I know!

Our Goal — take RowFeeder, which allows somebody to purchase tracking of a specific term on Twitter over a set period of time or on an ongoing (recurring) basis, and charge accordingly. Doesn’t sound too difficult does it?

Let me state our requirements for making this happen:

  • We want to accept payments for Rowfeeder
  • The payment method should be SaaS (hosted by the provider, not on RowFeeder) and PCI compliant
  • Rowfeeder should’t collect (or be responsible for) payment data
  • The payment method must support both one-time purchases and ongoing subscriptions
  • Customers should be able to have multiple subscriptions or be able to purchase multiple quantities of one subscription
  • The payment provider should support notifications of activity (IPN) or have a queryable API tied to a reference ID for the user
  • The Payment provider must provide useful feedback/tracking data (i.e. work with Quickbooks or allow a cvs dump)
  • The solution Rowfeeder implements should be integrated and live in 1-2 days

Now that doesn’t seem too difficult, and we know it’s doable, but our primary requirement was for subscription billing and because of that we looked at several new players in that field (specifically, Spreedly, Recurly, and Chargify) in the hope that they were actually delivering on simplifiying the world of subscriptions.  Not only that, the allure of maintained Ruby gems, restful APIs, and flashy feature-sets made it look like something we could pull off without investing heavily in a Paypal, Google, Amazon, etc solution.

Before I go on, let me quickly thank Nathaniel Talbott of Spreedly, Isaac Hall of Recurly, and David H of Chargify. I’ve been in more or less constant contact with all three companies throughout the weekend(!) and am floored by the level of attention and support as we’ve gone through this process. Also of note is that Recurly just went into public beta in December and Chargify is still in private beta.

Let’s start with Spreedly.

Fantastic solution if all you’re doing is basic subscription billing. Ridiculously easy to integrate and several other nice features including a branded hosted payments page and ongoing HTTP PUSH notifications of subscription status. Unfortunately, one-time payments are not possible, nor are multiple subscriptions (or quantities) of a specific subscription. Another thing to note here, is that we unfortunately dove into Spreedly before performing proper requirements planning, so our opinion of the service is somewhat skewed.

Verdict: Great for simple use cases … like say a subscription to a newsletter or an online magazine … but that’s about it.

Recurly is next.

Also a great solution and offers 90% of what we’re actually looking for. Unfortunately, they don’t have a good solution for one-time payments in combination with hosted payment pages. They also do not support multiple subscriptions, but it is possible to upgrade to different quantities of a specific subscription. So if somebody buys one term on a monthly subscription, we can make use of the API to increase or decrease the number of terms they’re tracking as necessary. However, I ran into a couple errors while working in their sandbox. First, my account was rendered useless when I entered a plan name with a period. Oops. Then, the math on their hosted payments page was subject to an embarrasing front-end bug (2 * 2.49 = 9.96) when you specified a quantity via a URL parameter. From a security and QA perspective, this didn’t instill a lot of confidence, but I will mention that they fixed both of these issues IMMEDIATELY after we notified them. RackSpace may claim fanatical customer support, but these guys deliver on it.

Verdict: An excellent and flexible solution for subscription payments. If they had one-time payments (outside of pre-existing subscriptions), we’d be in.

Finally, we were able to get access to the Chargify closed beta.

For somebody looking for a hosted payments solution, they haven’t put enough effort into that portion of their service yet for it to be viable. While they have put a lot of work into the API … I just want the ability to redirect a customer to a secure, reliable, third-party and PCI-compliant site where I don’t have to worry about taking credit card information myself, but can still get instant notification of the necessary purchases and changes to subscription levels. Unfortunately, the documentation (and the video on their home page) is also out of sync with reality, which was extremely frustrating.  It’s pretty infuriating to actually perform due dilligence only to find out that the documentation is out-of-date after hours of implementation effort. As an example, their documentation states that they support one-time payments, but we didn’t find out until after emailing their support team that this functionality had been disabled temporarily while they re-architect some things. Again, I don’t want to criticize a private beta too much, but this was definitely frustrating.

Verdict: I’m confident that once these folks reach the point of being out of closed beta, they’ll have a great product and (what will be) a complete feature-set that’s going to do very well.

The fact that this is the state of recurring subscription billing isn’t shameful in itself, but it’s truly lamentable how close these services are to being great while clearly falling short in many use cases. Either I’m thinking about this too hard, or I want this to be easier than it can be.  It seems like these companies are focusing too heavily on the “vertical” of subscription services rather than branching out horizontally (even slightly) and becoming robust payment solutions. (Side note: This doesn’t apply to Chargify, and I’m excited to keep an eye on them as they build their dev team!)  It’s a tough economy out there, and plenty of companies are trying out every monetization strategy that they can.  Should they really be forced to go through two different payments providers if they want to offer both subscription and one-time pay solutions, especially if they’re simply using the one-time payments in hopes of upselling to a subscription?

Since the weekend, I’ve been contacted by a number of other subscription billing companies. Of the couple I checked out (Vindicia and Aria Systems), their websites were primarily marketing fluff – white papers, best practice guides and webinars. In order to actually determine their feasibility, I had to fill in a form and have a sales person contact me. This may work for larger corporations, but we’re a startup. Putting up a sales gateway in front of your documentation makes it pretty damn difficult to evaluate the efficacy of your solution. When we’re building products in a matter of hours or days, your 9-5, Monday-Friday attitude is simply not going to be compatible with our workflow. But maybe we’re not your target audience.

All that being said, there’s hope. Spreedly, Recurly, and Chargify are all brand new and all appear to both be listening and care about their  current and potential customers. I don’t doubt that they’ll all get to where I want them to be in the near future, but they’re not quite there yet.

Perhaps useful to other folks is this spreadsheet where we tracked different recurring billing solutions against our requirements. I’d love to hear other people’s experiences with these, or other payment solutions.

  • The10Most
  • We provide Subscription management, Billing & Payment solution on Salesforce.com and here are some key features -

    > Flexible Product Catalogue - Bundle multiple Services, Items, Rates
    > Service Renewal - Auto renewal for any period, create bills automatically on renewal
    > Relationship pricing - Customize the product pricing based on customer's need
    > Discounting - Discount for plans and/or items for any period
    > Subscription change - your customer can add or remove any plan or item any time
    > Order fulfillment - manage fulfillment tasks, create predefined tasks, assign automatically, send alerts using WorkFlow
    > Billing options - anniversary billing, pro-rating, advance billing
    > Metering - metering can be done based on flat or tiered rates
    > Usage data upload - upload usage data automatically daily or monthly
    > Payment options - Credit Card, Check, ACH, Auto payment - charge credit cards automatically and send receipt to client
    > Manage Payment adjustment, disputes, Late fees and Refunds, Collections
    > Auto email - email Invoices automatically to the clients

    For further details check our website http://www.chikpea.com.
  • Steve Phillips
    You could also try PayTrace.com. Sounds like they may fit the needs your are looking for.
  • Damon: Loving the new version of RowFeeder. What billing solution did you end up implementing? I kept scrolling farther down the comments hoping to cut to the chase but was left hanging! Please do tell...
  • Hi Matthew, thanks for the kudos. It's much appreciated, we've put a lot more effort into RowFeeder lately.

    As for billing - we ended up going with Recurly. Truth be told, though, were I to make the choice right now I would likely go with Chargify. They've been charging ahead (pun intended) with new features based on user feedback. Recurly is in a bit of a state of flux right now and it isn't clear what their pricing plan is going to be.
  • Interesting post and dilemma. Something that every startup (& business) must go through...how to get paid; especially in a recurring (or 1x) revenue model. Even the comments provide a lot of additional services to consider. Did you run out of time to evaluate any of the others?
  • Just to update the thread regarding PCI DSS compliance, Spreedly is PCI compliant. Spreedly also offers visibility into its status at http://bit.ly/is-spreedly-pci-compliant. Status is updated after each vulnerability scan (some 35K+ vulnerability checks) performed on the network. As far as I'm aware, Spreedly is the only company in this space providing QSA (Qualified Security Assessor) verification of its PCI compliance status.
  • Good to hear, and with 403 Labs as well. I know a few of the guys that work there, coincidentally enough - good group.

    As far as the others, I believe you're correct in that they are still in the process of obtaining PCI certification. I know one of Recurly and Chargify were already compliant at a lower level and trying to get Level 1 certified, but I can't recall which at the moment.

    Is Spreedly going to be on the list of validated service providers at some point? http://usa.visa.com/merchants/risk_management/cisp_service_providers.html

    Thanks for the update - it's been amazing to see a general lack of understanding around PCI in the startup world.
  • Validation as a Level 1 Service Provider is in the pipeline and will be approached as our transaction volume increases. We've been scanning for quite a while now and our primary hangup in our attestation has been getting our documentation suitable for an audit. We're quite confident in what we've put together in topology, application design and security policy. Nonetheless, we're treating this as a point-in-time measurement and remain committed to improving our posture as Spreedly grows.
  • Ryan Robinson
    Thanks for the post. We are launching a site with similar requirements. You may also want to look into billingcircle.com and subscscriptiondna.com. The services are similar to recurly.com have excellent APIs but some of the same limitations as the other services mentioned.
  • Do also try out www.cannybill.com, the API will soon be out and it also handles web based order forms.

    (PS: Sorry about the double post, I have the wrong blog open!)
  • Damon,

    Just a few weeks ago after our email exchange, Aria Systems announced two new editions - Standard (for startups like yours and your readers) and Enterprise. Our Standard edition is designed for small and medium sized companies that need subscription billing deployed in a matter of hours.

    http://www.ariasystems.com/product/billing_platform_editions/

    Good luck with everything and I look forward to following your progress.

    -Joy Larkin
    Marketing Director, Aria Systems
  • You may want to consider or check out a check payment system, which you can receive payments by email, fax, and phone to name a few. It's a great alternative when you don't want to go through an entire "billing" service.
  • John Dex
    I've looked in depth at Aria Systems, Zuora and Vindicia. Though they are relative newcomers, Zoura impressed me in and is best priced of the three. Vindicia knows payments best and their system seemed the most plug and play. Their customer risk management components are unique and worth looking to as they can save you thousands at scale operations.
  • jakem
    Damon, I see that you're a former PCI QSA. Can I use a credit card service that isn't PCI compliant and on Visa's list [ http://bit.ly/dbKhu ]? I asked on HackerNews [ http://news.ycombinator.com/item?id=1118313 ] but didn't get much of a response. Would you mind joining the discussion?
  • Just followed up there - probably my longest comment ever on HN. ;) This is a confusing topic, so thanks for trying to shed some light on it.
  • jakem
    Thank you for taking the time to respond. I appreciate your advice.
  • Oops CheddarGetter I mean :)
  • GetterCheddar is also a contender, although the lack of Paypal support makes it a no go for me.
  • richard zhou
    Hi Damon,

    I know you are not looking for on premise solution but I have used this open source billing solution called jBilling (http://www.jbilling.com/). It is dual licensed under AGPL and a commercial license. It can do recurring billing with multiple frequency such as monthly, yearly and one time. It has a web based UI for administration (not pretty but your customers won't see it). Other flexible features are integration with a business rule engine (http://jboss.org/drools) for advancing rules such as volume discount, limited time discount. Only downside is that you have to maintain the server itself (java based) and learn its SOAP based API. From 1.5 year of using, I am pretty happy about it and I stop worrying about our billing system.

    As regarding to billing solutions, if it is important to you to get paid by your customers and bill your customers correctly, why outsource to another provider who takes a cut from your transaction ? If they screw up, it won't matter to your customers that you did not cause the problem and they will hold you accountable.

    If you need more information, feel free to contact me. Emiliano is the person behind the project and he is pretty on the ball. He also offers commercial support if you want.
  • Hi Damon, thanks for the interesting write-up. As the subscriptions lead at Social Gold, may I suggest taking a look at our offering as well? Social Gold Subscriptions are in public beta, so you can get started right away. Also you'll find that our range of products is fairly broad, since we started out in payments and virtual currency before adding subscriptions.

    You can try it out by signing up http://jambool.com. Here's a recent blog post about Social Gold Subscriptions: http://blog.jambool.com/index.php/2009/12/22/tapping-into-the-purchasing-decision-through-flexible-subscription-options/
  • I know a couple of people who work at Zuora (http://www.zuora.com/). No idea whether or not they fit your requirements. If you evaluate them, please let us know your Verdict. Thanks! --Alex
  • ahoving
    would like to put PayCheckr on your radar: offering users "many ways to pay" - including cash and non-cash alternative payments (see the model at http://www.PayCheckr.com)
  • Did you look into CheddarGetter (http://cheddargetter.com)? From what I can tell they don't have a "white-label" credit card collection page - you send them credit card data through the API - but they worry about storing the information, so all you have to do is shuttle it over HTTPS and forget about it after that.

    The real advantage is that their billing is very flexible. In addition to the standard real-time payment stuff, they have the ability to charge setup fees and custom one-time charges and credits.

    I'm using them for my project, http://gainstudio.com
  • I wish it were that easy. Unfortunately you can't just slap HTTPS on your site and call it good. When you start accepting credit cards, you have to ensure compliance with the guidelines set forth by the PCI Security Standards Council. And the instant you start touching actual credit card data, your risk (and associated compliance cost and effort) go up. Regardless of who you shuttle off the data to, you're still transmitting credit card data and need to comply with a number of security requirements.

    There's more information on the PCI Self-Assessment Questionnaire here - https://www.pcisecuritystandards.org/saq/instructions_dss.shtml - and SAQ C is available here - https://www.pcisecuritystandards.org/pdfs/pci_saq_c.pdf

    So if you _are_ accepting payments on your site, and you "store, process, or transmit" credit card data, you'll need to fill out SAQ C. Not to mention there's still discrepancy on whether you can achieve PCI compliance on shared hosting platforms (I know that a PCI level 1 merchant can't be compliant on EC2, for example).

    I also question what CheddarGetter's actual level of PCI compliance is. The only reference I can find to this on their website is here - http://support.cheddargetter.com/discussions/questions/39-pci-compliance - and that doesn't seem to actually address all the requirements necessary.
  • Imagine an online exchange that enables contracts to be made between any two parties where agreed amounts of funds could be transferred between them depending upon the outcome of future, but dependent public events. Thus a thousand users of a software package can make a thousand contracts with the developer that they'll pay them a dollar in the event a particular feature is implemented and published.
    Such a mechanism is far more appropriate for the sale of digital work than conventional online payment mechanisms intended for the sale of material goods (shoehorned into the sale of digital copies protected from copying by copyright and/or DRM).
    Such a mechanism is in development, called the Contingency Market.
  • maccman
    I'd use a service like Braintree, and initiate the monthly charge yourself. It may be a bit more code, but it'll give you the flexibility you need.

    If you want an example of that, take a look at Saasy: http://github.com/maccman/saasy
  • Pretty interesting and looks like a nice solution, thanks for sharing. I'd still personally prefer to avoid touching credit card data at all. We'll see what happens - somebody told me yesterday "Let me know if you still feel that way in 2 months", and many others I've talked with have "rolled their own". Reminds me of the days before wordpress. ;)
  • maccman
    The requirements for processing cc data aren't as stringent as storing it. Alternatively, Braintree offer a redirect feature, which means cc information doesn't ever touch your system, but you still have the granular subscription control: http://www.braintreepaymentsolutions.com/pci-dss-compliance/
  • Completely agree on storage vs. transmission. re: their redirect feature, it looks like (from the diagram) you still have to take cc data on your website, but once you pass it off to Braintree you don't have to worry about it.
  • This diagram may make it more clear: http://bit.ly/bGWZMi . The customer's browser submits the form directly to us, and we redirect the customer back to your site. The customer never notices that he/she left your site, and you never have to touch credit card data, even for transmission.
  • Hi Dan - thanks for the detailed info, that helps.

    Disclaimer: I'm a former PCI QSA and likely more paranoid than most.

    That configuration definitely seems like it's toeing the PCI line. There's certainly an argument that cc data is being entered on the merchant's site and they would need to secure those specific systems and fill out a SAQ C. Even if the cc data is being transmitted directly to Braintree, there's still a significant amount of risk on the originating merchant's site. Definitely an interesting approach, though.
  • Hi Damon - merchants that use our redirect api and take web only payments have been qualifying for the SAQ A since the PCI Security Standards Council created the four versions. QSA's typically take issue with the SAQ A qualification initially but to date we've never had a QSA ultimately determine that an SAQ A was not appropriate after further discussion.
  • maccman
    The form on your website goes straight to Braintree, and then redirects back. None of the data gets sent to your servers (although the user adds their cc info on one of your sites pages). You'll probably still have to have SSL on your own pages (so the user feels safe with the padlock).
  • Great review, Damon. My experience has been with Zuora, another provider in the space. We were led to Zuora to leverage their tie-in with SalesForce, but nonetheless use them as our subscription service. Overall, I would rate the service "pretty good".

    The good parts:
    - Supports recurring and one-time subscriptions. Yes, you can create one-time payment structures, but in their records they still appear as a subscription. The charge plan (recurring vs. one-time) is called a Rate Plan.
    - Operational uptime is well managed. They do have maintenance windows where the service goes offline that they plan for, and they'll alert you well ahead of time (1 week or so) so that you might plan accordingly.
    - Flexible structures permit you to concoct your product catalog very flexibly.

    The stuff I don't like:
    - It's very enterprise-y. It doesn't feel as simple as it should, but they are dealing with payment systems. Still, wish it seemed simpler.
    - System upgrades vs. keeping your codebase current. Seems they're on a 1/month release schedule, and the product is getting tweaked quite a bit. That leaves my client code sometimes out of date, and I'm rushing to backload my code against the current service version. They promise backward compatibility, but troubleshooting headaches go down if you're working from the same version of their WSDL as is the current standard.
    - Complexity: a lot of different objects required to interact with the service. SOAP and POST rule the day here. (See prev. note, re: enterprise-y).

    Zuora provides a good service, but you need to be prepared to jump in all the way with them.
  • tientzuo
    Jeff, thanks for the public feedback. Yes we're iterating rapidly based on customer feedback, and while we do maintain backward compatibility in our API's so your integrations don't break as we do releases, I'm hearing that we need to create less change from version to version to keep things simpler for you. Let me send you an email separately, would love our engineering team to hear your feedback.
  • Thanks for including us in your comparison. I'm very sorry that some things are in flux for a couple of weeks and your time was wasted... definitely not the experience we want for anyone.

    As you mentioned, a lot is going on as we grow the team and map out our feature development for 2010. The rough edges are getting smoothed out this week, next week, and beyond. The architecture changes you mentioned are worth it in terms of better supporting our customers' needs as their businesses grow in complexity.

    Managing all the business processes around recurring billing has been way too hard and way too expensive (whether you bought or built something).

    Someone who knows this space and whom I really respect told me last week that 2010 is going to be a great year for this space. I think he's very right.

    --- Lance
  • I agree, 2010 is definitely going to be an interesting year for the payments space. There's a lot of opportunity and I think Chargify is headed in the right direction.

    Despite the setbacks with the documentation, I am happy to see that you're re-architecting now (in the private beta) to address upcoming needs. I've never gotten anything right on the first try and glad to see you're revamping as needed.
  • Thanks for taking a look at us Damon! I agree that we're mostly focused on serving the needs of the medium to large enterprises, but we also work with a lot of companies that are just getting started.

    We have found that many people in need of billing solutions are looking to learn and be educated on the best practices in the industry. Since we have been providing SaaS billing at scale for merchants selling digital goods for several years now, we are in a good position to help those who are looking.

    Also, if you look a little further on the website, you do find the good stuff :) Our API guide is available here - http://www.vindicia.com/pdf/Vindicia_CashBox_API_Reference_Guide.pdf
  • Thanks for pointing out the API documentation. I would definitely urge you to feature that more prominently on your site so interested independent developers and small companies can see what it would take to integrate with your solution as well as the associated fees.
  • reducedjuice
    What a timely post - glad I found it! We've been looking at this exact thing over the past week for my startup (shameless plug - www.betsmartmedia.com) and spent quite a bit of time looking at Spreedly (but haven't yet heard of the other two here. Your reviews of the 3 products are extremely helpful and time-saving for us, so thanks!

    Unrelated but interesting nonetheless is Spreedly's "Kickstart" package... it's a neat strategy employed by the guys there to not only generate interest in their product and reward their early adopters, but as they pointed out in this blog post, a good way to (hopefully) generate some quick cash in lieu of raising capital through more traditional means.

    http://blog.spreedly.com/2009/5/7/the-spreedly-kickstart
  • Working in the billing/finance arena myself, I know this kind of thing is a nightmare.

    It's not helped by the big banks thinking that they own the space and wanting to charge a fortune for a shoddy system. I really hope that someone breaks their stranglehold, and soon.

    The reality is that global differences (legal and cultural) have a huge impact on payment processing and acquirers need to talk with Visa, Mastercard & Amex. Just getting to sit down and chat with those leviathans takes time and money. Visa et al could cut out the banks and provide a simple online payment gateway but that's not (yet) in their interests.

    Good luck to Spreedly, Recurly, and Chargify but I suspect they've got a long, difficult task ahead of them. Big rewards if they can pull it off though!
  • Recurly
    Thanks for the great writeup Damon. As Dave's rant mentioned- there's a huge amount of momentum towards recurring billing (and away from CPC based models)- and we're here to help developers make that transition as easily as possible. We're working on getting the non-subscriber one time transactions feature ready and your feedback was truly helpful- please let us know if there's anything else we can help polish.

    Regardless of the solution you choose, its a great time for developers to be a dev. With the options available today, hopefully you'll be able to save some precious coding time for what matters- working on your own product (and not reinventing the subscription billing wheel). Let us know if we can help!
    Tim
  • freerobby
    Bummer. I have only dealt with the big guys (Paypal, Google). They get the job done, but they're hardly RESTful in either meaning of the word. It's too bad that none of these three provide a turnkey solution just yet.

    I have heard mostly good things about Amazon's FPS, and cscotta wrote a rails plugin for it that might come in handy for you. I haven't used the service or the plugin myself, though. http://github.com/cscotta/aws_fps
  • untitledstartup
    Don't be fooled by our issues, these guys DO solve A LOT of problems. It's just that the breadth of use cases they support isn't quite there yet for our needs.
  • Well said, Damon! I've had to just write our own for now on SocialToo. Hoping these guys deliver soon so we can jump on board. I'm excited to see what you end up going with.
  • The inability to provide one-time charge seems like one of those typical "not-looking-at-it-from-the-customer's-perspective" situations one runs into so many times. This typically happens when you get too wrapped up in a pre-defined product plan.

blog comments powered by Disqus