#andrew-mackay_best-practices

1 messages · Page 1 of 1 (latest)

lunar lilyBOT
#

đź‘‹ 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/1405463681843597372

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

upbeat knoll
#

For this, I generate a customer session and a new setup intent and pass this to the stripe elements component. Is this best practice? My concern is that the payment method is already saved in our system so there is no point creating a setup intent and saving it again.
As you said, this is for reusing an existing PaymentMethod or collect a new one, the created SetupIntent is for collecting a new one

#

To avoid creating a Setup/Payment Intent, I think you can use confirmation tokens

#

Following this flow, you can collect new PaymentMethod or allow your customer to collect a new one, then create an Intent if needed

north smelt
#

Hi, thank you for your help! so to clarify, you are suggesting that instead I

  1. Generate the customer session and set it on the stripe elements
  2. After doing elements.value.submit();, I would then create the confirmation token which then gets passed to the server
  3. On the server I would retrieve the confirmation token using https://docs.stripe.com/api/confirmation_tokens/retrieve. At this stage, if the customer had selected an existing payment method, would the payment_method field be set? Depending on if payment_method was set I would either do nothing or create the setup intent?
  4. I would then call from the client
    clientSecret,
    confirmParams: {
      confirmation_token: '{{CONFIRMATION_TOKEN_ID}}',
      return_url: 'https://example.com/order/123/complete',
    },
  });```
 but what would I do in the case where I didn't create a setup intent?
upbeat knoll
#

At this stage, if the customer had selected an existing payment method, would the payment_method field be set? Depending on if payment_method was set I would either do nothing or create the setup intent?
Yes exactly

#

but what would I do in the case where I didn't create a setup intent?
You charge the existing PaymentMethod I imagine ? It depends on the flow, what should be the user journey, if they choose an existing PaymentMethod ?

#

I would then call from the client

  1. you can do it in the backend too
north smelt
#

Ah okay, so in the case of the existing payment method being present, there is nothing left to do except our own business logic?

This all makes sense however it would be a reasonable change to our existing system. Just so I understand a little more,

  1. What would be the downside of simply creating an additional setup intent? This would mean the only change we need to make is generating a customer session.
    2.What would be the drawback if we were to just handle the re-use of an existing payment method outside of stripe elements? I'm thinking we could add a button along the lines of "use my existing card ending in xxxx" that doesn't use the stripe elements at all? Is the advantage of using the elements here that it would check if the card is still valid or is it more to do with the displaying of saved payment methods?
upbeat knoll
#

Ah okay, so in the case of the existing payment method being present, there is nothing left to do except our own business logic?
Yes

#

What would be the downside of simply creating an additional setup intent? This would mean the only change we need to make is generating a customer session.
Nothing, just pending SetupIntent will remain in your Stripe Account

#

2.What would be the drawback if we were to just handle the re-use of an existing payment method outside of stripe elements?
Nothing to, you can handle that using your own UIs.

#

Is the advantage of using the elements here that it would check if the card is still valid or is it more to do with the displaying of saved payment methods?
No, no check will be done on the PaymentMethod it self (maybe just the expiration date? not sure honestly). However the advantage, is that will be in the same UI/UX

#

Otherwise you can use your own UI

north smelt
#

Nothing, just pending SetupIntent will remain in your Stripe Account
Just to check my own understanding, will the setup intent not be "succeeded" instead of pending?

upbeat knoll
#

In case the customer choose an existing PaymentMethod, then no need to confirm the SetupIntent, thus it will remains pending

north smelt
#

Ah I must have misunderstood, so in the case of doing

  1. Generate customer session on server, return to client and pass as option to stripe elements
  2. On confirm payment:
await elements.submit()
const setupIntent = await createSetupIntent() // Request to the server to create setup intent, returns setup intent client secret
stripe.confirmSetup({
  elements: elements,
  clientSecret: setupIntent.clientSecret,
  confirmParams: {
    ...
  }
})

If the customer selects the existing payment method, it won't be used against the new setup intent?

upbeat knoll
#

When the customer selects an existing payment method, simply don't confirm the setup intent

#

And move forward to your business logic

north smelt
#

So instead of having to change our flow to use confirmation tokens, I'm wondering if there are any drawbacks to just creating a new setup intent and that can either be used with the existing payment method or the new payment method. In the case where they re-use the existing payment method I guess that payment method will then have been used by two setup intents, the orignal when making the booking and then this new one

lunar lilyBOT
upbeat aspen
#

Why would you need a new Setup Intent for an already existing pm_xxx generated by a SI previously? That is redundant

#

For this, I generate a customer session and a new setup intent and pass this to the stripe elements component. Is this best practice?
If you use the deferred flow, then you'd defer the SI creation until after the provide the new card details, whilst still maintaining the UI for them to select their existing saved card(s) via the Customer Session

https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=setup