#boggerrss
steel valley
obsidian torrent
Hi!
Currently I am using a card element yes
Then firing a request to my backend which returns the client secret for the payment intent
The payment intent is set to 'setup_future_usage' => 'off_session',
I have tested this on my own live stripe account and it worked correctly but some other stripe connect users on our platform are having issues
Just trying to give as much info as I can 🙂
tropic iris
What kind of issues?
Could you please share the PaymentIntent ID pi_xxx?
obsidian torrent
Ah sorry yes I didn't state the issue
When the client secret is returned to the frontend and handleCardAction method is executed the modal doesn't display
The intent id is: pi_3NXkMEK29uYRXACN0lXBo5wC
tropic iris
Do you see any issues in the console in your browser?
obsidian torrent
No sadly not - the network tab isn't showing any invalid labelled requests either
I can also confirm there is no try catch possibly surpressing the error too
tropic iris
The Card Element should handle the 3DS on it's own actually
obsidian torrent
Are you saying I don't need handleCardAction to process the secret?
tropic iris
Yes, no need to do anything extra. Just confirmCardPayment/confirmPayment
obsidian torrent
This is after the payment intent is generated in the backend correct?
tropic iris
Yes, you return the secret to the frontend, have the customer fill out the form and submit, then you call confirmCardPayment/confirmPayment.
Card Element is quite outdated though, there's not much docs to demonstrate this. But you can take a look at the new Payment Element, that's the default for custom integrations now: https://stripe.com/docs/payments/payment-card-element-comparison
obsidian torrent
Is this visually the same? - Never mind I can see this is split and single line mode which is fine
I'm just confused as to why this works for some people and not others
tropic iris
So what happens after you call the confirmPayment?
obsidian torrent
That method isn't being used we are using handleCardAction and only doing so when the backed instructs the frontend that action is required via the intent status returned
In the example the modal isn't showing the backend is definitely instructing the frontend to execute the card action as there is a visual indicator triggered for this
It was my understanding that handleCardAction was required when the payment intent status is set to requires_action
And that confirmCardPayment is required when the status is set to requires_capture
tropic iris
Not quite.
Are you collecting payment details on the frontend? Or are you using saved Payment Methods?
You can go through this guide to understand the complete flow. It's using the Payment Element, but the principles are the same: https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=elements
obsidian torrent
We are collecting the payment details on the frontend.
stripe.createPaymentMethod is executed
The ID of that payment method is then sent to the backend and linked to the payment intent
That response is then returned the frontend with the client secret where required and handleCardAction then processes the 3D Secure check.
Upon success of the 3DSecure process it then fires an request to the backend to confirm the intent since its set to manual
tropic iris
I think your flow is a bit more complex than it needs to be. I suggest you to go through the guide. If you follow the steps carefully, it should solve the issues you have at the moment.
fair abyss
Hi there 👋 taking over as my teammate needs to step away soon, bear with me a moment while I catch up.
Alright, sounds like you're not seeing the 3DS modal appear when calling handleCardAction? Am I understanding correctly?
obsidian torrent
Hi toby,
I believe my flow might be complex as described but it does work
our UAT environment with all 3DSecure test cards shows the modal
On our live environment I did a test earlier today on my own stripe account that is linked to our company via stripe connect and that has worked also showing my HSBC 3DSSecure window
But yes thats the case
fair abyss
Gotcha, alright so this worked as expected in test mode, but now you're seeing something different in live mode. For clarity, is the modal appearing but remaining blank, or is it not appearing at all? From what I can see in the logs so far for that intent, I'm not seeing evidence that 3DS was attempted, so I'm trying to get a feel for how far the process got before it stopped.
obsidian torrent
So the payment intent was created I believe you can see that
Then the client secret is returned from our backend, I've included a partial screen shot from dev tools
The modal just doesn't appear
fair abyss
Hm, normally I would expect to see some sort of error in the console or network logs if handleCardAction couldn't run, trying to think where else to look.
obsidian torrent
Can I provide you with a payment intent ID that did work through the same code today?
Maybe the logs between the two could shed some light
pi_3NXj9BIC7gXM1uxn1lTQbbl1
fair abyss
Hm, I don't think I'm going to see much difference, for the one that isn't working I don't see any logs other than the creation request, so there isn't much to compare against.
Do you have a site where you could run stripe.js commands from the browser console?
obsidian torrent
Yes I've just done that with the client secret provided in the response and it did open the 3DSecure window
Its not gonna be CORS or Same Origin or something is it, these payment forms are embedded onto our clients site
This was from the parent window of the embed presumably though, since console will be executing commands outside of the iframe
fair abyss
CORS issues would be thrown as errors in the browser console, I'm pretty sure. Hm, it working as expected when you run the command directly make this more confusing. Can you try again in the site that has the problem and double check whether any errors are thrown?
obsidian torrent
Of course would you recomment maybe pushing a quick update to console log the error in handleCardAction promise ?
Or would it throw the exception either way
by that I mean
await window.stripe.handleCardAction(
secret
).then(async function (result) {
console log result here
}
})
fair abyss
Yeah, I think that would be a good idea, you'll want to make sure any possible errors aren't going unnoticed.
obsidian torrent
Thanks for taking the time to do this by the way it does seem like a strange issue
CICD just triggered so will take 2 mins
fair abyss
Happy to! Agree this is a weird one.
obsidian torrent
Aha I'm getting somewhere.
This is thrown in a catch inside the then before the catch is the handleCardAction
This only seems to appear when the payment form is embedded on an external site.
Now I understand this probably isn't a stripe issue it is same origin policy, although I know this isn't what you're here for is this the customers site where the form is embedded being the issue?
fair abyss
That I'm less certain on, is dash.cartfuel.io your payment form?
obsidian torrent
dash.cartfuel.io is the host website
We produce payment forms that users can then embed onto their sites and collect additional information etc.
The site the issue is displaying on is a customer who is trying to embed the form
cloud front is our CDN
fair abyss
Gotcha, I'm not exaclty sure of the cause, but it does sound like there is likely a concern with how that is being embedded then.
obsidian torrent
Yes it would appear that way, thanks for all your help does look like we've narrowed it down now, thankfully don't have to change the whole flow 😄
fair abyss
Happy to help! Best of luck ironing out that last wrinkle.