#Greggles
1 messages · Page 1 of 1 (latest)
Hello! Go ahead and share the event ID here
Are you not using Stripe's subscriptions? It looks like you're directly creating PaymentIntents here
You're right. We're creating a paymentintent for the additional charge then updating the subscription. What would be the correct way to charge for the difference?
Stripe will automatically charge for the difference when you update the Subscription.
I'd recommend reading through this: https://stripe.com/docs/billing/subscriptions/upgrade-downgrade
To clarify, we're updating the upcoming invoice $stripe->invoices->upcoming([]). So we don't need to do that, we just adjust the invoice and Stripe will automatically charge? I will read that documentation.
I'm not sure what you've suggested is the way to go. This is specifically for a tiered product.
They're adding a unit.
How are you updating the upcoming invoice? The upcoming invoice API doesn't actually generate an Invoice yet so there's nothing to update/adjust
Right
Can you actually sahre the request ID of the subscription update?
That's a PaymentIntent creation request - I'm specifically looking for the request you make to update a Subscription
Sorry about that.
https://dashboard.stripe.com/events/evt_1Mg42mGxG8m2870UXTtnZgnM
thank you!
It looks like the request post body for this event is the one I sent you
So instead of proration_behavior: none you could do proration_behavior: always_invoice and the subscription update request will immediately generate an invoice that charges for the new subscription unit being added
Our subscriptions are by default set to charge_automatically using the default payment method attached to the customer. Would the method you suggested generate an invoice by the send_invoice method?
No, it would still be charge_automatically and attempt payment
That's seems like a really easy fix. Thanks for your time.
👍 I'd definitely recommend trying that out in test mode once just to make sure it behaves like you expect, but yeah, it should be way simpler than what you're trying to do now with PaymentIntents
A related question: If the subscription reduces the number of units, we don't refund, we just modify the subscription so the next time around, they're charged the reduced amount. Would always_invoice produce a refund?
good question! So yes, always_invoice will produce a refund in that case so you'd likely want to introduce logic on your end to check whether it's increasing or decreasing the number of units and set proration_behavior based on that