#ronho
verbal edge
desert spire
- Yes, generally that approach sounds right. If you want to charge for one-off products outside of the recurring subscription you can create an Invoice w/ the appropriate line items
- And yes you're correct that Stripe won't auto cancel an open Payment Intent but the answer is slightly different for Invoices depending on your specific account configuration. As an example, if you have retries enabled then it's possibel your invoice could be automatically voided if all retries were exhausted (depending on your settings here https://dashboard.stripe.com/settings/billing/automatic)
atomic holly
ah ok, thank you. for number 2, i was thinking for the 'draft' invoices and incomplete payment intents
desert spire
Ah yeah for drafts they'd just stay as drafts indefinitely
It's really up to you whether you want to keep them around or not - there isn't really any harm in leaving them open
atomic holly
ok
for the 'open' invoices (finalized awaiting payment), i want to control when to collect payment, so i have 'auto advance' turned off, because otherwise stripe will try to collect in ~ 1 hour
did i understand the docs correctly?
desert spire
Are you working with collection_method: send_invoice invoices or charge_automatically?
For charge_automatically yes there'd be a 1 hour wait period between draft creation -> finalization + payment attempt so if you want control over that timeline then auto_advance: false would do the trick
atomic holly
ok great. yes charge_automatically (which is the default)
once the payment is kicked off, would the auto_advance:false setting still allow for retries in the event of a failed payment ?
half roost
Yup! The invoice will be retried if auto_advance is set to false and payment fails
atomic holly
thank you!
one more question... is there a way to test a 'pending' payment ... between the time we kick off a payment to getting the webhook for invoice.paid?
half roost
Can you share more about the scenario that you would like to test? Once the payment has been made, its result will be sent through webhook events
atomic holly
a bit of a edge case perhaps, but not sure if you have any advice:
the clients submits the payment via Elements, and then the backend is waiting for the webhook to come back to unlock access (via invoice paid webhook). so in the waiting period, the clients begin polling to see that we unlocked access successfully. just seeing if there is a better way to simulate the scenario where the webhook doesn't come
tangental: afaik the clients would get a declined message from elements right away, is there any other error handling we should be handling via webhooks?
half roost
There is no direct way to simulate the scenario where the webhook doesn't come. One way I can think of to not subscribing to invoice.paid event for this testing purpose
With Element integration and customer in session to perform payment, no extra action is required to handle via webhooks