#tamires_3ds-issuer

1 messages ¡ Page 1 of 1 (latest)

violet oysterBOT
#

👋 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/1227997040089366608

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

woeful oasisBOT
#

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.

mild moon
#

No the customer needs to authenticate the payment

#

But you should only need to set setup_future_usage once (when first collecting payment method details)

elder wraith
#

Before we were using the deprecated method charge create and although it's a deprecated api, it didn't have issues with 3DS cards. Is this something new somehow?

#

I am saying this because we have legacy card_id tokens from before the migration and these are the tokens we use for payment intent when we have a subscription charge coming through. During subscription I charges I don't have the customer present. How could they authenticate the charge?

mild moon
#

3ds isn't new, no. Provided the payment methods were set up properly, future off session charges shouldn't require 3ds

#

But it's possible

#

How were the payment methods created? Can you share a sample payment intent id where this issue is happening so I can examine?

elder wraith
#

yes pi_3P4KSSKIWnXaN5iw1fkGiERy

#

So this case is a card_id collected in the FE and attached to the customer. The first charges were done years before with the legacy api charge.create in our backend. Now we are re-using this card_id to "renew" this customer but now we migrated to payment intent.

#

We don;t collect charges on the FE, we just generate the card token in the FE and process all of the payment in the BE

mild moon
#

Do you still do that in the new flow?

#

If so, you shouldn't do this

elder wraith
#

so my FE calls stripe.createPaymentMethod and the pm token is passed to the BE. The BE then creates the payment intent by using the pm token

#

so either my new payments using pm tokens or the subscription one that have the legacy shape of card token fail for 3DS cards - but all the other payments are coming through just fine

mild moon
elder wraith
#

That is very challenging. I followed your whole documentation that walks me through the architecture of how to finalize payments on the server particularly for payments intent.

Even if I was to change the company's entire architecture, subscriptions would still impose a problem because they don't have any sort of ui.

#

Do you think you could walk me thorugh a solution at least for subscriptions?

mild moon
#

Oh you can still finalize payments on the server, but it's still a different flow from what you're using

#

^ is the recommended approach if you need to do it that way

elder wraith
#

Ok, yeah that is the documentation I sent earlier, that's how our server is doing. But the last step still indicates there is a need for UI anf for subscriptions charges I don't have the customer present nor any ui

mild moon
#

Well if a payment requires 3ds, you need to bring the customer in to a ui to verify

#

There's not a way around it

#

3ds is requested by the banks sometimes

elder wraith
#

can this be like a sms that they can confirm?

mild moon
#

But if the payment method was set up properly, this should be rare for future subscription payments

mild moon
elder wraith
#

like is this a notification on their phone?

mild moon
#

No 3ds is something that needs to be done in-browser

elder wraith
#

ok let me do some reading on this last link cos I didn't see this one until now. Last question though The legacy way we were using, the charge, didn't mentione anything about 3DS secure and we never got this step of needing customer interaction. I believe their card already had the feature but is it possible that the charge-api didn't account for it somehow?

#

so like nothing changed on the client's card. But maybe the charge-api wasn't "secure enough" to account for this feature?

mild moon
#

Normally if the issuer required it in that flow, you'd just get declines

woeful oasisBOT
patent sentinel
#

tamires_3ds-issuer

elder wraith
#

oh one more question: we have some payment intents pending because they are stuck in the "require_action" step but some customers switched cards and created a new already confirmed payment intent. What is your recomendation about the pending PI, is there any action we need to take - like cancel or "release" it?

patent sentinel
#

@elder wraith it depends what you call "pending" exactly. Do you have a concrete example I can look at?

elder wraith
#

the stripe dashboard show the status of that PI ID I gave you as pending

#

some customers are just switching CC so we have collected the pay with a different credit card and a whole different payment intent - a new payment intent was created.

patent sentinel
#

"that PI id" can you share the exact id so I can look without reading the whole thread?

elder wraith
#

pi_3P4KSSKIWnXaN5iw1fkGiERy

#

"status": "requires_source_action"

#

If we have no intentions to confirm, is there anything we have to do - like issue any requests to cancel it?

patent sentinel
#

In theory what would have been best is to keep that PaymentIntent and re-confirm it with a different card instead

elder wraith
#

yes, I realized that!! I'll bring it up to the team.
What happens if those intents are not canceled, do they have any sort of expiry?

patent sentinel
#

I think that attempt will expire a bit later (no idea on the time) but the PaymentIntent won't be canceled ever unless you do it. Best to clean up and explicitly cancel it!

elder wraith
#

Sounds good, I'll bring this up. Is there any documentation about unconfirmed PI?

patent sentinel
#

not really

elder wraith
#

can they be canceled through the dashboard?