Stripe subscription with capturing

[Toshiki Inami]

As far as I know, Stripe is only capable of dealing with capturing for one time charge.

I'd love to capture the certain amount of amount for some subscribers beforehand, and release it before subscription items being added during subscription payment circle.

So that I can check if the customer can pay some good amount before adding invoice items onto the invoice, and charge.

 - It's pay as you go system

 - Total balance can be different for each customers.

Any ideas?

[Remi J.]

Hey,

Right now it's not possible to do this automatically with subscriptions. You can build that logic yourself by authorizing a certain amount upfront and then letting us charge the correct amount for the current month automatically and releasing the original authorization if you want.

This seems confusing for your customers and might lead to a higher risk of declines if you keep authorizing $100 and then charging $125 and releasing the original authorization though so I wouldn't recommend this flow.

You might want to reverse the logic where you charge upfront for a certain balance, let's say $10 that your customer can use during that month and then you simply "top-up" by $10 whenever they use the balance previously charged.

Hope this helps!

Remi

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

[Toshiki Inami]

Thanks for the answer Rami.

Probably I have to explain little bit more about the detail.

My team started to implement usage based payment system on Stripe for PaaS/SaaS service.

In this case, I found two ways as far as I know.

1. Using subscription (Create users. Not one time charge.)

2. Using Invoice

I decided to use both 1 and 2 to implement usage based payments. Subscriptions on Stripe are charged through invoices. Stripe generates an Invoice object that represents the amount the customer owes and then attempt to charge the customer that amount. Note that this kind of invoice isn’t actually sent to the customer but is instead paid automatically in Stripe. A successful payment of the invoice results in an active subscription, which makes my life easier because I don't need to implement additional batch system to calicurate the amount.

So I can sign customers up for a $0 base subscription and attach invoice items each month to bill them for usage. As invoice items are a one-time adjustment, I use Stripe webhooks to listen for invoice.created event on each renewal and then add your invoice item for the appropriate amount plus dealing with tax.

I already wrote the production code, and it works well.

And my additional requirement is

- Once the usage goes over the certain amount. Let's say 50 bucks. I'd love to check if the user's card has potential to pay for the amount.

I couldn't find any right answer yet, so I thought it's better to implement without capturing first because our customers are all individuals, and I can expect the usage amount is small.

As our business grows and the time to need to provide it to companies ( not individual users ) comes, maybe it could build that logic ourselves.

(Ex. Something users can shift from subscription payment to One time charge. So the capturing is supported without confusing customers )

> You might want to reverse the logic where you charge upfront for a certain balance,

I'd love to hear more about the way you suggested though.

Thanks,

[Remi J.]

Thank for the extra information! It seems that I understood the flow you had built so that's a good thing!

The main issue here is that you are trying to authorize $50 on the card for example just to make sure the customer has enough funds on the cards to let him continue use your service. The fact that the customer has enough funds today doesn't mean they will tomorrow or next week. If you hold that authorization (and you can for up to 7 days [1]) then that helps but it doesn't guarantee that the charge associated with the invoice, for example for $55 a few days later will succeed as you already hold $50 on that card.

In that situation, it seems that you want to implement a metered billing service with a limit where you force the user to pay. This means that, instead of authorizing $50, you can just charge those $50 now outside of the monthly billing cycle so that you're sure the customer will pay the amount he currently owes. He can then continue to build up his usage back from $0 which you would charge on the normal billing cycle.

The caveat is that for large users of your service, you'd end up charging them $50 multiple times a month. In that situation you could make a dynamic limit based on the customer's usage over month. Someone who spends $10 each month and suddenly reaches $50 is charged immediately to cover for it. Someone who spends $500 each month isn't charge until they suddenly spend $1000 for example.

As for the other option of charging upfront, I meant something like a top-up. The idea is that instead of subscribing the customer to a $0 plan and charging them the correct amount at the end of the month, you can subscribe them to a $50 plan that they pay upfront. They then use that $50 during the month and anything that is not used at the end of the month is added back as credit for the following month (with a negative invoice item). This way you ensure that a part of the amount owed is always paid upfront.

Ultimately there are a lot of ways to approach and build this and it depends on your business model and the risk you want to take with your customers and what they are ready to pay you for upfront.

Hope this helps!

Remi

[Toshiki Inami]

Thank you so much for the answer! (sorry for the late reply.)

You answer helped a lot!!

However the team leader changed the specification. It's more like recursive + meter billing.

It would be another topic, so I'll post that later on.

Thank you so much.

Best,

Toshi