#eamjr_best-practices

1 messages ¡ Page 1 of 1 (latest)

wintry helmBOT
#

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

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

limpid canopy
meager wave
#

We are not using stripe.js page we receive a raw pan in the transaction , turn around and create a PM. The issue is we might get multiple copies of the transaction with the raw pan each time.

limpid canopy
#

Ah gotcha, unfortunately there isn't a way to see the fingerprint until some Stripe object with it. I do know that many users check fingerprints after the transaction and then detach one of the duplicate PMs. Would that work for your usecase?

meager wave
#

So if we create conrimation token object rather than a pm on subusequent verions of the transaction we could see if the latest version fingerprint matches the existing saved version?

#

params := &stripe.PaymentMethodParams{
//Type: stripe.String(string(stripe.PaymentMethodTypeCard)),
Type: stripe.String("card"),
Card: &stripe.PaymentMethodCardParams{
Number: stripe.String(card_number),
ExpMonth: stripe.Int64(exp_month),
ExpYear: stripe.Int64(exp_year),
},
};
params.SetStripeAccount(ConnectedAccount)

new_pm, err := paymentmethod.New(params);
Current code to deal with the incoming raw pan

limpid canopy
#

Gotcha, a confirmation token wouldn't let you do anything there that that isn't already letting your do. I thought you were describing a different flow where you created the payment method and intent in the same call.

#

So checking the fingerprint after creating the PM like that is a good solution and unfortunately we don't have a lighter way of doing that at the moment.

meager wave
#

Plus this is all server side.

#

Is there a way to get rid of the later version pm's if the fingerprint matches or is there some backend process at Stripe that gets rid of orphan PM records. Just seems like we would be generating a lot of dead wood.

limpid canopy
#

Nothing built-in on our side unfortunately. The best solution I am aware of is to detect that in code and make the API call to detach the PM

meager wave
#

We would never attach it if it matched.

#

Just trying to be concientious regarding leaving junk in your storage.

#

So do the detached PM go away?

limpid canopy
#

The typical way to never attach it would be to re-use the old PM ID when you detect the new one is a duplicate.
The data doesn't go away but detatching is the closest thing to deletion. It won't show up in the dashboard or list API calls, but you can still retrieve its ID and see its info on charges related to that specific PM in the dashboard.

#

Also FWIW we don't limit your data storage based on that, you can create as many one-off PM objects as makes sense.

meager wave
#

Roger that. We will go forward. Appreciate the help and insight.