Stripe ConfirmCardPayment (frontend) vs paymentintent.Confirm (backend)

When would you choose confirmCardPayment in the front end and when would you choose paymentIntent.Confirm in the backend?

currently our app allows you to checkout as guest, save a credit card if you are not a guest or use a saved card.

All of these flows work without confirmcardpayment on the frontend and without the paymentintent.confirm on the backend

I'm guessing there will be a time where a card payment requires extra authentication and that is when we need to either confirm in the front end or conifrm in the backend? (Also, when/why would a card require extra authentication? New to this space and looking to learn)

Our code pretty much follows this: https://github.com/stripe-samples/saving-card-after-payment/blob/master/without-webhooks/server/go/server.go

PS: The TLDR from the above link is:

Front end:

• Creates a paymentmethod with a given card or saved card.
• Sends POST /pay API to backend

Backend:

• Receives API (validates if user is auth or not - in our case)

• Creates a payment intent to be sent to stripe with paymentmethodID from frontend AND customerID gotten from our backend (Stripe's customer id that we created beforehand)
  Stripe returns us the paymentmethod with status.

No confirmation on either front.

If same payment method tries to get used for another customer, fails.
If same payment method gets used for same customer (Saved card behavior) it works.

> I'm guessing there will be a time where a card payment requires extra authentication and that is when we need to either confirm in the front end or conifrm in the backend?

You need to do this on the frontend because of customer authentication yes. Confirming on the frontend attempts the payment, and the Stripe JS library will also present any additional UI needed like the customer's bank's 3D Secure authentication page.

That is also important for accepting other types of payment methods(which you should, as having more local payment methods in your checkout flow increases customer conversion). E.g., payments using iDEAL require a redirect to the customers bank which again is handled on the client side. https://stripe.com/docs/payments/ideal#payment-flow

> (Also, when/why would a card require extra authentication? New to this space and looking to learn)

Pretty much any transaction in Europe and the UK requires 3D Secure authentication right now, and it's only becoming more prevalent worldwide

https://stripe.com/docs/strong-customer-authentication

https://stripe.com/docs/payments/3d-secure

https://support.stripe.com/questions/strong-customer-authentication-sca-enforcement-date

>Our code pretty much follows this

The Github link/flow you linked is an alternative way of using Stripe where you attempt the payment on the backend and then need to do a round-trip if authentication is required , but it's generally preferred to use client-side confirmation as it's more scalable for accepting other payment methods. See the notes on
https://stripe.com/docs/payments/accept-a-payment-synchronously