Usage-based subscriptions in Stripe

I’m evaluating ERPNext and was curious whether the Stripe integration would work with its usage-based subscriptions. In usage based subscriptions, Stripe adds multiple items to the subscription for a client, to be invoiced at an interval such as monthly, and the usage is posted to the subscription as it happens throughout the period. When the period is over, an invoice is created billing for the usage that accrued, using the billing-rate attached to that item.

If I link ERPNext’s subscription support to Stripe and try to use this, will it work?

Hi there,

Can you clarify a bit what you need ERPNext to do? When you say that “usage is posted to the subscription as it happens”, what does that mean specifically? How is usage being tracked, and which service is responsible for tabulating and invoicing?

Frappe has excellent integration interfaces, so the answer to your question is almost certainly “yes”, but we’ll need a bit more detail about the workflow to answer more specifically. I’m only loosely familiar with Stripe, and a quick google search didn’t turn up much for usage-based subscriptions.

I’ll try to clarify. I’m trying to determine whether ERPNext can track “metered usage” in its subscriptions. I’ve tried to set it up and it appears that it can’t but I want to be sure – it looks like a really great system.

For example, let’s say I have an online service which performs certain tasks for users. Let’s say “Task A” and “Task B”. My users sign sign up with a subscription for either Task A, Task B, or both. The “metered rate” for Task A is $5 per “task completed” by the service. For Task B, it’s $15. As my service performs a Task or Task B for each user, it increments the usage for their subscription, which would be tracked in ERPNext. Then, on their invoice date, ERPNext would automatically check the usage for each Task type for the user’s subscription and issue an invoice with the item quantities set to the usage counts. The usage then gets rolled back to 0 for each task and the next billing cycle commences.

This is how Stripe enables metered subscription item tracking in their system. I could probably setup the invoice linking between Stripe and ERPNext without much trouble, but I love the Contracts function of ERPNext and would like it to track the subscriptions as well. I’m just not sure whether the Stripe/ERPNext integration supports the “metered” subscription item.

Frankly, if ERPNext can do it, but the integration doesn’t support it for Stripe, I’d still be interested in dropping Stripe’s subscription and going with ERPNext, so I suppose this is a two part question: 1. Can ERPNext do it? 2. Can it coordinate it with Stripe?

Thanks for any tips you can provide.

Here’s a link to Stripe’s docs on their function:

Actually I just turned up this thread, which makes me think that’s it not supported in ERPNext, but could be implemented with custom coding:

It goes well beyond utilities and printer services. Many SaaS companies are using this model and it’s got huge potential. AWS and Azure are examples of big players who use it.

Again, any pointers, even just to technical docs that might give me a leg up on a custom implementation would be greatly appreciated.

I understand the idea of metered billing, of course. What’s less clear to me is how a systems implement the concept in a formally generic way.

In ERPNext, Subscriptions are just regular invoices issued on a repeating period. It sounds like what you’re looking for is a way to determine invoiced quantities programmatically. That’s certainly possible, though it’s not built-in to subscriptions. If I were trying to implement this, I’d use a custom script. Before submission, poll the remote data source to see how much usage has taken place, then adjust quantities, etc. I can’t think of any reason why that approach wouldn’t work.

The Stripe documentation I linked to seems to explain pretty well the formally generic way they’ve implemented it, in case you’d like to see their approach. I’ll see if I can determine what the “custom script” strategy will provide in ERPNext.

Thanks for the assistance!

Actually, one more question. I just found the Custom Scripts docs here:

They seem to be solely focused on UI adjustments. The Subscription issuance happens automatically according to the periodicity. Do you have any idea for linking custom logic into the back-end operation that creates the invoice itself?

Ah, I think I understand better now. Thank you for the clarification.

There’s nothing like what you’re describing built-in, but setting up what you’re looking for would be relatively straightforward. I don’t think that Stripe’s “tally”-based approach is right for ERPNext, as it creates a redundancy between your metering data and your service period count. If I were in your shoes, I would probably just poll the metering data at the time of invoice creation.

For that, you can ride on the before_submit event, either by overriding the default Sales Invoice controller with a custom app or by using a server script.

Apps have more power and flexibility, but custom scripts are much easier to manage because they can be created directly on your site and don’t require any mucking about in the filesystem. Custom scripts have two types: client scripts (js) which manage UI/browser behavior and server scripts (python) which manage the data model on the backend. As you’ve noticed, client scripts won’t do what you want here.

One limitation: server scripts aren’t allowed to make http requests, so you’ll be able to use them only if your metering data is already in your ERPNext database somewhere. If it’s stored elsewhere, you’ll need to use either an app or a different approach. (They can now!)

If you don’t mind the functional dependency in your data, you can create something very similar to what Stripe does by creating a webhook endpoint using a Server Script exposed as an API. This could then log the data to be consumed later, or it could write directly to the sales invoice if you’ve set it up that way.

In other words, there is no shortage of possible approaches, depending on your preferences and how your metering data is organized.

1 Like