#alex_best-practices

1 messages · Page 1 of 1 (latest)

verbal furnaceBOT
#

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

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

granite karma
#

hello! just want to acknowledge your question, i just had a few other questions come in so i need to work through some of those first

vocal delta
#

no worries, no rush, thanks for the ack

granite karma
#

ok, circling back to this now.... thank you for your patience

#

(also still juggling a few threads so responses may be a little delayed)

#

hmmm ok, so just to make sure i understand... you're basically trying to reverse lookup a customer ID from a payment method used in a tap to pay scenario?

#

off the top of my head i don't think that's possible, but i can double check. what integration / SDK are you working with?

vocal delta
#

let me get those for you, but basically it's react-native on the clientside and nodeJs on the backend

#

according to the payment method docs I linked, the payment method should expose a customer property, but I'm unclear if that will be populated when the PM is coming from a setup-intent confirmed by Tap to Pay.

granite karma
#

yeah, i don't think we would have that unless you're already providing the customer in the setup intent up front

vocal delta
#

as far as SDKs go, node js backend uses "stripe": "^17.5.0"
terminal uses: "@stripe/stripe-terminal-react-native": "0.0.1-beta.25"

#

ok so to clarify, we are not providing the customer in the setup-intent in this case, since during Tap to Pay, we don't have any identifiers to retrieve a user document in our database. That is, until we have confirmed the setup-intent, at which point we have a payment method.

what we are doing currently is using the fingerprint of that payment method to see if any user records in our DB have that fingerprint.

what we are trying to do additionally, is allow for the possibility of a customer having more than 1 payment method. what we want to avoid is storing an array of card fingerprints in our database.

#

There is a scenario in which the user (customer) signs up in-app, links a payment method (we save that finger print call it pm1), then links another payment method (pm2) (we don't save this second fingerprint). Later, that user might use the Tap to Pay product with pm2, we want to connect that action with the customer.

#

in that scenario, is the advice to save each card fingerprint and do a lookup against a list of fingerprint?

granite karma
#

ok, that makes sense... let me poke for you

#

off the top of my head i do think the array of fingerprints might be the best option though

vocal delta
#

ok, thanks for that input, seemed like a bit of an anti-pattern but maybe it's the way. I have been reviewing our logs and so far haven't found a PM with a customer, but that might simply be because I'm not seeing repeat customers in my small sample set.

#

(back in a few mins)

verbal furnaceBOT
floral stirrup
#

Hello
Taking over from solanum here
You'd need to use fingerprints to de-duplicate. There's no other workarounds/best practices aside from just that.

vocal delta
#

ok understood, thanks Hanzo

floral stirrup
#

NP! Happy to help

vocal delta
#

just to understand this a bit better, because other people at my company are going to ask, this call:
return this.stripe.paymentMethods.retrieve(paymentMethodId); is not guaranteed to return a customer, even if the payment method has previousy been attached to a customer?

floral stirrup
vocal delta
#

I saw that note about expand, which I thought meant it would return a customer object as opposed to the string customer_id.

#

but you're suggesting I should pass expand in order to retrieve the customer at all?

floral stirrup
#

Yeah, expandable properties behave in two ways.

One is, we only return the Object ID and then you can expand that to look at the complete object
Second is, we only return the "field" if you expand the parameter.

See: https://docs.stripe.com/api/expanding_objects?api-version=2025-06-30.preview&rds=1

In many cases, an object contains the ID of a related object in its response properties. For example, a Charge might have an associated Customer ID. You can expand these objects in line with the expand request parameter. The expandable label in this documentation indicates ID fields that you can expand into objects.

Some available fields aren’t included in the responses by default, such as the number and cvc fields for the Issuing Card object. You can request these fields as an expanded response by using the expand request parameter.

I'm not sure what category the customer parameter falls into but if you don't see the field returned then you can try to expand it so we include it in the response

#

does that clarify?

vocal delta
#

OK, just read that as well, intuitively I'd expect customer to be a string or null by default but yes, I can bear that in mind and even expand by default and work with the object just to avoid ambiguity there.

#

So am I hearing correctly that there may be an option here to get the customer from the payment method given the assumption that the payment method and customer have previously been connected?

#

With the understanding that if the PM is detached then this connection will be removed as well.

floral stirrup
#

Not previously but if they're currently associated.

If the payment method has been detached then I don't believe we'd return a customer ID

#

correct

vocal delta
#

makes sense

#

ok thanks Hanzo, I will give it a try bearing all this in mind and see how we do. there is also the nuance of mobile wallets/generated_cards so we may run into other complications, but I think as long as the PM and customer are currently associated, this might actually help avoid some of those complications.