#maha-Subscription

1 messages · Page 1 of 1 (latest)

trail perch
#

Hi there, what do you mean by always pending?

lime crescent
#

So basically, lets say there is a card that won't error out or require 3D secure when making the payment (payment needs to be made since the customer may be upgrading to a more expensive price). This payment would transition directly to the paid state instead of transitioning to pending state. I don't want to do that, since I want to fetch the client_secret for the payment_intent of the pending update invoice and then confirm the payment intent over on client side

#

Basically without being able to do so, I won't be able to fetch client secret when initializing stripe payment element for the payment since the payment intent would already have been confirmed over on the server side

#

In short, I would like to always confirm the payment intent over on client side

#

@trail perch

trail perch
#

Got it, so you want your customer to confirm the upgrade on the client side, am I right?

lime crescent
#

Yupp

trail perch
#

You can generate a portal link and send to your customer where they can choose what subscription they want to upgrade to, and confirm the payment in the page.

lime crescent
#

Yes I understand that the customer portal would be a good solution to this, but would there be another way to do this via API calls?

#

We unfortunately may not be able to follow a redirect based approach

trail perch
lime crescent
#

Thanks, I'll try doing this

trail perch
#

Stripe will only attempt the payment when the invoice is finalized.

lime crescent
#

yes and wouldn't it be finalized in this case immediately after I attempt to update the subscription?

#

invoice would get created and then immediately finalized (in case billing period of the updated price is different from the current price)

trail perch
#

Here's how it works

  1. you update the subscription
  2. a invoice is generated and you'll receive invoice.created event
  3. set the invoice's auto_advance to false so Stripe won't charge the customer automatically when the invoice is finalized.
lime crescent
#

But there is not going to much of a gap between the invoice.created and invoice.finalized events...right?

trail perch
#

What gap do you mean?

lime crescent
#

Since stripe is almost immediately gonna attempt to finalize the invoice...isn't it possible that the invoice is finalized before I receive the webhook?

#

by gap I mean the amount of time between the creation and finalization of the invoice

#

since the docs say that the payment is attempted immediately...I would assume that the update invoice would get created and then be finalized right away

queen schooner
#

👋 stepping in for Jack and gimme a few mins to catch up

lime crescent
#

sure

#

Ok so about the auto_advance approach that Jack suggested above...it doesn't work precisely because the invoice is already paid when I receive the webhook

queen schooner
#

That's what I suppose. To clarify we are talking about interval change, correct? Monthly to Yearly

lime crescent
#

yes

queen schooner
#

You're right, it's attempted automatically. Let me look around to see if there is some convenience parameter

#

But taking a step back why would you need to intercept this Invoice? You already collected your customer payment info, so you can just charge them right away

lime crescent
#

no but

#

they could be adding a new card?

queen schooner
#

Stripe build the API to maximize your revenue, so we attempt immediately since we think we can

lime crescent
#

like lets say a customer has a bunch of payment methods on stripe due to past payments. now, they wanna upgrade to a new plan but they want to use a new card. Now to use a new card with this payment, it would be ideal that a payment element could be created using the payment intent of the update

#

but I can't use the payment intents client_secret since the payment gets immediately attempted and the invoice gets finalized

queen schooner
#

Sounds like you want to let your customer specify which card to use

lime crescent
#

yes

queen schooner
#

before making the change

lime crescent
#

yes

#

we basically have it such that they could use any of their existing cards or add a new card

#

we were previously using the tokens api so it wasn't an issue since no client secret is required in that case...but obviously we couldn't keep using it since its outdated and doesn't support additional factor authentication

queen schooner
#

Ok I found it

#

set payment_behavior to default_incomplete

#

I just tested it. It will stop the Invoice to be paid, leave at "Open" and its PaymentIntent at unconfirmed

lime crescent
#

But wouldn't the subscription update be applied in this case?

#

Like what if the payment later fails..would I need to roll back the update?

queen schooner
#

The Sub will remain in "Past Due" until that PI is confirmed

lime crescent
#

is there a way to not update the sub until the PI has been confirmed?

#

kinda like with pending_if_incomplete

#

but without updating immediately

#

basically:

  1. user should be able to choose a card when making payment for subscription update
  2. the update should only apply if the payment is successful
  3. in case the payment is not successful...the subscription continues as it is
queen schooner
#

If I understand correctly, you want the Sub to be completely untouched?

lime crescent
#

yes

#

sorry for the late response

queen schooner
#

In that case I think the only feasible solution would be, pre-collect the new PaymentMethod then making the Subscription change

#

You can collect via a SetupIntent/PaymentElement. After it's confirmed, extract SetupIntent's payment method and set back as default payment method for the subscription

#

and make the change

lime crescent
#

but then what if its a card that always requires authentication? customers would first authentication when adding the card and then when making the change

queen schooner
#

PaymentElement would handle the 3D Secure authentication for you

lime crescent
#

Yes but doing what you suggested would split the flow into two, right?

  1. Collecting the payment info using setup intent
  2. changing plan by extracting payment method from the confirmed setup intent

but isnt it a possibility that the customer needs to authenticate their card twice (once when adding it using setup intent and then when changing plan)

#

it may affect the user experience?

#

especially since there are cards that always require auth

#

ideal flow would be to only have the user authenticate their card once (either while making the payment or when adding the card using setup intent)

queen schooner
#

No I don't think so. SetupIntent is an agreement to charge later, including authentication. When you make the Subscription change it shouldn't ask for authentication again

lime crescent
#

hmmm alright, I'll test it

lime crescent
#

I just tested this with 4000002500003155 this test card (authenticate unless setup) and the invoice wasn

#

wasn't paid

#

card was created using setup_intent

queen schooner
#

Invoice Id plz!

#

Ah

#

After you confirm the setup intent, take the pm and set into the Subscription

#

then make the change normally

#

And don't set payment_behavior to default_incomplete

lime crescent
#

in_1KrGTLKHqIuz5QBfgdePZm1D

#

payment_behvaiour is set to pending_if_incomplete

#

i basically made the pm the default pm before upgrading the subscription

#

also would this card 4000002760003184 (test card that needs to be authenticated for all transactions) work with the above approach

#

hmmm

queen schooner
#

You tried multiple times with different cards, right?

#

Yeah cards behaves differently

#

sorry your concern was correct

lime crescent
#

hmmm yeah I guess I'll need to think about a workaround

queen schooner
#

there are cards that required authentication every single time

lime crescent
#

yes

queen schooner
#

those are not common tho IMO

#

but they are

lime crescent
#

ah yes that is true

#

thanks tho, I'll try thinking of something