#kevboh

1 messages · Page 1 of 1 (latest)

void forgeBOT
scenic cosmos
#

Hello, happy to help

neat storm
#

I'm trying to build a webpage that allows a user to choose between two plans, a monthly or a yearly one, by clicking buttons. On the backend we create a subscription and return the latest invoice's PaymentIntent so that a corresponding Element can be shown on that same page for finalizing the subscription. So in sequential terms, what's happening is:

  1. User: visits page.
  2. Backend: picks the default plan (say, monthly), creates a subscription for it, and returns the data needed to show the Element.
  3. User: may fill out the Element or change the plan
    4a. If the user changes the plan, a request is sent to the backend to update the subscription with the new price ID.
    4b. If the user fills out and submits the Element, normal subscription flow continues.

I'm seeing errors on step 4a above, where the user may change the plan. It seems as if the API does not support the notion of updating a newly-created subscription with a new price. My question is: what is the best way to model the behavior I want via the API? Should I instead cancel and recreate the subscription entirely on plan change? Should I create subscriptions for both possibilities and cancel the one that isn't used? Thank you.

scenic cosmos
#

What error are you getting when you try to update the prices on the subscription?

#

I think you might be running in to a restriction related to not being able to change the prices on an Invoice after it is finalized. Might be hard to pull off this switch if you already have a subscription with a finalized first Invoice, I think you might have to create a new subscription, render a new payment element with its first payment intent, and confirm that intent

neat storm
#

You cannot update a subscription in incomplete status in a way that results in a new invoice or invoice items. Only minor attributes, like metadata or default_payment_method, can be updated on such subscriptions.

or

Currency and interval fields must match across all plans on this subscription.

I can't remember the cases in which which error occurred (code has changed since then as I try to debug), but these are the two I've seen

#

if I create two potential subscriptions, one for each potential plan the user could choose, and then cancel the unused one after the used one is finalized, is that an acceptable use of the API? Would I be able to delete the unused subscription such that it doesn't clutter the dashboard?

#

I'm mostly confused as this seems like a fairly common use case: surely most subscriptions with different pricing interval options allow the person to choose which interval they'd like before paying?

scenic cosmos
#

Gotcha, it sounds like you are running in to that restriction.

#

That would be a fine way to use the API, and yes you can delete the other subscription afterward. I agree that that is a common use case that is a bit awkward to implement here, I think even our integration with Checkout runs in to this restriction but it resolves it by not actually creating the subscription until after details have been put in.

#

Also have you seen our pricing table offering? That could be a good way to display options to users here

neat storm
#

rereading the docs, could I instead do the following:

  1. Use a card Element instead of a payment Element, which doesn't require a secret key (and thus a subscription) at creation-time (as far as I can tell)
  2. In the card click listener, hit an API in my backend to generate the subscription and return the secret key, and then call confirmCardPayment

this way I could defer subscription creation until the user has already entered their payment information and is ready to buy. I would still have to handle the edge case where payment fails and then they switch their plan, but does that seem workable?

scenic cosmos
#

Yeah that could work. That would definitely allow you to switch on the fly more easily. That edge case would be a bit tricky but still sounds doable to manage. At the moment I am not thinking of a good way to do this with the Payment Element.