#Matty-card-dupe
gritty topaz
Hey there! You'll likely wanted to track the fingerprint of each card (which is unique): https://stripe.com/docs/api/payment_methods/object#payment_method_object-card-fingerprint
That's assuming you're using Payment Methods
plain sage
We are using payment methods, but the problem is that when the customer is entering their card, we have no way of knowing if that fingerprint was already created via the Stripe.js API. Unless I am missing a process somewhere? i.e. Customer enters card into elements that is a duplicate // something happens here to just return the already created payment // and then charge the customer.
gritty topaz
Which Element are you using?
gritty topaz
Hmm, little trickier this way yeah
plain sage
Ha! 🙂
gritty topaz
As there's no way to create a Payment Method directly from that Element (and this to check the fingerprint)
Is this in order to prevent trial abuse?
plain sage
It's to allow payments like Clearpay and Klarna without having to setup multiple payment elements.
gritty topaz
Oh, yeah. I meant the concern over multiple cards
i.e. signing up for a free trial with a 'new' account but the same card
plain sage
No, it's because our CS teams are seeing lots of cards in an account and our tech team gets tickets. 🙂 But I see their point... it's messy.
gritty topaz
Ah, so it's a single Stripe customer with multiple cards?
How are they adding multiple?
plain sage
Another reason is that if a customer chooses to "save" their card, we flag that and they can create duplicates.
Just checking out. If they don't choose to save their card, they don't see that it is saved in Stripe, so they'll add it again during checkout. I'm not sure how we can prevent that.
gritty topaz
So they're always presented with the Payment Element when checking out?
plain sage
Yes, that is correct.
gritty topaz
Got it. In that case, my recommendation would be to present your customers with the option of payment with a previously saved payment method. You'd need to build the UI for this yourself
plain sage
We do that, but not all customers want their card saved, so if they don't, and they purchase from us often, there is no way for me via the API or our system to prevent the new duplicate card from being added to their Stripe account.
gritty topaz
but not all customers want their card saved, so if they don't
Then why are you saving them?
Am I confused? If they don't opt to save them, then how do they end up with multiple card payment methods attached
plain sage
We allow customers to reserve a product or sign up for product subscriptions. When this happens, their card has to be attached to their account in Stripe so it can be future charged. A lot of our customers want to re-enter that information at checkout each time. Think of it as them entering a confirm your card in checkout. They just don't like it being there to allow a quick checkout without having to re-enter their card information.
Hopefully that helps clarify.
gritty topaz
Got it, seems a bit obscure to me! But anyway I guess to the point in hand, is a new Payment Method being 'saved' for each payment?
plain sage
Yes... if they don't choose a visible saved card. Visible means they chose to save it even though it is saved in Stripe, so we display it as an option on our site for quicker checkout.
Is there a reason de-duplication doesn't happen on the Stripe side?
With a key of cust -> card info -> off session?
gritty topaz
Then it seems like you just need to opt out of saving it in your integration?
Is there a reason de-duplication doesn't happen on the Stripe side?
I don't think there's a specific reason why or a limitation, just something we haven't built
plain sage
If we don't save the card, I'm not sure how we would do the off session charges for the final payment or subs.
gritty topaz
Right, but is the issue not 'we have X duplicates of Y card because we save it for every checkout regardless of if it requires off-session payments'
Surely you should be only saving where off-session is needed
Seems naive of your customers to think their payment data isn't saved for a recurring charge too
plain sage
Correct, but that is 50+% of our orders.
gritty topaz
But anyway, there's no real easy way to deduplicate with Payment Element as you can't use createPaymentMethod from Stripe.js (which would create the PM client-side). That way you could check the fingerprint, and throw an exception or whatever
plain sage
Think of it this way... they know they are going to have their payment saved for anything related to THAT transaction, not for future.