#neha_subscription-invoice
1 messages ¡ Page 1 of 1 (latest)
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.
- neha_api, 5 days ago, 59 messages
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1242965013015040040
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
neha_subscription-invoice
It looks like your integration made 2 identical requests to updated the Subscription with new items each time, which immediately created and charged an Invoice each time due to having proration_behavior: "always_invoice"
Here are the update requests:
i can't see those links
those are Dashboard links so you should be able to see those if you're logged into the Dashboard of this account
ah you use Workbench that;'s why it works differently and we don't have access to it.
you can load the Event and it should have a direct link to the exact API request that caused it for each one
I'm sorry I am not familiar with Workbench it's in beta and I haven't touched it or have access so I can't see what you see unfortunately
request 1
{
"items": {
"0": {
"id": "si_Q89Ycms6WVMmCx",
"price": "price_1OrVScBZ8IchjqOe1hT1404y"
}
},
"payment_behavior": "pending_if_incomplete",
"proration_behavior": "always_invoice",
"trial_end": "now"
}
request 2
{
"billing_cycle_anchor": "now",
"items": {
"0": {
"id": "si_Q89Ycms6WVMmCx",
"price": "price_1OrVScBZ8IchjqOe1hT1404y"
}
},
"payment_behavior": "pending_if_incomplete",
"proration_behavior": "none"
}
yeah you passed billing_cycle_anchor: 'now' and that immediately resets the billing cycle and creates an Invoice
so your own code did this twice, both times without any proration and cutting. a brand new Invoice for the full new Price
yeah that part is really on your end I can't tell you
it's rare to use billing_cycle_anchor: 'now' with proration_behavior: 'none' for example so maybe that;s what you need to revisit
it's because i have a "Renew now" button
some people want to renew their subscription manually
yeah but that is not doing what you think then
Say I have paid $20 on March 1st and April 1st and May 1st. Now on May 22 I want to renew my subscription in advance, I want some credit for May 22 - May 31 right?
not exactly
you pay $20 on march 1 - you're granted 100 credits
you deplete them all
within 24 hours of your renewal, so starting march 31, i show a renew now button if you're chomping at the bit to get more credits
if you click this button, you're billing cycle should shift to the time when you clicked it (so your new "month" would be march 31 - april 30)
does that make sense
ah yeah I see, it's a credit based billing model so yeah that makes sense
so yeah maybe they clicked twice and you don't have a protection against this? Maybe track if the "credit" has been consumed before you re-reset
so i have 2 bits of code
- end free trial early
items: [{ id: subscription.items.data[0].id, price: finalPriceId }],
trial_end: "now",
proration_behavior: "always_invoice",
payment_behavior: "pending_if_incomplete",
});
- renew subscription early (within 24h of scheduled renewal)
return this.stripe.subscriptions.update(subscriptionId, {
items: [{ id: subscription.items.data[0].id, price: finalPriceId }],
billing_cycle_anchor: "now",
proration_behavior: "none",
payment_behavior: "pending_if_incomplete",
});```
so yeah maybe they clicked twice and you don't have a protection against this? Maybe track if the "credit" has been consumed before you re-reset
can you elaborate on the 2nd sentence?
i agree it's probably something i can solve by double checking the sub
I don't know exactly how you track the credits used on your end so it's tough to say but you need to prevent the second early renewal if the credits haven't been consumed
okay, thanks for the quick help