#kabala_unexpected
inland patioBOT
👋 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/1341472149264928902
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- kabala_api, 13 hours ago, 11 messages
last zodiac
Hi! That card requires 3D Secure on every payment. It is always possible that the issuing bank may require the customer to come back to do 3DS.
lunar edge
Is that common? I can't imagine a service like Netflix repeating 3DS every month
I'm hoping cards like 3155 are the common real world behaviour.
last zodiac
It's possible, which means you'll need to be able to handle that situation.
Is it likely to happen often? Probably not - but it's not impossible which means you either have to have a flow to handle it, or accept that in those cases things will fail.
lunar edge
is there any way to avoid repeat 3DS without the cardholder getting involved?
I'd really want to set up a subscription once and not need to reach out to the cardholders to reauthenticate the 3DS
inland patioBOT
last zodiac
No, that would defeat the point of 3DS.
lunar edge
The cardholder would be authenticating the series of payments (subscription) with the first 3DS challenge authentication
I don't understand why a repeat 3DS would be required if this is all part of the same subscription
last zodiac
I understand that, but that's how 3DS works. You may, at any time, be called upon to bring the customer back to prove you have permission to charge them.
north zenith
hi! fyi i'm stepping in to take over this thread as my colleague has to run
north zenith
but yeah, just to restate what timebox already said, whether or not a 3DS challenge occurs is entirely determined by the issuing bank, so there's not much you can do on the stripe end to reduce your chances of it. it's always going to be important to handle cases where customers will need to re-do a 3DS challenge mid subscription. obviously you don't need to handle it, but then you'll run the risk of losing subscriptions
lunar edge
I worked in card payments a while back so I'm a little rusty but I recall the 3DS process happens before the authorisation request is sent to the card network so the 3DS result can be sent in the 0100 auth request. In the case of recurring transactions there shouldn't be any need to go to the ACS before the auth, so I'm not sure where the request to perform 3DS is coming from for the next invoice in the subscription
I am rusty... it's the DS before the ACS but same question, why would you consult the DS for a recurring payment knowing the card is a card on file?
north zenith
that is an excellent question, and it's also getting a little bit beyond the scope of my expertise 😅 let me chat with some colleagues to get their thoughts on this
lunar edge
ok, thank you
there's also this link that might be useful https://www.emvco.com/whitepapers/emv-3-d-secure-whitepaper/recurring-and-instalment-transactions/business-overview/
viscid quartz
Hello
Jumping in to help out 👋
3184 card is specifically designed to require 3DS auth regardless of the transaction type. Meaning it will prompt for 3DS even if it is CIT (Customer initiated transaction) or MIT (Merchant Initiated Transaction) or a recurring transaction.
Depending on how you're attempting to charge the card, we'd pass appropriate information to the issuers.
For example, for subscription payments - we'll flag the payment as a recurring payment when sending data to the card network.
It is upto the issuers to approve/deny/require auth based on the received request and we have little to no control over it. Stripe will just relay the same information/next actions based on what we receive from the issuer.
In short, 3184 is a special card that triggers 3DS auth regardless of the payment type
It doesn't 100% reflect real world behavior with Cards <> 3DS <> Issuers
lunar edge
Hi Hanzo
viscid quartz
Additionally, we do generally recommend that you listen to webhook events in order to be notified in case things don't go the way you expect.
https://docs.stripe.com/billing/subscriptions/event-destinations
lunar edge
Thank you, this was my suspicion, I was confused about the behaviour of card 3184, it was flagging up in our tests as something that should approve but did not.
now I understand it will always send the same response and this isn't something we should expect as normal in the live environment
viscid quartz
Correct
lunar edge
excellent, thank you again