#nova-astramentis_api

1 messages · Page 1 of 1 (latest)

hard beaconBOT
#

👋 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/1372283206136631417

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

main root
#

This is related to thread 1372015091603738705 . The solution that was offered there does not fit what we want to do.

We simply want to bill the customer for the upgrade mid-cycle, and leave their billing cycle alone.

The ALWAYS_INVOICE method should work just fine here.

The problem is that the prorations it creates suggest a coupon is applied, but its applying no discount. If we instead use item-level discounts, the next invoice is getting double discounted (once for the line item, once for the subscription itself).

hard beaconBOT
main root
#

req_yhdQoYzC5ODah2 shows the behavior of the prorations when set to ALWAYS_INVOICE (no discount applied).
req_WsignzMJYFAMtH shows the behavior of the prorations when both setBillingAnchor and CREATE_PRORATIONS is used (discount applied, but 18 line items is really excessive)

hollow relic
#

Hi there 👋 taking a closer look at the requests you shared.

main root
#

Thanks for responding!. There is another request req_aMizbqOW4z52vo that shows what happens if you apply a discount at the line item level. Description changes to (with multiple discounts), the amount seems to be correct, but the discount_amounts value doesnt reflect the actual discount. We are using this information to show to users, so we do need it

hollow relic
#

Okay, we'll come back to that, one thing at a time.

Right now I'm looking at the first request you shared:

req_yhdQoYzC5ODah2 shows the behavior of the prorations when set to ALWAYS_INVOICE (no discount applied).
and am trying to understand what you mean by "no discount applied", because it looks like a Coupon was provided in that request and like the Subscription already had a Discount on it from that same Coupon being applied to the Subscription previously.

main root
#

So when we preview an update to the subscription, we pass the existing coupon ID to that request to ensure that the coupon remains on the subscription after the update.

The initial invoice has the coupon apply no problems. Subsequent invoices as well, have no issues.

When upgrading a subscription (and generating prorations), the discount seems to physically get applied to the line item, but the discounts objects return an amount_off of zero (when they did actually take a percentage off the prorated item)

#

The line item is 500,000 units ($5000). We see a prorated billing of $4490.11 which corresponds to ten percent off the line item price, minus whatever time has elapsed on the subscription. Mathematically, this makes sense. What we don't see is the discount being recorded anywhere.

hollow relic
#

Can you share a request you made to update a Subscription and the ID of the Invoice it generated?
Or are you seeing the concern with the preview invoices?

Sorry for all the questions, I'm having a hard time grasping what specific fields you're looking at from which request response, what you're expecting them to be set to, or what they're set to instead, which is making it hard for me to get my bearings and follow along with what you're describing.

main root
#

Yeah absolutely.

Request ID: req_DxobyV1c0LbNaN
What happened:

  • Subscribed to a price that charged the user $1,000 CAD / year. With a 10%-off coupon. Final charge is $900 CAD. (successful)
  • Created a preview invoice where they upgraded their plan to one that costs $5,000CAD / year.
  • Proration was created for -$899.82. This is the credit for the unused time on the $1,000/year price.
  • Proration was created for $4499.11. This is the charge for the remaining time in the year at the $5000/year price.

Expected Behavior:

  • We expect the 10% off discount to apply to the prorations (it did) (successful)
  • We expect the amount taken off by the 10% discount to be reflected in the total_discount_amounts.0.amount field. (Not successful).

Alternatively, we would expect something to show up in lines.data.1.discount_amounts.0.amounts which is also $0

What went wrong:

The total_discount_amounts.0.amount field was set to $0, when it should have been set to $499.90, reflecting the 10% discount on the $5000/year plan.

#

Sorry for the lack of clarity earlier. This feels like a bug on Stripe's end, so I should have just submitted it in a standard bug report format from the get-go

hollow relic
main root
#

This is in contradiction to what your previous support staff was suggesting (in the other thread), which is that I am supposed to set the discount at the item level. When I did this, I got the proper discount amount.

Is this just inconsistent behavior, or is there something I am missing?

unkempt wraith
#

Hello. i want some help iinstalling stripe react native, it is getting installed, also did pod install but failing to build, what could be the issue, anyone please help me out

hard beaconBOT
#

@unkempt wraith looks like you're in the wrong place, this thread is for someone else's question.

Note that posting inappropriate messages in other people's threads is against the rules. No worries if this was just an honest mistake, but anyone who violates the rules multiple times will be removed from this server.

hollow relic
#

Maybe I'm missing something in that thread, but I'm also that thread didn't bring enough context initially for us to understand your situation.

main root
#

Gotcha. It wasnt my best work for sure.

I think for now, I have my answer which is calculate it yourself if we need the discount amounts. We can just use refund/purchase price to get a percentage of elapsed time, and then perform what are likely the same calculations you are doing on your side. Its a shame that this is a non supported operation, but I appreciate your time spent with me either way.

hollow relic
#

Any time! Untangling proration scenarios always takes time, and I appreciate your patience as I built an understanding of what you were doing.