#piyush_docs

1 messages · Page 1 of 1 (latest)

elder sleetBOT
#

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

📝 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.

steel sail
#

Hello, this depends on what you pass for proration_behavior, by default we update the subscription immediately and create invoice items that get added to the next invoice when the subscription cycles. If you want to charge immediately, you can pass proration_behavior='always_invoice' and if you want the upgrade to wait for the payment to succeed you can use our pending update functionality

cunning nest
#

yes, i want to charge immediately that's why i am passing it as always_invoice, but does that mean the charging is synchronous(i mean when the update call returns it contains the result)?

#

this is the nodeJS code if you require
await stripe.subscriptions.update( subscriptionId, { payment_behavior: 'pending_if_incomplete', proration_behavior: 'always_invoice', items: [ { id: subscriptionItemId, price: priceId } ] } )

steel sail
#

For synchronous payment methods I think so but I am having trouble finding it explicitly documented. Can you try this out in test mode and let me know what the result is? Our test mode will simulate this logic correctly, so it will be synchronous here if it is synchronous in live mode

cunning nest
#

which payment methods are synchronous btw? i am not aware of it, i've enabled cards with apple pay and google pay

steel sail
#

I'm not finding a doc that lists this for each PM overall, so I think you may need to check the docs page for each PM you want to use here. Cards are synchronous, most bank debits are asynchronous, beyond that I forget off the top of my head. The difference is basically whether the bank or whoever Stripe has to reach out to responds instantly with whether the payment succeeds or if it can take ~days. Those are what we call asynchronous payment methods and the payment intent moves into a processing state while we are waiting to hear back on the success or failure.

cunning nest
#

what about amazon_pay? i have heard it being async despite the charge not taking more than 30 sec at max

steel sail
#

From the Stripe docs for it, it looks like we say the intent goes straight to succeeded so I think it is synchronous

cunning nest
#

so is the redirect based and asynchronous are two different things, am i messing up?

steel sail
#

Yes, but that does raise a good point about something else you have to keep in mind here. Redirect based refers to the fact that users have to be redirected in order to submit their payment details. This makes the intent go in to a requires_action state until the user has completed their action.
Asynchronous refers to what happens when all payment details are submitted (so after that requires_action step if applicable). For synchronous payment methods, the payment will either immediately succeed or be declined and will go into the relevant state. For async, the intent goes into a processing state while we wait to hear back.

#

The good point that that brings up is that some of your payments will go into a requires_action state which means you need to bring your user back to your site or app so they can complete that step.

#

So when you make this update, we will immediately attempt the payment and there are 4 things that can happen there:

  1. The payment immediately succeeds, and the upgrade happens
  2. The payment is immediately declined, no upgrade yet
  3. The payment intent goes into a requires_action state, the customer needs to come back online to complete next steps.
  4. The intent goes into a processing state, no action needed for now, you will get an event later with info on whether the payment succeeded or failed.
cunning nest
#

i am using cards only, will 4 be applicable in this case

steel sail
#

Nope, cards are synchronous so only 1-3 apply

cunning nest
#

okay, last one, want to ensure if synchronous is actual synchronous or not🙂 the status of payment will be there in update call's returned value, right?

steel sail
#

You can pass expand: ['latest_invoice'] to get the full invoice object and its status back, but unfortunately I don't think there is a good way to get the payment intnet's status so you may have to retrieve it to get further detail on whether it is processing or not

cunning nest
#

processing? How it could be in that state with PM types i've configured, you said it's paid or failed when update returns

elder sleetBOT
steel sail
#

Sorry working in a lot of threads right now and I forgot that. Though you would need to check that for requires_action

cunning nest
#

Nw and yes that i get for 3rd point(from the 4 you mentioned above) but for first 2, it's either paid/failed state when update returns, right?

steel sail
#

Kinda, the invoice will either be paid which covers scenario 1 or it will be open which could be 2 or 3