#Naveed | Web3Auth
1 messages · Page 1 of 1 (latest)
hello! you can use https://stripe.com/docs/api/invoices/upcoming
"You can preview the effects of updating a subscription, including a preview of what proration will take place"
How can I do this?
"subscription
optional
The identifier of the subscription for which you’d like to retrieve the upcoming invoice. If not provided, but a subscription_items is provided, you will preview creating a subscription with those items. If neither subscription nor subscription_items is provided, you will retrieve the next upcoming invoice from among the customer’s subscriptions."
ok this seems like the one
i can provide the new subscription items for it
yep
you can also specify the specific proration start date : https://stripe.com/docs/api/invoices/upcoming#upcoming_invoice-subscription_proration_date
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
so in my case i would probably want it to be immediate
can i actually get an intent from this to feed to my frontend?
where i can display the amount to users and they can also confirm and thus udpate their subscription?
you won't get a PaymentIntent
you will get the preview Invoice object back but it's a preview, keep in mind nothing has actually been created.
i can just show them the preview amount, and if they're good they'll confirm, and i will udpate sub in the backend
you can see the sample response in the docs
right i dont see an intent there.
So is this flow correct then for update subscription with amount preview flow?
- Call upcoming api with the desired new subscription items
- Show the response amount to the frontend
- Button which will call update subscription endpoint in my backend
yep, looks right to me. As usual, test it out and see how it works
Ok but in the pending updates scenario, I dont have to use upcoming endpoint right.
I can just use the latest invoice payment intent to derive that information right
I was hoping that pending updates could work for cases even when there's a card on file
the key point of pending updates, is so that updates won't be applied if the payment fails (and you won't need to manually roll back the update)
It will work if you have a card on file
Okay, then going back to the preview invoice way
- Call upcoming api with the desired new subscription items
- Show the response amount to the frontend
- Button which will call update subscription endpoint in my backend
Step 3 would charge the card on file. My question now is
If the card was set up via set up intents (which means completed all necessary steps including 3d secure), then it would successfully charge it
But what if the card has insufficient funds?
onesec, i think there's still a misunderstanding here
if you update the Subscription with payment_behavior=pending_if_incomplete, and the payment is successful, the update will take place immediately
that's what i meant by pending updates will work for cases even when there's a card on file
if you want to show a preview amount, you should use the upcoming invoice API
Ok so in step 3, it would fail if there are insufficient funds when trying to update sub
i can show this error message in the frontend
"if you update the Subscription with payment_behavior=pending_if_incomplete, and the payment is successful, the update will take place immediately"
And in the case where there's no card on file, it will be pending, and I should confirm payment on the latest invoice intent to make it successful
yep that works
but i feel your flow would be cleaner if you just did the upcoming invoice at step 2
instead of splitting it into two separate scenarios
hmm i dont get you
- get the upcoming invoice to display the amount to the customer
- let the customer decide how they want to pay
- do the update to the subscription in your backend with payment_behavior=pending_if_incomplete
Ok so lets go into step 2
a) Customer has no card
b) Customer has card
b is simple, just go to step 3
Not sure about a though
So for a I assume they'll have to
- input card details
- submit (uses setup intents to save card)
- Update subscription
in this case it seems like Ill need two buttons, one for setting up card successfullly and THEN updating subscription
but the designs I was given look like this
so what happens is that when you click on Change Plan, you would confirm the SetupIntent, and assuming it's successful, you would then make a subsequent request to your backend to update the Subscription
Hmmmmm...
Yeah u know what as you'd mentioned in an earlier thread using setup intents would be easier than, trying to do a pending update, getting back the latest invoice payment intent secret, using that to instantiate the <PaymentElement /> and THEN confirming the intent with the stripe element input fields
it's just an idea, i find that whenever i try things out, there may be some things which i forgot to take into consideration previously, so like what I always say, try it out and see how it goes first 😆
yes no doubt
I will also have to support the case of creating subscriptions actually
as in not just updating but also the case of user has no sub
so in that case i think actually i can use the same principle
set up the card, then create or update subscription
though my current flow for create is using the create incomplete subscription + latest invoice payment intent way
the setup intent approach might unify + simplify everything
Oh hold on does create subscription (if prorated) also return a preview amount of what will be actually billed?
it works the same way as if you update a subscription. If you attempt to create it and an existing default payment method is set, then it'll attempt to charge automatically
otherwise, if the customer doesn't have an default payment, and you create the subscription with payment_behavior allow_incomplete or default_incomplete, then the Subscription will be created in incomplete state first
so i can use the upcoming endpoint again?
yes, you can
ohhhh...