MrJamesF

[bright dragon]

Hi! Let me help you with this.

You can use usage-based subscripiton: https://stripe.com/docs/billing/subscriptions/usage-based

For that, you can put your amount into the base fee and don't report any usage.

[desert agate]

Thanks

Some of our products have a quantity, can you have a quantity of 2 on a usage based product?

[bright dragon]

In this case you can omit the base fee (e.g. $100), and add 2 usage records of $100/unit.

[desert agate]

Perfect

How would it would with proration when they upgrade from plan a to plan b?

[bright dragon]

That might be challenging with downgrading as usage records imply they've already been "used" so no proration will happen.

Maybe you could instead give those customers a 100% discount on subscription, but then create a PaymentIntent for the real amount at the end of the billing cycle. That's another workaround.

[desert agate]

One of the approaches we are considering is to treat invoice.finalized as if they are invoice.paid events, meaning the orders get filfiled when the invoice is finalized instead of when the invoice is paid

can you see any issues with that?

[bright dragon]

How would that help with your issue?

[desert agate]

Because you could create a new subscription for Customer A and choose the option to Send Invoice. When the invoice gets created it will trigger our webhook with an invoice.finalized event and then we give the Customer access to the saas app

rather than triggering giving access to the saas app based on the invoice.paid webhook event

my understanding is you would normally give access to your saas app after the invoice.paid webhook event is received

One problem we see with the usage based suggestion is that the Customer needs to receive the invoice at the start of the billing period as it takes 30 days for their finance team to pay invoices, with usage based i believe the invoice would be sent at the end of the month? @bright dragon

[storm raven]

If a usage based model doesn't fit your product/business, then I'd not recommended using it. It's appropriate here as its the only pricing model where we invoice at the end of the cycle

But otherwise, send_invoice and using finalisation to provision access seems like the best solution

Obviously there's risk associated with that (i.e. revenue recovery) but you seem aware of that

[desert agate]

Do you know if any other companies do it using Stripe as its quite common to have large customers paying on 30, 60, or 90 day terms

[storm raven]

Do what sorry

[desert agate]

handle the 30, 60, 90 day payment terms of finance teams , i'm happy to wait for @bright dragon if they are on lunch?

https://gocardless.com/guides/posts/what-does-net-30-mean-finance/#:~:text=this comprehensive guide.-,What is net 30%3F,after they have been billed.

Some of our customers are on Net 30, some on Net 60, and some on Net 90 days payment terms with us

[storm raven]

That's supported via the send_invoice collection method, yes. Otherwise we'll attempt payment ~immediately and automated retries would apply

You can set a due_date on those invoices

[desert agate]

Ok great, can you confirm how that would work, would the invoice be in the paid state if the due date is set in 30 days, or if not how would we grant the customer access to our Saas App before they have paid the invoice

if a due_date is set the invoice should really have a different status of 'net_terms' or something so we know to grant them access to the saas app

[storm raven]

would the invoice be in the paid state if the due date is set in 30 days
I'd only be marked as paid when its either paid, or you mark it as paid. Otherwise it'll remain open and the subscription would be flagged as past_due.

[desert agate]

So how would a typical customer make use of the due_date in regards to a Net 30 payment terms invoice and how would they grant the customer access to the saas app

[storm raven]

Who is a typical customer in this instance? Your customer?

Have you tried to use the APIs to simulate your use case? You can use Test Clocks to advance time as needed

[desert agate]

In that instance i mean a typical stripe customer, such as Figma or Slack

[storm raven]

I don't really know if/how they integrate with Stripe

[desert agate]

they are both integrated but the case studies are lacking the technical details of how they use it, which would be very valuable to know https://stripe.com/gb/customers/figma

My point is we are not the first company to use Stripe in this way but it would be good to know how the others have make it work successfully

[storm raven]

Those aren't the kind of details we share publicly

[desert agate]

Thats unfortunate as it would be useful to know the best practices of using Stripe

I can't see how the due_date has anything to do with solving the Net 30 days issue, could you explain more please

[storm raven]

Our documentation covers most of those. Your use case is a little off piste so we don't really account for that specifically

I don't understand what you require from Stripe in respect to the 30 day payment terms

[desert agate]

I will let you know the process of Net 30:

1. Customer signs up to our Saas app
2. Customer chooses to pay on Net 30 terms
3. Invoice is generated at start of billing interval
4. Customer is granted access to login and use Saas app
5. Customer pays invoice 30 days after receiving it

How would you do this using due_date?

Which webhooks would you listen for and which webhook event would you use to grant the customer access to the saas app

It needs to have proration so if the customer decides to upgrade or downgrade it will only charge for the remainder of the month

The finance team needs to receive an invoice and will pay it 30 days after receiving the invoice

[storm raven]

1. Create your Subscription, setting collection_method: 'send_invoice' and setting days_until_due to the payment terms required.
2. The Subscription will be created and active. You can provision access at this point.
3. The Invoice will be finalised and sent to your customer within ~1 hour, with a due date reflecting the days_until_due value.

After that point, my assumption is subscription becomes past_due if the invoice is unpaid beyond the 30 days. But you can test this easily yourself with Test Clocks: https://stripe.com/docs/billing/testing/test-clocks

[desert agate]

The problem is the customer needs to receive the invoice at the start of the billing period but with days_until_due the customer will not receive the invoice until 1 hour before the due date?

[storm raven]

No, read again. We send it 1 hour after subscription creation

[desert agate]

Ok thats good

[storm raven]

That's standard for all subscriptions: https://stripe.com/docs/invoicing/integration/workflow-transitions#finalized

[desert agate]

If we provision access based on subscription being active, would that be a problem for customers who pay using a more standard payment method such as a credit card?

As we have some customers who pay via Credit Card, some via Invoice and some via Invoice with Net 30

[storm raven]

No, because in those standard subscriptions (i.e. non send_invoice) they'd only become active after the initial payment succeeds: https://stripe.com/docs/billing/subscriptions/overview#subscription-lifecycle

[desert agate]

Perfect

We also have a one-time product customers can pay for on Net 30, which wouldn't have a subscription as its a one-off item

how would you handle that

its for the customer to buy one-off tokens/coins

[storm raven]

You'd send them a one-time invoice I guess

[desert agate]

we need to add the coins to the customers coin balance

you would have to add the coins to their coin balance when the invoice.finanlized webhook event is received?

[storm raven]

I don't know what a coin balance is

[desert agate]

its something in the saas app

you buy coins and spend them in the saas app

[storm raven]

I guess that'll work then

[desert agate]

do you forse any issues with anything we have talked about

it sounds like we are the only people who are using stripe in this way?

[storm raven]

I doubt that

Honestly, I'd recommend just playing with the API and seeing if what I outlined actually works for your use case

[desert agate]

we have been playing around with something similar

the only difference is this step

2. The Subscription will be created and active. You can provision access at this point.

[storm raven]

Build a proof of concept using your test keys, as there may be edge cases that I haven't accounted for. Equally, I don't know anything about your product/business so I can't account for everything – I can only recommend way Stripe can help you

[desert agate]

we provision access on the invoice.finanlized event rather than the subscription active event

there should be no real difference in using invoice.finanlized or subscription created/active i assume?

the reason is invoice.finalized covers both one-time and subscriptions in one go

[storm raven]

Well invoice.finalized will fire ~1 hour after creation of the susbcription/invoice as per the doc I shared earlier

[desert agate]

during our testing it seems to fire immediately

but we are not setting a due date so maybe thats why

i just created a subscription now and this was the webhook events sent

[storm raven]

Well if you're not using send_invoice then it will fire immediately for the initial subscription payment

[desert agate]

ah i see

[storm raven]

You can't pay an invoice until its finalised

[desert agate]

i think a 1 hour wait should be acceptable

if needed the sales agent can go into Stripe dashboard and force it to finalize faster i believe