Multiple Stripe Developer Solutions for a SaaS Platform Subscription Business

Excitement of Stripe API for a SaaS Subscription Websites & Stripe Developers

Providing intricate payment gateways is considerably easier using Stripe for subscription-based SaaS websites. Simply put, a Stripe developer can leverage the flexibility the API provides 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 Stripe developer elements and documentation for developers, plus, the easy-to-manage dashboard for businesses. It allows you to easily set up subscriptions, send invoices, and more. It is highly appealing to developers or a software development company because of its API permissions. This helps when modifying it for varied types of transactional situations and integrates well with Apple Pay and Google Pay.

In this article we will review how Endertech’s Stripe developers have used Stripe to fulfill the needs of several different subscription based SaaS businesses. For this purpose, we’ll use three case studies to demonstrate the flexibility and what’s achievable through manipulation of the Stripe framework. Maybe, one of these examples is the answer you’ve been looking for.

Stripe Developer Configurations of Stripe API for SaaS Subscription Business

Example of Stripe API with Elementary Payment Process for Subscription Business

The look at our first example: Doctors for Accidents.

This 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.

The revenue on this site is generated by charging doctors for listings, with a fee for each 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 wouldn’t apply until the following month. Now, when a doctor adds additional clinics to their subscription, the prorated cost of adding a new clinic isn’t collected until the following bill is due.

With Stripe, the default configuration allows 1 plan, 1 price. In some cases, doctors may own multiple clinics, and obviously is more expensive than their $99/yearly fee.

Let’s show an example how Stripe payment subscription plan works for this site. If on January 1st, one clinic is added and charged, then on January 15 another clinic is added, the charge for the second subscription only appears until the next billing period, now with both subscription charges 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, batched monthly subscription cost for users. There is only one plan with multiple clinics, and there is no pro-rating needed for entirely new plans; each plan is charged for the full month of 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, and with Stripe developer support, it was possible.

On the site, a seller can list a laundromat and pay a flat $29/month, with the ability to add more than one laundromat under the same account. However, unlike in our first example, the client wanted upgrades (the addition of a more laundromats) to be collected immediately instead of the next bill cycle, which required custom Stripe developer programming. While Stripe would set the billing for the next period at the normal rate, if listings were added before a new billing period began, it needed to prorate the cost per month.

This required customizing the Stripe invoice API. To do this, we implemented code to find how much should be charged regularly, then generate a one-time invoice with a prorated amount for that month, and finally return to the normal rate the next month. Reason? Money needed to be collected instantly, without waiting 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 Stripe payment billing. This site includes job listings for various positions in public municipalities. On this application, there are two types of users who pay for access for different reasons. The first group are job seekers, and the second group represents human resource departments of city employers.

In this case, the first level of clients needed different layers of subscriptions as 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 that included, both a month to month rate, and an annual rate. Different levels of privileges need to be assigned as well, depending on the contract. Even further, the amount charged also varies based on population size for each city. Default settings allowed cities or towns to be able to list all jobs. But also be able to hide specific positions from the public site, requiring a higher level of access for this capability.

The client asked for Stripe 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 a monthly or yearly plan).

And, there’s more. An option also existed for allowing cities to downgrade a plan at a lower rate (and less features), 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 mentioned, this is more complex than the average Stripe development account.

As a result, the online payment system required making Stripe flexible enough to handle future subscription changes immediately, but make user-access changes to their account later. In short summary for this client, a prorate price is factored into the pricing, while maintaining the different levels for upgrades and downgrades.

Customizing Stripe for SaaS Websites, a Stripe Developer Approach

In each of our examples, a dedicated Stripe developer had to apply varying levels of custom coding. In some cases, Stripe works well out of the box with its default configurations, however, as demonstrated, there is some variation required for modifying billing to work with a site’s custom billing plans mostly found in a SaaS website.

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 Stripe developer 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; this 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.

Stripe

We found for the purposes of most clients, the Stripe subscription API is a great solution for creating a recurring billing system. Stripe provides detailed developer documentation, and it’s very customizable, plus 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 for future changes to payment models. This freedom made it possible for us to make all of the needed customizations for all of the above client types.