#musty

1 messages · Page 1 of 1 (latest)

plucky archBOT
verbal valve
#

👋 happy to help

shell obsidian
#

Hey thank you, hopefully it makes sense, there's a lot of text haha, let me know if you need anymore context

oblique cipher
#

Hi there! Give me a few minutes to read/understand your question 🙂

#
  1. When creating our subscription plans, does it make sense to use quantity or pass the number of tokens in as metadata? What is standard practice?
    That's completely up to you, both approach work. Using the quantity would make it easier to increase/decrease the quantity if needed. If this can't happen, then metadata might be simpler.
#
  1. My most pressing issue is in regards to upgrading, simple proration won't really help us because the customer may use some of their tokens before they upgrade.
    Makes sense, then you shouldn't use Stripe's proration. You can pass proration_behavior: none when updating the subscription, and then handle proration on your end by updating the number of remaining tokens in a metadata field.
shell obsidian
shell obsidian
oblique cipher
#

Ok so in the case of the client having used 3 tokens and they want to upgrade from the $50 plan to $100 plan with 15 tokens.
The exact logic is completely up to you. For example: do you want to charge the customer immediately to the new price when they upgrade, or charge the new price at the next billing period?
Then just keep track of the quantity of token in metadata. something like metadata.tokens_current_period: 15 and metadata.tokens_last_period: 2 (or metadata.tokens_proration: 2)

shell obsidian
#

Since they've paid upfront for the last period, I'm thinking a line item showing a discount makes sense

sinful turret
#

Hi there 👋 jumping in as my teammate needed to step away.

You will need to calculate those prorations on your end, and then tell us how much you'd like to charge the Customer for. Are you planning to move the Subscription to the next billing cycle as part of the upgrade process? If so, I believe adding an Invoice Item to the Subscription would be a good option, but if you're not moving the Subscription to the next billing period then you'll likely want to process a one-off payment (possibly using an Invoice for that).

shell obsidian
sinful turret
#

When you create an Invoice Item object, you can provide a subscription parameter to indicate that it should be associated with a specific Subscription. Then when that Subscription generates its next Invoice it will pull in that Invoice Item.
https://stripe.com/docs/api/invoiceitems/create#create_invoiceitem-subscription

When creating the Invoice Item you can provide a negative value to amount to create a discount on the new Invoice to compensate for the previous payment.

Stripe API reference – Create an invoice item – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

shell obsidian
#

Ok got you, so is this done after checkout? When we create the negative amount does this show up on the checkout too?

#

Ideally the flow would be that user clicks upgrade, gets taken to a stripe checkout page and can see the 'prorated. amount' and how many tokens they will get with a disclaimer

sinful turret
#

Oh, I didn't realize you were planning on using a Checkout Session for this. Is there a particular reason you're considering doing so? The Subscription should already have details to process a payment and be able to do so without Customer intervention.

shell obsidian
#

Yeah the issue I have is that when using a checkout session, it needs to be clear what happens to the tokens the customer had. And how much they're getting charged. If they purchased a plan 3 days ago and used a few tokens they shouldn't see a completely new payment in full for the upgrade plan

#

im also looking to have optionality, so some customers can pay via card in a checkout or pay via invoice, is this possible via the checkout page or do I need to handle this before a checkout session is created?

sinful turret
#

Typically Checkout Sessions are not involved with Subscriptions after the first payment.

shell obsidian
#

oh really

sinful turret
#

If you're moving Subscriptions to their next billing period, then they will generate an Invoice, and once that Invoice is finalized it will have a link to its Hosted Invoice Page which is kind of like a checkout session for Invoices:
https://stripe.com/docs/api/invoices/object#invoice_object-hosted_invoice_url

Stripe API reference – The Invoice object – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

shell obsidian
#

so how would it work in most cases if a client wants to upgrade via the website

sinful turret
#

Via what website?

shell obsidian
#

my website

#

I have the plans showing and I want to allow them to upgrade

sinful turret
#

Your site would make a request to update the Subscription, and then the Subscription handles processing the payment.

If you create a Checkout Session, and also move the Subscription to the next billing period at the same time, then you'll end up processing two payments for your Customer. One from the Checkout Session, and another from the automatic process of the Subscription's lifecycle. To avoid this you would need to suppress our default Subscription behavior, which would be a bit complex.

#

My thinking of how to model the flow that I believe you're describing is:

  1. Calculate the amount you want to prorate on your end
  2. Create an Invoice Item with a negative amount and the ID of the related Subscription in the subscription parameter.
  3. Create a request to update the Subscription to change the Price that the Customer is subscribed to, and set billing_cycle_anchor to now to move the Subscription to the next billing period.
  4. Allow the Subscription's automatic flows to handle the processing of the payment, with a flow ready to handle the case where that payment fails.
shell obsidian
#

Ok that makes complete sense, so the client just clicks and confirms they want the upgrade and then we sort the rest on our end. The new amount we set gets charged immediately, a new billing cycle begins and we can then issue the invoice with all the information laid out with what was deducted and what was charged?

sinful turret
#

The Invoice will automatically be created, you do not need to manually issue one.

shell obsidian
#

ahh ok got you, so we update the subscription on our end with the amount then create an InvoiceItem which then links to this subscription?

#

other way round but yeah

#

seems pretty clear

#

if thats correct

sinful turret
#

Yup, you create the Invoice Item, and it is associated with the Subscription. Then when the Subscription is moved to a new billing period, it begins the automatic process of generating a new Invoice for the new billing period. When doing so, the Invoice will pull in the Invoice Item that you created which will adjust the amount that the new Invoice processes a payment for.

shell obsidian
#

got you!

#

ok that makes sense man thank you

#

so if the subscription gets cancelled and then they want to create a new plan again, they'd need to checkout right?

#

or would it just be a case of us just create a new subscription from our end

sinful turret
#

If the Payment Method that was being used is fully set up for future payments, then you could create a new Subscription directly. If you want to allow your Customers to also provide a new Payment Method while re-subscribing, then Checkout Sessions may be an easier approach though.

shell obsidian
#

got you

#

ok i think thats pretty clear man

#

thanks so much

#

if anything pops up, can I just message herE?