#adam-williams_api
1 messages ยท Page 1 of 1 (latest)
๐ 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/1262715458113638471
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
hi! I don't think there's a specific field for this. I know in Google Pay some cards are added biometrically and others just come from like browser auto-fill, I think that's what you're talking about? I don't think you can differentiate them easily
That's exactly what I'm referring to - yeah. This card was added on a desktop machine from a browser, and then subsequently used to pay on my phone via Stripe's SDK
I think when I look at this internally for support cases I see if there was a cryptogram passed in the API call creating the Token but that's not really something you can do programmatically.
That sounds exactly like what we'd want
but not exposed to API users?
I guess the actual cryptogram couldn't be for security but all I want to know is if there was one or not ๐
I don't believe this is directly exposed no, it all just rolls up into google_pay
and just to check -> network_token.used -> is this only set for Stripe-tokenized network tokens?
AFAIK yes
the only time I look at this is is occasionally when people ask about disputes/liability shift and we can sometimes determine it was not a biometrically-added card by looking at parameters passed on the API call(Google Pay works in a special way where Google calls the API on your account directly) but I honestly don't look at this very often at all. I'm fairly sure it's just not something we expose/productinise at the moment overall but is likely on some eventual backlogs/roadmaps.
That's useful to know, anyway - thanks a bunch for your time. It might be something we need to chat about with our account manager at some point, I believe there are some advanced integrations that would have us do the decryption ourselves (integrating directly with e.g. Google Pay) and then sending the decrypted DPAN, cryptogram etc over to Stripe which would give us more control and visibility of what's going on - at the expense of requiring a lot more work from our end
Pros and cons
yes that integration exists but are restricted and you would also need to be PCI certified