Using Stripe API for Your SaaS Subscription Website
Providing intricate payment gateways is considerably easier using Stripe for subscription-based SaaS websites. Simply put, Stripe provides an API for developing subscription payment systems. This enables people and businesses to process transactions on a recurring basis.
While it is not the only payment gateway solution for subscriptions, it has rapidly become one of the most popular. This is due to its great features and documentation for developers, and easy-to-manage dashboard for businesses. It allows you to easily set up subscriptions, send invoices, and more. It is highly appealing to developers because of its flexible APIs. This helps when modifying it for varied types of transactional situations and integrates well with Apple Pay and Google Pay.
Client Configurations of Stripe API for a SaaS Subscription Business
Example of Stripe API with Elementary Payment Process for Subscription Business
The first example we will examine is Doctors for Accidents. This site is a membership site for servicing accident victims. This site provides accident victims a list of doctors who are willing to work on contingency, and who will provide basic evaluations and bill estimates for pending court cases. The site is searchable by doctor specialty and location.
Revenue on this site is generated by charging doctors for listings, with a fee per clinic listed. In order to handle payment, our client needed to be able to set up subscription plans for doctors, with the option of being able to provide listings for multiple clinics. Stripe doesn’t collect payment until the end of the billing period. Each additional charge for a new clinic needed be applied to the next billing period. When a doctor adds additional clinics to their subscription, the prorated cost of adding a new clinic is not collected until the following billing period.
The default configuration allows 1 plan, 1 price. In some cases, doctors may own multiple clinics, and the rate for a listing is $99/year per clinic.
More specifically, the subscription plan for this site works as such. If on January 1, one clinic is added, and then on January 15 another clinic is added, the charge for the second subscription appears in the next billing period, but with the charge for the second January subscription included. This was relatively easy to configure using the Stripe subscription API, which provides per-seat licensing and allows multiple quantities within a single subscription. In this case, Endertech was able to create a straightforward out of the box, batched monthly subscription. There is only one plan, and there is no pro-rating needed for new plans; each one is charged for the full month for when the subscription appears.
Example of Moderate Level Payment Processing using Stripe for Subscription Business
For the second site, Laundromats for Sale (LFS), provides a directory of (you guessed it) laundromats for sale. Using the case study for LFS, the client did not want to use the default Stripe Subscription API settings, so some modification was necessary.
A seller could list a laundromat and play a flat $29/month, and a seller can list more than 1 laundromat. However, unlike in our first example, the client wanted upgrades (addition of a second laundromat) to be collected immediately, which required custom programming. While Stripe would set the billing for the next period, if quantity is increased, it needed to prorate per month.
This required modifying the Stripe invoice API. We needed to figure out how much should be charged, generate a one-time invoice with a prorated amount for that month, and then return to the normal rate for the next month. Money needed to be collected right away, and not wait to add the prorated amount to the next invoice.
Example Solving Multi-Layered Payment Options using Stripe API for Subscription Business
The third example, citygovjobs.com, required a much more complicated method of billing. This site includes job listings for various positions in public municipalities. On this application, there are two types of users, who each pay for access for different reasons. The first group is job seekers, and the second group represents the human resource departments of city employers.
In this case, the client needed different layers of subscriptions for job seekers, including multiple plans, with different levels of access. A job seeker would pay monthly for access to a specified set of jobs on a month to month basis.
The second level of payment was for charging city employers, which had a few different rates which included, both a month to month rate, and an annual rate. Different levels of privileges need to be assigned depending on the contract. The amount charged is also variable based on the size of the city. Default settings allowed cities or towns to be able to list all jobs. To be able to hide a few specific positions from the public site requires a higher level of access.
The client needed payments to be made immediately upon any changes, but with a complex upgrade logic; all upgrades to an account are prorated based on the amount of time left in the month or year (depending on the plan).
An option also existed to allow cities to downgrade a plan to a lower expense, however the change in the billing cycle would need to wait until the end of the year or month for the change to take place. As a result, the system required making the system flexible enough to handle future subscription changes immediately but make the change of the access to the system later. In other words, proration is also factored into the pricing, but with different mechanisms for upgrades and downgrades.
Customizing Stripe for SaaS Subscription Website
In each of the above circumstances, our Stripe developers had to apply varying levels of custom coding. In some cases, Stripe works well out of the box with its default configurations, however as was demonstrated, there is some variation required for modifying billing to work with an individual site’s plan.
Endertech handled this by building several custom web applications. We worked with the Symfony PHP framework and made use of the Mirovskyi Stripe bundle.
This bundle provided a PHP object-oriented interface for accessing the Stripe API, and included a layer for listening to Stripe web hooks, which other libraries did not include.
Learning to Win with Stripe API Customizations for SaaS Website
When changing subscription plans for a client, we learned that every time a price or frequency of a subscription would change, a new plan needed to be created in Stripe with a new frequency. This provides a useful feature to protect past customers who signed up under a previous plan from suddenly having their rates change without notice. However, as a result, any time that a customer wishes to change frequency or if the cost of a plan is changed, customers must be switched into the new plan.
If a user has a subscription and they wish to make a change to their existing plan, or if the pricing rate of a plan changes, we need to create a brand-new plan and switch the users over to this new plan. The subscription itself could remain stable, but the plan to which the user subscribed would change. We built an interface to allow the client to define the plan, and to create a few rules, to handle various customizable options. When a subscription plan is created, an equivalent plan gets created in Stripe. Stripe only needs the name of the plan, the price, and the frequency. All business rules were handled by our customized application, which included pricing, which in turn is also stored in Stripe.
When we collect payment on a subscription change, we need to create a one-time invoice at the time of the upgrade, or Stripe won’t charge the update until the following period.
In development we also found that it was useful to have multiple Stripe accounts. We did not wish to litter the client account with a large amount of test data, so we needed to create a development environment for listening to Stripe webhooks. We used Ultrahook, which enabled developers to test Stripe hooks for when a computer is protected behind a firewall. Ultrahook uses a tunnel to connect to Stripe.
As a result, we were able to create multiple accounts which include the staging account, the live (client) account, and an deployment account which would update the webhook URLs.
We found that for the purposes of most clients, the Stripe subscription API is a great solution for creating a recurring billing system. Stripe provides excellent developer documentation, and it is very customizable, and is very developer-friendly. Support is easy to find in the Open Source community.
Clients also like Stripe because of its easy to use interface and dashboard for managing accounts. It allows manually setting up subscriptions, sending invoices and more.
Overall, we found few reasons to choose any other platform. The only case where one might wish to use something other than Stripe is if one is a high-volume merchant without much need of customization; in this case the transaction rates would typically be lower using a direct merchant account and Authorize.net. However, compared to other vendors, Stripe is particularly strong quite simply because of its pure flexibility, which made it possible for us to make all of the needed customization for all of the above client types.