#alex3249837
1 messages · Page 1 of 1 (latest)
Hi there 👋 you cannot reopen threads. Can you summarize the current state of your concern that you want to discuss?
Did so here: #dev-help message
Copy pasting for context:
If I follow the advice given in this thread (alex-subscription-pause), when I pause the billing for a subscription, will this suspend or stop the customer from receiving anything subscription related until the specified timestamp?
Can you elaborate on what you mean by that? When you say "will this suspend or stop the customer from receiving anything subscription related until the specified timestamp", is that regarding the access/products you provide as part of the Subscription, or is this regarding the Stripe side of the process such as generation and transmission of Invoices?
If the latter, it depends on which behavior you're using, and those are talked about in a bit more detail here:
https://stripe.com/docs/billing/subscriptions/pause
You can use Test Clocks to test this behavior out in test mode and see how the system will behave:
https://stripe.com/docs/billing/testing/test-clocks
Regarding the access/products the company provides as part of the subscription.
If a customer is on a monthly subscription for tea and say they have a lot leftover from April's shipment, and they decide they want to skip receiving anything this month, can we pause the subscription for this month?
Sure, you can pause the Subscription, but taking action on a Stripe object doesn't necessarily mean the downstream processes on your end will stop. You will need to update your logic to track whether a Subscription is paused and tell your processes what they should do if that is the case.
I don't know how you trigger your downstream processes so I can't provide any insight on how to adjust how they are run, you will be best suited to make those changes.
You can listen for customer.subscription.paused and customer.subscription.resumed Events though to know when a Subscription is paused or resumed.
https://stripe.com/docs/api/events/types#event_types-customer.subscription.paused
https://stripe.com/docs/api/events/types#event_types-customer.subscription.resumed
via webhook endpoints:
https://stripe.com/docs/webhooks
Which endpoint would you use to pause the subscription with a specified amount of time?
So like from this page (https://stripe.com/docs/billing/subscriptions/pause), which one would you recommend I use?
What do you want the Invoices for the Subscription to do while the Subscription is paused? Do you want the Invoices to be kept in a draft state, or would you like them to be voided or marked as uncollectible?
I don't want the customer to be charged until the specified amount of time or date has been reached.
Hello! I'm taking over and catching up...
What's the difference between the two options? What happens to invoices when they are kept in a draft state? What happens to invoices when they are voided or marked as uncollectible?
Invoices in draft are just that: drafts. While they're in draft they're still editable and they don't do anything. Invoices that are voided can no longer be paid. Invoices that are uncollectible are ones marked to indicate the amount cannot be collected. We have more details here: https://stripe.com/docs/invoicing/overview#invoice-statuses
So it sounds like I want the invoices drafted then.
So from this page (https://stripe.com/docs/billing/subscriptions/pause), I would use resumes_at property to allow the invoice to be turned back into a non-draft invoice? And then when the resumes_at property is reached, the invoice will be collected?
Yep, if that's the behavior you want, where the paused Invoices stay in draft.
If a customer has a custom OMS that uses Stripe Subscription, then is it safe to assume that their OMS system will check Stripe Subscription API for the latest info and see that for a particular subscription the invoice is in draft state and therefore should not be shipped?
What does OMS stand for?
In any case, I don't think it's safe to assume anything about a system you don't control; I would confirm the behavior will be what you expect with the people who own/created that system.