Unexpected Pitfalls Of SAAS Recurring Payments: It's Hard

"It looks so easy. Slap down a paypal button and be good to go."

"With all these friendly API's with payment processors. You should be delivering a plug and play experience."

"Certainly, setting up recurring monthly plans shouldn't take longer than 2 weeks."

You probably are coming to realize that setting up ecommerce is a lot harder than it looks and it's easy to get estimates wrong.

Your billing software (where your revenue stream lies) can't mess up.

You can lose customers, or worse, piss them off by billing them wrong.

Worst yet is the potential of having a customer experiencing an error, the error not propagating correctly, and not knowing it's happening. These cases can go on for months. Many are surprised to find users will give up at the slightest hiccup in the billing process and may not contact support.

So what do you do? You have to write tests to mock the scenarios, and do the appropriate thing depending on the state of the account, local settings and ecommerce settings.

The funny thing is, maybe you've implemented robust ecommerce solutions before. And you forgot how freaking time consuming it is, even with a rails, django, laravel, wordpress, blahblahblah plugin. No, there's still more work to do. Ugh.

The reality is, you need to allot more time to setting ecommerce up. Heh. It's part of your flow that's too big to fail, and there are a LOT of places it can fail.

Building my own SAAS framework

For about 5 years, I've been dabbling with the idea of building a SAAS framework so I can solve the aches and pains (in python) permanently.

Having integrated a billing system twice over at a startup (first in Node.js, then in Python), I can say that if you don't mock out scenarios like bad tokens, missing remote API objects, and every possiblity that could cause something bad to be spit out, you're inviting hell on yourself.

The problem is, writing out mocks to make braintree/stripe/whatever fail is also painful. So the decision was made on my end to do it all upfront. Cover basically every potential case.

It needs to be reuseable, come with high level, sensible defaults, and if need be, composable, for those custom cases.

Design decisions had to be made to raise exceptions when certain inconsistencies were found, and to handle them. When I deploy this library on a different website, I can either accept the default behavior of the database-copy of information being out of sync with a payment processor, or enter my own custom behavior.

Why we're making SAASKit

SAASKit is my first closed-source offering your startup can license.

It is comprised set of django apps (and some supporting JS and SAAS files)

How SAASkit helps

SAASkit is a django-based starter kit for small businesses and startups (or anything else that would like to bill) that automatically handles creating a parity with payment processors and handling inconsistencies, user experience (registering, subscribing, changing memberships, cancelling memberships, trials, even refunds).

Our first supported payment processor is Stripe.

This saves users a lot of work.

1 year of updates are included. The license is unlimited. The fine print is forthcoming. The price point is forth coming, but it'd cost less than having a freelancer or salaried engineers toil away for weeks rebuilding every time detail and possible user scenario.

Instead, a developer can use saaskit, its templates, and it's API to configure and leverage it. From the business end, getting ecommerce setup faster and correctly helps get you faster to market and avoid snags.

Everybody wins. But you could actually end up saving money too. Because here's what I bet will happen:

Your engineer (or you, if you're the engineer) is going to estimate that subscriptions are easy to setup - underestimating the complications that can arise. 1 or 2 weeks may turn into 3 or 4 weeks. Even longer. Bugs will crop up. The the billing system will end up sucking away time from more urgent matters.

It is backed by optional commercial support plans. That is, python-based websites can also ask of our service to help fix snags with payment processors and work on bulletproofing their systems. That may mean running custom tests to handle billing cases and make sure they're not resulting in failing transactions.

In addition, payment providers may have API's update. We also offer support migrating to newer API versions. We service SAASKit based sites, but also may provide a best-effort service for other libraries and payment processors.

Ecommerce is hard. devel.tech is focused on alleviating the headaches because we've been through them.