If you’re like me, though, you’ll then wonder how to properly integrate the Recurly.js form into your app.
In this post I’m documenting the 3 different types of integration I could think of, so far.
Collecting billing information at the end of trial
In this setup you require payment information once the trial is over only.
- you can probably get away with no CSS customization at all without giving the impression of a badly integrated form (since the payment details are requested much later, the look won’t feel too much off)
- postponing billing information collection means (at least in my experience) more support and less engaged users
Collecting billing information upfront (two-step workflow)
This is the workflow I ended up implementing for WiseCash: a good middle-ground in my opinion.
In the first step, you will present your app signup form then create a user record in your database with login/password (which you will mark as “not yet activated”).
In the second step, you will show the Recurly.js form to collect the billing information, then mark the user as activated when the Recurly callback is called, in order to let the new user actually use the app.
Currently, I’m just redirecting the subscriber to the second step until I have the payment details properly collected.
- upfront payment details collection, yay!
- with a bit of CSS, it looks nicely integrated (more into an upcoming post)
- the visitor can left at step 2 and you will then have a zombie account created in that case, so you’ll probably want to set up a cron job to delete those after some time
Collecting billing information upfront (single-step workflow)
This implementation is probably the state-of-the-art right now.
I found one instance of that technique on CageApp: if you look at the page it looks like there is a single form to fill, including application-related fields and billing info in one place.
What happens is that there are AJAX calls to verify email unicity as the user types, as well as a hook into Recurly.js form to cancel the form submission if the app data is not valid, and another hook to actually create the app-side account once Recurly.js returns that the subscription was created properly.
It really mimics a single transaction where there are actually two different servers here.
- very likely to have a better conversion rate
- more complex to implement: requires hacking the Recurly.js form behaviour quite a bit
Although I picked the two-step workflow to get started, I will very likely move to the single-step workflow in the future to improve conversions.
What’s next in this series?
PS: thanks for sharing this article around!