#johan
lost cliff
the card is a MasterCard
floral totem
Hi! Let me help you with this.
Could you please share an example PaymentIntent ID? pi_xxx
lost cliff
sure we're using setupIntent to add paymentMethods off session seti_1MtTDuGn4NNxlFpMrChgQlZV
azure dirge
in that specific example it's that the bank rejected the attempt to do 3D Secure on the card. The customer needs to contact their bank to investigate if there's a problem with their card or the bank's 3D Secure server, or use a different card to pay.
if it helps as part of the internal error message the bank returns(we don't expose this in our API yet), they return this message intended for the customer.
"cardholderInfo": "Transaction has failed.<br/>Please call us on +353 1 4885466 for more information.",
the specific error code they return in the 3D Secure spec means
Transaction not permitted to cardholder which just means something like the bank has blocked that customer's card or something, we don't really know anything else.
lost cliff
Perfect yeah thanks a lot this will be very useful
we thought it was very weird and it might not be bank related because the issue is coming up multiple times in the past few weeks
have you guys get similar requests from other people related to the same issue we're having? specifically to that bank?
azure dirge
not that I know of but that's not something my team works with or that we track
wind walrusBOT
lost cliff
we pointed a few of their customers to their banks but their banks are sending them back to us and told them that it's an error in our integration which I don't think it's true otherwise we'd have thousands of people reporting the problem
it's for a specific number but it's becoming a bit frustrating for the CS team as they think it's us
if you guys have more information that can be useful please share it here
azure dirge
if you think you're seeing some sort of trend across multiple cards you could write a detailed mail to https://support.stripe.com/?contact=true with multiple specific examples so we could see if there's anything to find.
I don't see anything unusual about how you call the API here, it's a normal integration. The only thing I note is that in this example the card seemingly belongs to the same person who is the merchant(the connected account). That in itself doesn't mean anything but for example maybe it's part of a some signal for the bank thinking this is fraud and blocking it. That's complete guesswork though, only the bank knows why they blocked the 3D Secure attempt.
lost cliff
yeah
this might be something
so there are two ways of adding cards, our customer can do it for their customers
or our customer customer's can do it themselves
but this hasn't caused any issues so far
azure dirge
the merchant(the connected account) adding the card doesn't make much sense to me. It means the connected account is seeing that person's credit card number directly so they can type it into Elements or something? For example, if 3D Secure is required what happens? Is the customer's customer expected to tell the connected account the value they get in an SMS from their bank, or to use their bank app and approve the transaction and let the merchant know? That's not really how things are meant to work.
lost cliff
yeah this happens when they want to sign up to a new product and they don't know how to do it themselves, they go and ask help to the merchant (the connected account) and the merchant adds the card for them. then the customer will provide the challenge in case the 3D secure is required.
azure dirge
That is quite.. unusual and not really how I'd recommend building a payments integration. The recommended path would be
-- end-customer enters their own details on a payment page on your website/Stripe Checkout etc. If this has to be done in person maybe have a QR code they can scan on their personal phone to get to the payments page and do the payment/saving of the card. i.e. our normal documented payment solutions; that's mostly how this would always work. Our product suite is designed for the end-customer to use and they use the payment page and do 3D Secure etc.
-- if you have a use case where you have phone agents taking details from customers, and you understand the PCI implications, you can integrate with our API to do "MOTO" payments that are usually exempt from 3D Secure (https://support.stripe.com/questions/mail-order-telephone-order-(moto)-transactions-when-to-categorize-transactions-as-moto ) if your account has access to that feature(you need to ask support for it)
I have to run unfortunately but @languid hill can help with any follow up questions
lost cliff
ah this is great, I'll take a look at these docs thanks a lot for your help!