sweetpotato8776

[thick gyro]

Your site suggests using stripe.confirmPayment like this.

This method involves the entire process from approval to capture.

Do I understand that correctly?

[keen yew]

Hello 👋
What's your usecase exactly? When you say

is there a way to first check whether the card can be accepted and then complete the payment?
Are you trying to block certain cards?

[thick gyro]

Before putting order data into the database, I want to check first whether payment is possible.

i insert data into the database after i call confirmPayment at front.

in this process, If an exception occurs while inserting into the database,

As far as I know, you have to call the refund API.

[keen yew]

Okay so taking a step back, what you really want is to wait to insert data into your database until you know the payment succeeded/failed

You should implement a webhook that sends relevant events to your server
https://stripe.com/docs/webhooks

[thick gyro]

Can I use what you told me with stripe elements?

Can you explain the sequence of the process you consider?

[keen yew]

Yes, you can build a webhook for elements.

The guide here covers this step by step
https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=elements#web-create-intent

Webhook section
https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=elements#web-post-payment

[thick gyro]

i think if i call confirmPayment, entire process from approval to capture is occured.

[keen yew]

Yes

[thick gyro]

then, it's not resolved. because if our site has trouble, i call the refund api as ever

If there's a problem with our site, you don't want to processing pay.

[keen yew]

What sort of problem though? Are you concerned about declines?

[thick gyro]

Like a problem with our server down.

We receive the card number, but if an error occurs while entering it into the database,

I hope the payment doesn't go through

In the case of PayPal, there are two steps: approval and capture. Don't you have something like that?

[prisma river]

You can switch to this flow if you want to make sure your server is the final thing that is confirming the payment https://stripe.com/docs/payments/finalize-payments-on-the-server

good point, you can also place a hold on certain PaymentMethods https://stripe.com/docs/payments/place-a-hold-on-a-payment-method

But keep in mind that not all payment methods support holds.

but any which way, you should definitely impliment webhooks and listen to them for redundancy

[thick gyro]

Can you explain in detail what process you use the webhook for?

i don't follow..

.setCaptureMethod(PaymentIntentCreateParams.CaptureMethod.MANUAL)

as far as i know there are payment methods that do not support this method.

[prisma river]

Webhooks serve a few purposes, often they are used so that you can wait on things to happen rather than constantly making get requests to see when a certain object updates.

Webhooks also offer redundancy. With the client-side confirmation flow that you are looking at, it is possible for a user to submit their payment and then lose internet connection before their device hears back about the result of the payment. Even if that happens, Stripe will send your server webhook events about the payment. Stripe will resend the events until your server acknowledges that it successfully got the event, so even if your server is down temporarily it will get these events after it comes back online.
https://stripe.com/docs/webhooks

[prisma river]

Correct. Only some payment methods support this. So you can do manual capture if you don't want to move to our "finalize on server" flow but you will be limiting which payment method types you can use