#SudoPlz-pi-confirmation

1 messages · Page 1 of 1 (latest)

elder pumice
#

Hey! The confirm can be passed on creation to confirm automatically on creation. This is generally useful in cases of off-session payments. In most integrations, you'd confirm on the client with confirmPayment so that any required 3DS/auth can be completed

unique vector
#

@elder pumice does that mean that for on session charges we need to use confirmPayment on the mobile app in order to fullfill 3DS/auth but for off session charges we're ok with confirming on the backend?
Are there any drawbacks of always confirming on the backend, a.k.a never actually 3DS/auth?

elder pumice
#

Well if you passed confirm: true on creation and 3DS was requested, then the PI status would reflect that (i.e. requires_action). Which is where confirmPayment comes in

#

Obviously in off-session instances, there's no customer to carry out required 3DS so it would just fail

unique vector
#

got it, would that ever happen if the transaction is marked as moto? (3DS being requested?)

elder pumice
#

Shouldn't be no, as MOTO transactions are SCA exempt. So you'd pass confirm: true on creation

unique vector
#

Got it, you're the best, that all makes sense.

1 final question, I promise:

I noticed the create payment intent endpoint returns:
requires_confirmation as well as requires_action.

Do I need to confirmPayment when any of the above is returned, and what is their difference? I didn't find that in the docs.

Thank you ❤️

elder pumice
#

requires_action means 3DS/auth was requested, which is what confirmPayment handles

#

requires_confirmation is basically server-side confirmation (confirmation_method: 'manual'). not recommended