adam-williams_api | Stripe Developers | Page 1

dim bluffBOT Mar 24, 2025, 4:38 PM

#

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

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

#

vale schooner Mar 24, 2025, 4:39 PM

#

Hello 👋

Can you provide an example of the kind of request you are referring to?

grave inlet Mar 24, 2025, 4:39 PM

#

For example, pi_3R3ofYLCeRZDq69e13ijtqyS I suspect was done as a PAN_ONLY Google Pay payment

#

My view is that, because we specified payment_method_options[card][request_three_d_secure] any, it should've received a 3DS challenge

vale schooner Mar 24, 2025, 4:40 PM

#

Issuing banks can request 3DS at any time regardless of the parameters provided.

grave inlet Mar 24, 2025, 4:41 PM

#

That's fine, I understand that

#

but was there a challenge in this case, or not?

vale schooner Mar 24, 2025, 4:42 PM

#

No, this payment intent never entered a status of requires_action

grave inlet Mar 24, 2025, 4:42 PM

#

okay, but we asked for a challenge

#

#

and it supposedly supports 3DS

#

so why didn't Stripe's SDK show a challenge?

vale schooner Mar 24, 2025, 4:46 PM

#

Use any to manually request 3DS with a preference for a frictionless flow, increasing the likelihood of the authentication being completed without any additional input from the customer. 3DS will always be attempted if it is supported for the card, but Stripe can’t guarantee your preference because the issuer determines the ultimate authentication flow.

From our docs

grave inlet Mar 24, 2025, 4:46 PM

#

so is the card network (Amex) the problem here?

vale schooner Mar 24, 2025, 4:47 PM

#

I cannot say if that is or not. It could also be that the bank that issued the card did not send a challenge

#

We send the additional information you provide in our communication to the bank, but it is ultimately up to them whether they return a challenge or not.

grave inlet Mar 24, 2025, 4:48 PM

#

Are you 100% certain that if we do payment_method_options[card][request_three_d_secure] => any then it'll be used to try to request a challenge from the bank for a Google Pay tx?

vale schooner Mar 24, 2025, 4:50 PM

#

I think this may be related to the fact that Google Pay already supports liability shift. We describe that in this support article

grave inlet Mar 24, 2025, 4:50 PM

#

Right, I thought that might be the case

#

it does already support liability shift, but not for Amex and not for every Visa/Mastercard card (it depends on the authMethod and whether it was PAN_ONLY or CRYPOGRAM_3DS and also the country where the card was issued) - it's not sufficient just to allow the charge to succeed as-is, you won't get any liability shift. Which is why we now have a fraud dispute.

#

Stripe's docs on this are garbage, but Adyen's aren't: https://docs.adyen.com/payment-methods/google-pay/

Google Pay | Adyen Docs

Learn how to accept Google Pay payments.

#

Google Pay does not guarantee liability shift for FPAN transactions. To receive liability shift for FPAN transactions (or the below-mentioned brands that Google Pay also does not support liability shift for) it is advised to implement 3D Secure

Does Stripe do this additional 3DS on top? If it doesn't do it by default, how can we request it?

Google Pay does not guarantee liability shift for Discover, American Express, JCB, or Visa cards issued outside the EU and UK.

My reading of this is that there's no liability shift for an Amex transaction, even if it's CRYPTOGRAM_3DS auth'd, and you should always try and do a 3D Secure challenge on top.

vale schooner Mar 24, 2025, 5:02 PM

#

Do you also have our 3DS Radar rule activated? https://docs.stripe.com/radar/rules#request-3d-secure

grave inlet Mar 24, 2025, 5:02 PM

#

We don't use Radar; API request examples only please 🙂

vale schooner Mar 24, 2025, 5:03 PM

#

These are default Radar rules, not the kind that require a fee

#

They already exist on your account, you can just turn them on/off

grave inlet Mar 24, 2025, 5:03 PM

#

in that case, let me see

#

how?

#

is it this page?

vale schooner Mar 24, 2025, 5:07 PM

#

That should be it. You should be able to enable that rule to request 3DS on all payment intents where the card used supports 3DS

grave inlet Mar 24, 2025, 5:08 PM

#

What does "This rule will not apply to authenticated payments created with Apple Pay or Android Pay" mean?

What's Stripe's definition of an authenticated payment?

#

would the Amex charge from the example above be considered "authenticated"?

vale schooner Mar 24, 2025, 5:09 PM

#

Oh, right. That sounds like the third point here still applies

If the user selects Google Pay as the payment method on an e-commerce site or in an app that pays with Google Pay, the cards are saved as e-commerce tokens that represent the cards on file. Neither liability shift nor 3D Secure are supported for e-commerce tokens at this time.

grave inlet Mar 24, 2025, 5:11 PM

#

Would you see a cryptogram being sent in the SDK's request to /v1/token for an "ecommerce token"?

#

Sorry to ask all these questions, but I do not feel like we have a very strong grasp on how Stripe actually works when it comes to Google Pay

#

there are docs, but they're very high level and don't assume any understanding of e.g. Google Pay's own docs for merchants doing a direct integration

vale schooner Mar 24, 2025, 5:13 PM

#

No, that's fair. To be honest I don't think we do a good job documenting the internals very well either.

#

And yes, we would consider this an ecommerce token creation. The actual details are being made in a request to /v1/tokens by Google on your account

grave inlet Mar 24, 2025, 5:15 PM

#

there's no way I can distinguish the different cases from the API, is there - short of doing the Google Pay integration myself and passing the details to Stripe

vale schooner Mar 24, 2025, 5:17 PM

#

There is a way to determine this. Sorry I'm just jumping through a bunch of differet admin pages

grave inlet Mar 24, 2025, 5:17 PM

#

take your time!

#

it's the eciIndicator I sort of want to see from Stripe, if possible

vale schooner Mar 24, 2025, 5:18 PM

#

Aha! You can see it in the Card object. tokenization_method: "android_pay", indicates that this payment method is an ecommerce token

#

It's also in that /v1/tokens request

grave inlet Mar 24, 2025, 5:20 PM

#

ah, that request is made by your SDK :)

vale schooner Mar 24, 2025, 5:21 PM

#

The request I am looking at is this one: https://dashboard.stripe.com/logs/req_90uagCJs5y3Bku

grave inlet Mar 24, 2025, 5:22 PM

#

vale schooner Aha! You can see it in the Card object. `tokenization_method: "android_pay",` ...

yeah, we didn't manually send that; the Stripe Android SDK did, I'm not sure if it has any hooks we could use to intercept that / see what it's doing

grave inlet Mar 24, 2025, 5:22 PM

#

vale schooner Aha! You can see it in the Card object. `tokenization_method: "android_pay",` ...

Where are you seeing this? If I https://api.stripe.com/v1/payment_intents/pi_3R3ofYLCeRZDq69e13ijtqyS\?expand\[\]=payment_method I don't get it

#

oh I see

#

it's on the token itself

vale schooner Mar 24, 2025, 5:27 PM

#

It's a property on the Card object: https://docs.stripe.com/api/cards/object?lang=dotnet#card_object-tokenization_method

Which makes it pretty darn hard to get access to.

grave inlet Mar 24, 2025, 5:27 PM

#

I was just about to ask

vale schooner Mar 24, 2025, 5:27 PM

#

Yeah it's on the Card object within the Token

grave inlet Mar 24, 2025, 5:27 PM

#

can we get a token ID used from a payment intent?

#

or a charge?

dim bluffBOT Mar 24, 2025, 5:28 PM

#

grave inlet Mar 24, 2025, 5:45 PM

#

And, follow-up question

tok_1R4ANfLCeRZDq69eFFblesDu (req_8K00uLYrVrxbJq) had an "eci" / Electronic Commerce Indicator "07" value sent over by the client which means no liability shift in Visa-land - is there any way I can retrieve back that ECI value for a given payment intent / payment method ID?

dusky sorrel Mar 24, 2025, 5:50 PM

#

ECI is generally exposed in card payments, however, this is not the case for Apple Pay and Google Pay transactions. We expose it in the PaymentIntent for 3DS [0]

[0] https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-three_d_secure-electronic_commerce_indicator

Create a PaymentIntent | Stripe API Reference

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

#

Currently we don't support exposing ECI on Apple Pay and Google Pay

grave inlet Mar 24, 2025, 5:55 PM

#

thanks, there's no betas or anything here? I'll put the request in to our acct manager anyway

dusky sorrel Mar 24, 2025, 5:55 PM

#

None at the moment.

grave inlet Mar 24, 2025, 5:57 PM

#

Is it exposed to Radar internally for :has_liability_shift

dim bluffBOT Mar 24, 2025, 6:46 PM

#

lunar kernel Mar 24, 2025, 6:50 PM

#

Hello 👋
taking over here

#adam-williams_api