#soto-prepaid
1 messages · Page 1 of 1 (latest)
Hi there! Mostly HSA/FSA is dependent on your MCC for whether those cards are supported. I'd recommend talking more to our Support team about MCC and HSA/FSA support specifically: https://support.stripe.com/contact/login. We don't have a lot of recommendations on pre-paid cards in general... they shouldn't really behave differently than credit cards in terms of failures. Do you have an example PaymentIntent where you are seeing the PaymentIntent succeed but the card fail? I'm not sure what exactly you mean by that but an example may help
Yes I do. For instance if I use a prepaid card with 0 balance, the payment still will go through but then the card is declined, which does not happens with a normal debit or credit card.
It is hard to reproduce this because the only way I can do it is with the production site, since I don't have a staging prepaid card failed number.
Do you have a production example?
What do you mean "the payment goes through but the card is declined"?
Declines are synchronous
So payment would fail if there is a decline
Well actually in this case, create a subscription and attach the payment method to the subscription.
If I attach a normal credit or debit card, the failure is catch with the subscription creation, however if I attach a prepaid card it does not catch the decline.
That is not true so you must be doing something different here.
By bad here, I didn't specify subscriptions for this case.
Credit vs. prepaid functions exactly the same in that both will run a check with the issuer when they are attempting to be authorized and then we will succeed or fail the payment based on the issuer's auth or decline.
I'm happy to help troubleshoot if you are seeing differing behavior but actual examples would be really helpful here.
the thing is that I am struggling to test since I don't have a staging prepaid card
You can also find prepaid card examples in our test card docs: https://stripe.com/docs/testing#cards
5105105105105100 for instance
But that really shouldn't matter here.
That one doesn't work because it is a card for successful cases, I need one for decline cases, just like this one 4000000000009995 (insufficient_funds)
but this one does not work because it is not prepaid
Okay yeah we don't have a specified prepaid decline card.... but the behavior should be no different than any of the decline cards.
that's what I don't understand, because we have had cases in which the behavior changes, at least with our setup
this situation only happens with prepaid cards.
Are you using a SetupIntent?
nope, I am using subscriptions.
Sure but how are you collecting cards?
Like are you collecting them and attaching to a customer ahead of attempting payment?
Can you share an example subscription that I can look at?
There is likely a different reason here that you are misconstruing with prepaid being responsible
I'll share with you the process, just a minute
got it
So it is an HTTP request and these are the parameters
We update the customer payment method
Then we create the subscription
Can you provide a Subscription ID from one of your tests that I can look at?
sure thing!
is a fixed amount of 10$ off out of a 30$ fee
Got it
Subscription ID sub_1Knr0jIOU333jqng7MEHCiVr
Okay so I have a hypothesis of what is confusing you
In your flow you collect a PaymentMethod and attach it to your Customer object in order to set the invoice_settings default.
When you attach PaymentMethods to Customers, sometimes a card validation is triggered. See: https://support.stripe.com/questions/check-if-a-card-is-valid-without-a-charge
So my guess is that you are misconstruing times where that validation is skipped, and then the card eventually fails on the Subscription payment when a card validation is always done, with prepaid being the reasoning.
Whereas really this can happen with prepaid or credit regardless.
Got it!, that helps a lot!.
Thank you so much @vivid herald . This is really helpful. Once I finish solving the issue I'll get back to post the solution that made the trick. 😅