#recurly

Modele subskrypcyjne – jak działają i gdzie można je stosować?

Internet, możliwość szybkiego porównania cen, parametrów oraz coraz większy udział e-commercu sprawiają, że firmy poszukują sposobu by zatrzymać klientów na dłużej lub zdobyć klienta, który nie ucieknie do konkurencji po 1 zakupie. Dzięki temu w ciągu paru ostatnich lat widać wzrost liczby firm, które chcą oferować swoje produkty w modelu subskrypcyjnym – klient zamiast za każdym razem…

We at Scruddle are hard at work, continuously building new and deploying new features into the beta site. Currently, our challenge is to identify and implement a Software-as-a-Service (Saas) that handles subscription payments. After all, why spend time building something that other people are (1) already doing, and (2) probably doing better than you can or want to?

The Candidates

I evaluated 4 services, based on suggestions in this article on TechCrunch covering how to build a minimum viable product. They are: 

Chargify (http://chargify.com/)

Recurly (http://recurly.com/)

Spreedly / Pin Payments (https://spreedly.com/)

CheddarGetter (https://cheddargetter.com/)

The Requirements

Scruddle is a freemium service, so when users can sign up, they will have a 1-month trial of Scruddle Premium, but if they choose not to pay for it, they still have access to Scruddle Basic. This means the subscription service will still have record of non-paying customers, making it easy if they decide to upgrade again.

This detail about the non-paying customers is important, especially for any start-up entertaining the freemium pricing model. Based on feedback from other start-ups, only 3% of your customers are going to upgrade to a paid subscription or membership. This means out of 1000 customers, only 30 are going to be paying. We'll use this assumption when calculating costs.

Also, Scruddle Premium subscribers can add additional social, email, and news profiles, beyond the standard quota. The subscription service will need to be able to support those additional features, and handle the billing each month.

Finally, we need to have environments configured for development, beta (testing), and production (live). This enables Scruddle to build for future features while avoiding impact on current customers.

Comparing Cost and "Profit"

When selecting the provider for something as critical as subscription payments, the lifeblood of this start-up, we would be remiss by not forecasting the true cost of each available plan. I used an Excel spreadsheet (download here) to plug in the fine print from each of the subscription providers, based on criteria and assumptions for Scruddle.

Inputs:

Number of non-paying customers

Transaction revenue

The non-paying (NP) customers are using the Scruddle Basic, but as mentioned above, we still carry their information in case they upgrade, or we provide for them another trial. The transaction revenue for Scruddle Premium is $4 per month. This does not include users that add additional social, email, or news profiles, although I will build that out later for a blended monthly transaction price.

Assumptions:

Paid customer count is 3% of NP customer count

For every provider, I needed to capture the cost calculation inputs:

Monthly Fee

Included Customers

Cost Per Additional Customer

Included Non-Paying Customers

Cost Per Non-Paying Customer

% and/or $ Cost Per Transaction

Once the inputs are plugged in, both for Scruddle and for cost calculations, I can calculate the monthly cost, which is:

Add'l Cust. Fee + Add'l NP Cust. Fee + Txn Fee

Once we have the monthly cost, our profit/loss is calculated as:

Gross Revenue - Monthly Cost

That's it! Using these numbers, we can figure out how long before the subscription payment feature no longer costs money. (Obviously, this is not total business P/L, as other expenses and revenue streams are not included.)

Visualizing the Data

It is particularly useful to visualize the data, based on your customer acquisition targets. As you can see, Spreedly, Recurly, and CheddarGetter look very appealing.

Cost:

P/L:

Comparing Features

Now that we understand price, we need to verify features. In Scruddle's case, we need the following:

Multiple top-level sites for our different environments (development, testing, production)

Add-on features, in addition to basic plans (for each site)

How do the candidates fare?

Recurly allows only 1 top-level site, and no add-ons

Spreedly allows multiple top-level sites, but no add-ons

CheddarGetter allows multiple top-level sites, and has add-ons in the form of tracked items (e.g. "usage")

Chargify allows multiple top-level sites, and has add-ons

Whether your start-up has the same requirements may not be important, but this information can be useful. In our case, it seems like Chargify will be the best option, strictly because of the features.

Closing Thoughts

For Scruddle, we have to strike a balance between features and cost. Still, this has been a useful exercise as we map out each and every expense we expect in our forecast. 

If you have any questions or thoughts on how I did this, or if you have suggestions for other subscription payment providers (even start-ups), I'd love to hear about it.

Everyone who developed a web application heard about the so called PCI-compliance. Briefly, it regulates the requirements your application must meet if it deals with billing details. It usually takes several months to go trough the process of approval, thus small and midsize companies prefer using hosted billing solutions. The most popular ones are Chargify, Braintree, Stripe and Recurly. We chose the last one for development of the subscriptions and the billing details submission on one of our current Forex Jingle.

Recurly offers Recurly.js, a great integrated solution that passes billing details directly to the Recurly server. Look at the interaction graph:

The app generates a page that contains a Recurly form.

The customer fills out and submits the form to Recurly directly.

Recurly responds with a token that the app needs for further interaction.

The form posts the token to the app.

We are used to testing things we build thoroughly. Each project has its own specific traits and Forex Jingle is no exception. Let's focus on the Recurly integration testing. Since Recurly.js depends on JavaScript, we have to use a real JavaScript-enabled browser during the tests. This requirement can be satisfied by a pretty standard bunch: RSpec + Capybara + Phantom.js.

As far as the application communicates with Recurly there are several API calls during the subscription process. It would take too much time to perform actual communications in each testing scenario, that is why we use the VCR gem perfect for this case. But look at the figure: there is a crossdomain JSONP-request initiated by the browser, not by the application server where the test suites work, thus these requests cannot be caught by the VCR or similar tools.

The only elegant solution we came up with is on-the-fly Recurly.js patching. After in-depth code review of the well-designed Recurly.js library, it wasn't hard to apply the following patch right before submitting the form:

# The original 'save' function performs JSONP request to Recurly. # A token is borrowed during the real API interaction. page.driver.execute_script("""   Recurly.Subscription.save = function (options) {     Recurly.postResult('/subscription', { token: 'afc58c4895354255a422cc0405a045b0' }, options);   } """)

API v2 and support for multiple subscriptions on a single account. API v2 incorporates feedback we heard from our merchants and allows you to integrate with even more flexibility than ever before. For many customers, multiple subscriptions enables scenarios that were difficult workarounds with our first API.

I love this new crop of payment providers. Recurly (and new kid on the block, Stripe) are both top picks for me.