#delgesu1745
next halo
restive dawn
req_gTqgtHhdZfBakN
I thought setupintents were not supposed to attempt to charge the card but save for later.
limpid stream
Seems like the card was declined. We do validate the cards when attempting to save. And often that creates $0/$1 authorization charge (which is then refunded after validation)
https://support.stripe.com/questions/unexpected-1-charge-on-customers-bank-statement
restive dawn
So how is setupintents different from paymentintents then?
limpid stream
SetupIntents don't really charge an amount, they place an authorization which is released. This is to make sure that the card is valid and is attached to a real account.
PaymentIntents require an amount to be passed in.
restive dawn
Gotcha. Ok so what should we do then if a setupIntent fails? We are also trying to attach the payment method to the customer to have on file for invoice processing. Can we still do that if setupintent fails?
I'm a bit unclear as to why we can't just create a customer and then attach a payment method to that customer from a card capture on our site.
We tried just doing that with no setupintent, but it was failing.
Kept getting card decline errors.
limpid stream
No, it's likely that the subsequent charges on that payment method would fail since it failed the authorization. If SetupIntent fails, you'd likely want to ask for a diff payment method and have the customer talk to their bank to see why this was declined.
I'm a bit unclear as to why we can't just create a customer and then attach a payment method to that customer from a card capture on our site.
We tried just doing that with no setupintent, but it was failing.
Kept getting card decline errors.
Yeah exactly, if you save even if the SetupIntent fails then there's a higher change of subsequent charges to be declined too
restive dawn
Right, but if they just need to autorize with thier bank or something for that card, we don't want to have to recollect the card.
So can we actually just create a customer and then attach a captured payment method to the customer without having to actually charge an amount?
Do we really even need the setupintent?
We process all our payments via invoices.
limpid stream
But we don't know that right? Bank could've declined for various reasons.
Do we really even need the setupintent?
We process all our payments via invoices.
Do you send the invoices manually or are you charging the payment methods on file?
restive dawn
Charging the payment method on file.
restive dawn
But we don't know that right? Bank could've declined for various reasons.
> Do...
Right, but either way, we'd rather have them check with the bank and try and resolve rather than reachout about collecting a new card.
limpid stream
Charging the payment method on file.
In that case, you do need SetupIntents to save the payment method on file in the first place.
Right, but either way, we'd rather have them check with the bank and try and resolve rather than reachout about collecting a new card.
That's a risk you're taking as a merchant. But if you're okay with that then I believe our support team can help with disabling authorization charge with SetupIntents.
restive dawn
It seems that we were getting declined errors even when we just created a cusomter and attached a payment method. Why would that be? Does it try and authorize when you add a payment method to the customer?
I'm trying to understand whether we need to use setupintents at all.
Good to know in disabling though if we're good with that.
limpid stream
It seems that we were getting declined errors even when we just created a cusomter and attached a payment method. Why would that be? Does it try and authorize when you add a payment method to the customer?
Yes as I explained earlier, SetupIntents may create an authorization charge in order to make sure payment method is valid. This is done to avoid future declines (after you save the payment method and try to charge the customer).
restive dawn
Right. So if we don't care about that check then we could skip the intent and just attach the payment method to the customer?
Or does that also do a check?
I think it was because I kept getting 402 errors
limpid stream
We don't allow sending raw PAN (card numbers) to the API. In order to tokenize the PaymentMethod and set it up for future usage, you'd either use a SetupIntent or a PaymentIntent with setup_future_usage parameter.
PaymentIntent would expect you to pass in an amount (so this flow is for saving the payment method while charging the customer)
Hence you'd need to use the SetupIntent. You can't skip it since there's no other way to tokenize the PaymentMethod and set it up for future usage without it.
If you reach out to our support, they can help with skipping authorization charge with SetupIntents
restive dawn
Ok gotcha. I've gotta check with our implementation team to see if they are tokenizing the payment method via the setupintent or some other way. I thought I was a token for the payment method created when capturing the card, not on the setupintent, but I must be wrong.
limpid stream
Yeah would recommend double checking..
The ideal way here as a merchant would be to just ask for a different payment method to avoid delays in completing the sale/payment (the delay introduced by customer talking to their banks and figuring things out) as well as non-validated payment methods affecting on your decline rate.
But yeah, upto you 🙂 feel free to reach out to support and they can help provide more context on the workarounds
restive dawn
Yeah, it would be best to know at capture if there's going to be any issues.