Does Stripe use Stripe Billing to bill its customers?

Stripe is unarguably one of the most successful fintechs on the planet:

“Millions of companies of all sizes – from startups to Fortune 500s – use Stripe’s software and APIs to accept payments, send payouts, and manage their businesses online.”

Stripe, on the homepage of its website

However, we were wondering: if we wanted to reproduce Stripe’s pricing using Stripe Billing, how would it work?

‍

Context and disclaimer (skip if you’re familiar with Lago and Stripe)

For context, Stripe has 21 products. The best known is Stripe Payments (for payment processing). One of their products is Stripe Billing, which helps calculate how much money each user owes and manage subscriptions. In other words, it’s the product used to implement pricing. Once Stripe Billing has calculated how much each customer owes the merchant, it triggers a payment, which is processed by Stripe Payments.

Also, as a disclaimer, we’re building Lago: an open-source billing API for product-led SaaS. We were told recently: “We love your ‘Stripe hate’ content”. While it was intended as a compliment, ‘Stripe hate’ has never been our intention. We partner with Stripe Payments and love their products. Our own product is an alternative to Stripe Billing (and Chargebee, Recurly, etc.) but with a deep focus on B2B and product-led companies. We actually have common investors on our cap table (e.g. Y Combinator and others).

B2B payments and billing are very specific, and this market is big, therefore there will be ‘verticalized’ players. For example, Stripe invested in another YC fintech that processes payments for B2B SaaS, called Balance (they use Stripe Payments behind the scenes).

We want to explain why B2B billing, especially for fintechs and usage-based pricing, can be cumbersome with generalist players like Stripe Billing, which was primarily built for B2C and e-commerce. We also do our best to provide concrete examples/facts and not opinions.

Finally, we actually made these experiments before co-founding Lago. We were the founding team of Qonto (Brex for Europe), where we built and maintained a home-grown billing system. A team of twelve is maintaining the billing system there today and we wish we could have staffed these talented senior engineers on our ‘core product’ instead of our internal billing tool. We have evaluated various commercial billing software, including Stripe Billing, many times but none of them has ever met our expectations.

‍

The experiment: Replicate Stripe’s pricing using Stripe Billing

‍

Their public pricing, named ‘Integrated’ (see above), is pretty straightforward. It’s a pricing that even very early stage startups could offer.

Stripe Billing has some powerful usage-based pricing features. In a nutshell, we were able to replicate Stripe’s pricing but encountered several limitations.

‍

Limitation 1:  You can’t easily charge a percentage fee

According to Stripe’s public pricing, when a transaction of $100 is processed through Stripe Payments, we need to charge a fixed fee ($0.30) and a percentage fee (2.9% x $100 = $2.90). However, we couldn’t find how to apply a percentage fee, so we had to find a workaround.

We created a first product called ‘Card charge’:

1. We selected the standard pricing (i.e. fixed unit price);
2. We set a price of $0.029 per unit;
3. We defined it as a monthly recurring charge; and
4. We ticked the ‘usage is metered’ box in order to be able to calculate the sum of all usage values.

This product allows us to calculate the total amount of transactions and then apply a charge of $0.029 for each dollar processed through the platform ($0.029 per dollar = 2.9%).

‍

Limitation 2: The architecture isn’t event-based

Stripe’s pricing includes two dimensions: a charge based on the number of transactions ($0.30) and a charge based on the total amount of transactions (2.9%).

If Stripe Billing’s architecture was event-based, each transaction would be an event and the transaction amount would be a property of the event. However, with Stripe Billing, each price needs to be linked to a product, so we had to create a second product to implement the charge based on the number of transactions.

‍

Therefore, instead of sending a single event every time there’s a transaction, we will need to send two usage values:

• One to record the transaction and be able to calculate the total number of transactions at the end of the billing period; and
• One to record the transaction amount and be able to calculate the total amount of transactions at the end of the billing period.

This setup can be very limiting for companies that process large volumes of transactions as they will have to create twice as many usage records.

‍

Limitation 3: Even the simplest pricing requires to store 5+ IDs

This is where we see that Stripe’s architecture was built with e-commerce in mind and not B2B SaaS.

To create a subscription, you need to:

1. Create products – here we have two products, so two IDs;
2. Create a price for each product – so two more IDs;
3. Create a customer – one ID per customer; and
4. Create a subscription, which can include several products and therefore several prices – Stripe generates one ID for the subscription and one ID per subscription item, so we retrieved three more IDs.

We have to store all these different IDs in order to operate via the API. It’s doable but we can all agree that it can be confusing and generates extra work.

‍

Limitation 4: Rate limits are… limiting

“For most APIs, Stripe allows up to 100 read operations per second and 100 write operations per second in live mode”

Stripe, in its documentation

We’re not the only ones who have spotted it – see this Reddit comment:

‍

For fintechs and cloud infrastructure companies, these rate limits can be reached quickly. If you’re a B2B neobank and monitor each transaction, this is a huge limitation for scaling the billing system, as each customer is a company with potentially dozens of employees, all of whom have a payment card.

If Stripe was really dogfooding its own product (Stripe Billing), it would have heavily modified it a long time ago to make it sustainable.

‍

Limitation 5: All products must have the same billing period

The Grail for ‘pay-as-you-go’ or ‘usage-based’ companies is to get their customer to sign an annual contract (it gives them peace of mind about recurring revenue) with a ‘consumption overage’ component (to capture expansion revenue).

These companies usually offer ‘Enterprise’ plans to their biggest customers. This is what Stripe calls the ‘Customized’ offer.

‍

In this case, the usual practice is to offer:

• An annual or multi-annual contract, including negotiated consumption (e.g. 24 months contract with $10M processed each month, priced at 2% instead of 2.9% + $0.30); and
• ‘Overage’ pricing in case the merchant exceeds the negotiated consumption (e.g. 2.3% + $0.10 for payments processed above the $10M initially included).

In this case, the negotiated consumption would be paid in advance each year and we would then charge for any overage on a monthly basis. With Stripe Billing, this could be implemented by creating a subscription, including:

• One product for the annual fee;
• One product for the monthly charge based on the number of transactions; and
• One product for the monthly charge based on the total amount of transactions.

However…

“Since using multiple products with a subscription results in a single invoice and payment, all of the prices for those products must use the same currency and have the same billing interval. You are also limited to 20 products in a single subscription.”

Stripe, in its documentation

Therefore, to implement the required logic, we would need to create two separate subscriptions: one for the annual fee and another for the monthly charges, which would add complexity (and create even more IDs – see limitation 3).

‍

Conclusion

You can replicate Stripe’s pricing using Stripe Billing, but it implies many workarounds and results in a billing system that isn’t really scalable.

We hope you found this experiment useful and that it answers the question “Does Stripe Billing handle metering and usage-based pricing?”.

We also had a lot of fun creating a ‘billing template’ that replicates Stripe’s pricing using Lago. Check it out here!