#tannerhuynh_api
digital ivyBOT
đ 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/1328803946961309707
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
autumn flower
Hi, can you clarify if you're attempting to 'authorize' a charge meaning that the end customer's bank will hold the funds for the transaction then charge later? If not, can you add more clarity to what you mean by 'authorize'?
untold wadi
Authorizaton, meaning to check and verify with the issuer and put an amount on hold on a card. Not capture it yet.
My general understanding is that client SDK does all of this in a single request when confirmPayment is called.
autumn flower
Are you following this guide, https://docs.stripe.com/payments/place-a-hold-on-a-payment-method?
I think you're looking for the above
untold wadi
This authorization is not supported by all payment methods correct?
autumn flower
By passing capture_method: 'manual', you're essentially doing that.
Yes, you're right. We document that here: https://docs.stripe.com/payments/place-a-hold-on-a-payment-method#auth-capture-limitations
untold wadi
Am I also correct in assuming that this type is authorization can only be done server side? I do not see any additional notes regarding the Client SDK.
autumn flower
If you're using the Elements without creating the PaymentIntent first on the server-side, you can pass it in the CaptureMethod: https://docs.stripe.com/payments/build-a-two-step-confirmation#additional-options. You would still need to specify this on the PaymentIntent creation request later.
However, if you're creating the PaymentIntent first, there is not anything else you'd specify on the client-side no.
untold wadi
So is capture method equivalent to authorization? I thought that capture = charging the card?
autumn flower
Let's back up. You mentioned 'Authorizaton, meaning to check and verify with the issuer and put an amount on hold on a card. Not capture it yet.'
Capture is not equivalent to authorization.
With the above alignment, can you re clarify what you're really asking?
untold wadi
So by default, Stripe authorizes cards (puts funds on hold). I think I am trying to understand "when" this happens (which methods cause this) and whether we can trigger it manually versus letting the SDK automatically handle it on the client side. I am aware we can do this server side now, but trying to address the client side SDK for our current configuration and the documentation is a bit light on this matter.
autumn flower
I think you may be referring to something else here and not putting a hold on the account for the amount. Our standard authorization refers to checking if the card has enough fund for instance. We talk more about this here: https://stripe.com/resources/more/card-authorization-explained
untold wadi
Yes, I'm referring to the standard authorization.
I don't know exactly what happens during this automatic authorization, but I am curious if it can be called manually, or if its just offered up as part of confirming the payment intent.
autumn flower
I see, in this case different calls will trigger authorizations. These are called validation authorizations and are pertinent to card payment methods. These validations happen when:
Attaching a card to a Customer upon Customer creation
Confirming a SetupIntent
Attaching a PaymentMethod to a Customer
Updating the AVS information for a saved PaymentMethod
Please note that we use machine learning to decide on whether we run these card validation authorizations in order to combat card testing: https://support.stripe.com/questions/check-if-a-card-is-valid-without-a-charge
untold wadi
I see, so only those four scenarios will trigger authorization based on your ML models.
autumn flower
Yes!
untold wadi
Attaching a card to a Customer upon Customer creation
Attaching a PaymentMethod to a Customer
I do want to probe more on the above two scenarios for the client side. Is this part of vaulting a card (createPaymentMethod)? We have Signifyd fraud check which requires pre-auth (prior to authorization). Part of this fraud check flow, we need to vault the card before we call Signfyd. I'm hoping those two scenarios above aren't part of this method call to vault the card, which would trigger authorization too early.
Basically trying to clarify that the frontend SDK for createPaymentMethod and the attaching of a card (v1/payment_methods/:id/attach) are not the same in terms of authorization.
autumn flower
These are not the same. You can create the PaymentMethod (no validation at this time), and then you attach the PaymentMethod to the customer (validation)
untold wadi
Okay, awesome! Thanks for the clarifications. It seems that standrad authorization isn't always going to happen and only in some cases. Also that we can't actaully authorize anything manually on the client side.