#Taylor Cooney - Payment Method Fingerprints
1 messages · Page 1 of 1 (latest)
Hello! Stripe.js runs client-side, using your publishable key, and gets much less information. You will not be able to see the fingerprint client-side.
Really? It seems to be part of the API interface in Stripe.js: https://github.com/stripe/stripe-js/blob/3c15f72656159d4506fa0b8a536dfd5e592b0baa/types/api/payment-methods.d.ts#L140
I'll double-check, maybe I'm mistaken...
While I'm investigating, what status does the Setup Intent in question have when this happens?
It's succeeded
So you get the Payment Method object expanded, and fingerprint is there but set to null, or is fingerprint missing entirely?
Missing entirely. I'm new to writing here so let me try to attach a screenshot to this
Thanks, still investigating, hang on...
Yeah no rush. I'm trying to collect card details from Stripe.js and then before we attach the payment method to the customer in Stripe and save the card details to our server, we want to prevent duplicate cards
Ah, yes, I was correct. We removed fingerprint in publishable key API responses in 2014: https://stripe.com/docs/upgrades#2014-10-07
The code you're seeing in Stripe.js is likely there for backwards compatibility with older API versions.
Dang
Why do you want the fingerprint client-side?
To prevent duplicate cards from being attached to the customer. Stripe.js just returns a card token that is submitted to the server, and in the server we attach the payment method to the customer. It would be great to prevent this via the fingerprint attribute without having to make a second call out to Stripe (just to be clear, the second call out to Stripe would be required to get the fingerprint if Stripe.js won't provide it)
Gotcha. The flow you're describing (where your server fetches the token to check the fingerprint after receiving the Token ID from Stripe.js) is common and expected.
You wouldn't be able to trust the fingerprint coming from the client anyway; the client could modify it if they wanted to.