What I wish I knew about Stripe, before I started

Recently, EquipCalendar.com approached me to convert their payment and billing systems from Authorize.NET to Stripe. Now that the task has been completed, I've had some time to reflect on the journey and wonder what I should have known prior to starting the conversion.

First, let me lay some groundwork. EquipCalendar was using Authorize.NET's Customer Information Manager (CIM) and Automated Recurring Billing (ARB) to handle initial sign ups and recurring annual subscription charges. All of this was fine, but for the fact that any notification of an annual subscription failure (think of a credit card no longer active) was handled (almost manually) via an end of day email for transaction(s) status. One of the EquipCalendar staff was required to review the end of day email, identify any problems, get into the administration tools available, contact customers directly and it goes on and on. Clearly, you can see the problem here...to much manual work. Not to mention additional opportunities to muck up the customer relationship even further, even if accidentally.

An additional issue was the added expense of carrying a merchant account ($30 plus fees), plus two subscriptions to Authorize.NET ($20 each for CIM and ARB). EquipCalendar was approaching a 3 year anniversary, which was cause for evaluation of what was working, what was not and what expenses were detracting/subtracting from the bottom line. So, in comes Stripe. Stripe is basically pay as you go (or as you charge) versus the subscription model (i.e. pay whether you charge or not) that Authorize employs.

EquipCalendar also wanted to make one other major change, from an annual subscription model to a monthly one. So, now we have a full todo list: 1) Learn Stripe 2) Modify database, middle tier and user interface to support Stripe and/or monthly details 3) Convert existing customers from annual to monthly, but only on next anniversary date 4) All new signups should be monthly with recurring billing.

A full todo list, but not a complete one, I'm afraid. Where is the part about success or failure of recurring billing transactions that EquipCalendar was complaining about in the initial conversion request? That's right, Stripe reports them via Webhooks. What's a webhook you ask? I could overload you with more acronyms and technobabble, but I won't. I like to think of them as phone calls coming into a central switchboard and switchboard operator. You tell Stripe which phone calls or events you and your software must be notified about (little Charlie took his first baby steps) and my switchboard (i.e. webhooks receiver) will handle the rest, i.e. calling Grandma, posting an update on social media, etc.. Cool right? Except, somebody has gotta build that switchboard and that somebody would be me.

And, the todo list expands....1) Develop a new url or api site that can receive the events/hooks from Stripe. 2) Acknowledge receipt of the Stripe event(s) as quick as possible with a HTTP 200 response 3) Queue event(s) JSON from Stripe using Amazon SQS 4) Build a service to retrieve queued events from Amazon SQS and apply business logic (i.e. notify customer, notify EquipCalendar staff, revise subscription status, etc.). Did you catch that? Not only did our todo list expand, we know have to learn the ins and outs of Amazon SQS and develop an entirely new application/service that didn't exist before.

Software development is not for people who get discouraged easily, don't like learning all of the damn time and are afraid of an obstacle (or 3 or 4).