#Min.K

1 messages · Page 1 of 1 (latest)

autumn hillBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

  • Min.K, 6 hours ago, 4 messages
  • Min.K, 3 days ago, 4 messages
  • Min.K, 4 days ago, 20 messages
  • Min.K, 5 days ago, 5 messages
  • Min.K, 5 days ago, 4 messages
  • Min.K, 5 days ago, 3 messages
    and 3 more
woeful quail
#

Hi there!

solid knot
#

No entiendo mucho, 😓

woeful quail
#

Should I utilize the Upcoming Invoice API to get the next due amount?
Yes that sounds like the correct solution.

#

@solid knot Please ask your question in #dev-help

elder marlin
#

Should I utilize the Upcoming Invoice API to get the next due amount?
Yes that sounds like the correct solution.

============================================================

However, I'm concerned about the rate limits.

Q3. Is using their API the only appropriate way to go?

Q4. If I subscribe to multiple products and use coupons at the same time, the calculation is complicated, so I think I will have to use the upcoming invoice API. Is that right?

woeful quail
#

However, I'm concerned about the rate limits.
Why? How frequently do you need this information? Can't you cach it on your end?

#

Q3. Is using their API the only appropriate way to go?
The other option is to compute everything on your end. But that can be complex (free trials, coupons, prorations, etc.)

#

so I think I will have to use the upcoming invoice API. Is that right?
That's our recommendations, yes.

elder marlin
#

I'd like to ask a few more questions, and thank you so much for your kind response.

I have a question about how to integrate a subscription feature into our product utilizing the Stripe API and webhooks.

We want to provide a screen for our customers to view and manage their subscription information on our own, where we need to provide them with information such as the name of the subscription product, the start date of the subscription, the next due date, and the amount of the next payment.

I think there are two ways to achieve this goal.
store only Stripe subscription identifiers in our own DB and call the Stripe subscription lookup API to retrieve that information when accessing the subscription management screen.
store all information such as subscription identifier, subscription product name, subscription start date, next subscription due date, and next payment due amount in our own DB and not call the Stripe API even when accessing the subscription management screen.

Q5. I was wondering which of the above 2 approaches is officially recommended by Stripe? If we choose option 1, I think we will get a lot of traffic and hit our rate limit because we will call the Stripe API if many customers access the customer management page at the same time. However, if we choose option 1, it will be easier to manage because we will only store the subscription identifier in our own DB. If we choose option 2, we will be safe from rate limits, but we will have to manage storing too much information in our DB.

woeful quail
#

We want to provide a screen for our customers to view and manage their subscription information on our own, where we need to provide them with information such as the name of the subscription product, the start date of the subscription, the next due date, and the amount of the next payment.
Are you aware of the Customer Portal that does exactly this for you? https://stripe.com/docs/no-code/customer-portal

elder marlin
#

Yes, I know.

We use the Subscription Update API because when we upgrade a subscription, we need to upgrade the subscription immediately.

And when we downgrade a subscription, we use the Subscription Schedule API because it needs to be processed after the end of the subscription's current cycle.

However, the Stripe Customer Portal does not currently support subscription scheduling, so we need to create these UI screens on our own.

woeful quail
#

Yes you need to be carful with the rate limits. I would recommend to store most information in your own database, and use webhook events like customer.subscription.udpated to keep everything in sync

elder marlin
#

However, you recommend calling the API every time to get the next subscription price to be paid, right?

Shouldn't the subscription information also require a call to the API every time? It's inconsistent that the API should be used to get the next billed subscription price, but the subscription information should be stored via events.

woeful quail
#

You could also retrieve the Upcoming Invoice once, store the result in your database, and then display the information from your database to your users to avoid the rate limit. All of this is up to you.

elder marlin
#

Oh, i see. Very good point ! Thank you

Finally, a question.

Situation.

  1. you register duration_in_months as 2 times as a recurring coupon period.
  2. you start a subscription via the payment session API and subscribe to multiple products in one subscription.
  3. a week passes and you call the upcoming invoice API passing only the subscription parameter.

Last Question. If you look at item 3, the situation in item 3 is that you still have 1 coupon period left in the subscription. If I call the Upcoming Invoice API passing only the subscription parameter, will the coupon be applied and then the payment amount returned?

autumn hillBOT
echo epoch
#

I'd think so. You can test in test mode with Test Clocks to confirm.

elder marlin
#

Thank you for answer.

To easily find out the next payment amount, calling the upcoming invoice API seems essential.