#Morisha
1 messages ยท Page 1 of 1 (latest)
Huh interesting, can you share the customer portal URL?
you bet
๐
this is on test mode with a test clock btw
default card requires 3DS, stripe radar rules requires 3ds for all cards that support it
Testing with 4000002760003184 card, customer portal works fine ๐ค
Maybe it is an issue with that specific test card?
Hmm maybe, a bug or smth. I just checked out the test cards table didnโt know there was an Always Authenticate card
I was using the 3DS2 required card
Both behave the same for my test scenario I believe right?
It should, yeah. seem like a bug.
Where exactly did you find the 3DS2 3220 card?
I might be forgetting the correct location for this
Agh yeah it's right there ๐คฆโโ๏ธ
Let me double check with a colleague to confirm if this is a bug or I missed something ๐
yea for sure tyt
Just to make sure return URL is getting the right value set, can you print PROCESS.ENV.DOMAIN out before you create the portal session?
http://airbnb.test
Thanks for the ID, catching up and will check in to this
for sure thanks!
Hi there ๐ I'm trying to reproduce the behavior you're describing to take a closer look at what could be happening, but so far I've not been able to do so. I don't think I'm following the same steps that you are, and was hoping that you could provide some clarity on what actions you took that resulted in this error?
Hi toby!
Yea so what I did was:
- Create a test clock
- Create a customer and a subscription with the
4242424242424242card, and just cycle a few months (no issues) - Added another card
4000000000000341(decline after attaching) and set it as default, and cycle a a month or two (no issues) - Added a third card
4000000000003220(3DS2 required) and set it as default, and cycle a month and a week approx.
Here is when I went to the customer billing portal and it gave me the error.
I was testing for off-site payments that require 3DS in step 4.
Thank you for that clarification! I'll be quiet for a bit while I go work on testing that process, but will come back after I've done that.
yea for sure! tyt
i was able to replicate it again
with just steps 1 and 4
Hm, interesting, I'm not seeing the Requires confirmation tag in my customer portal instance the way I see it in yours, trying to see if I can figure out where the difference is coming from.
hmm I don't think it has anything to do with Stripe Radar rules right?
I don't think so
yea same
I went ahead and ignored the pay amount due button and just paid the invoice and it works
i don't think it should even show the Requires Confirmation Modal
Facing similar behaviour with the 4000002760003184 card (Always authenticate)
Thank you for your patience, I was able to reproduce the behavior you were describing, but only if the Invoice was waiting for confirmation and I tried to use an existing payment method (creating a new payment method in the Customer Portal always seemed to be successful).
I do think this is something that we will need to look into further, and I don't think this behavior is indicative of a problem with your integration.
great! yea, so imagine this scenario:
- Default Payment Method is a card that required 3DS for on and off-site payments.
- A recurring payment comes up and the bank sends a
authentication_requiredcode and then either me and stripe handle this situation by informing the user to authorize the payment - user can be sent the invoice directly and no friction on that, but lets say they decided to go to the billing portal, according to my testing they should see the
Requires Confirmationprompt right?
i'm not sure if this behaviour is present in Live Mode too
Yes, that is my understanding as well, that this behavior is dependent on whether the underlying Payment Intent is in a requires_action state.
Currently I believe this behavior is likely present in live mode as well, and have raised it to the appropriate team to be investigated.
Hmm interesting, yea well I hope I was helpful in getting this sorted out then ๐
Quick question, do you have any idea whether the 3D Secure Email that Stripe sends when an invoice/recurring payment requires further action contains a link to the invoice itself or the billing portal?
I'm not sure offhand, we primarily focus on helping developers work with our API so I'm not as familiar with our prebuilt email functionality. I want to say that we include a link to the Hosted Invoice Page in those, rather than the Customer Portal, but I'm not confident on that.
yea cause my reason is if it does direct a user to the portal then it might be confusing and the user might not go forward with it which equals loss of revenue, but it does make a bit more sense that Stripe sends a link directly to the Invoice but there's no way to make sure with Test Mode I guess.
Totally agree! Thank you for taking the time to raise this to us, and to walk through the replication steps with me!
yea of course, thank you for being attentive and engaged!