#mrafei_code

1 messages · Page 1 of 1 (latest)

sly glacierBOT
#

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

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

rough tulip
#

Our general recommendation would be to not use the Payment Request Button (it's deprecated) and migrate to use Express Checkout Element. It supports multiple buttons at the same time, and you can force wallets to render if even the device is not eligible

dark quest
#

@rough tulip Thanks for the quick response.

For the case that I have myself, I do have a saved card, same chrome profile shows googlepay on our staging but not on our production.

Also: We don't use paymentRequestButton we just invoke the wallet payment by paymentRequest.show(). I don't think that's relevant because the flow doesn't even reach there right?

We are definitely considering using express checkout but that takes time and until then if we learn more about how to improve it would be really nice.

rough tulip
#

The code you shared is the Payment Request Button: https://docs.stripe.com/js/payment_request/create

For the case that I have myself, I do have a saved card, same chrome profile shows googlepay on our staging but not on our production.
Is there somewhere I can repro? The likelihood is that something on the device/client is prohibiting it from rendering

Stripe JS Reference
dark quest
#

Not sure how I can share a repro, thanks for bearing with me 😅

So the prohibiting doesn't also seem likely because in the logs we receive stripe's response with link:true but with either applePay:false or googlePay:false

rough tulip
#

By 'prohibiting' I mean that Google Pay isn't available, so it falls back to Link. Explained here:

The Payment Request Button Element dynamically displays wallet options during checkout, giving you a single integration for Apple Pay, Google Pay, and Link. Alternatively, you can use the Express Checkout Element to offer multiple one-click payment buttons to your customers.

Customers see Apple Pay or Google Pay if they enabled them on their device, and depending on the browser they use. If Link appears, it could be because customers:

  • Don’t have Apple Pay or Google Pay enabled on their device.
  • Use Chrome with active, authenticated Link sessions.
Payment Request Button

Collect payment and address information from customers who use Apple Pay, Google Pay, or Link.

rough tulip
rough tulip
#

So we show Link over Google Pay – there can only be one button (another advantage of ECE)

dark quest
#

Sorry I'm not following, how do I confirm what you are saying?

rough tulip
#

You need to log out of Link, somehow

dark quest
#

I see, so is this correct to assume when link:true both google and apple pay are disabled systematically by stripe?

rough tulip
#

The integration can only show 1 button and it prefers to show Link. Again, ECE offers more control over this

dark quest
#

I see, final question, I see in the logs instances where link:true and googlePay:true. So technically, it means that for those they do not have authenticated Link session, is there any way to distinguish those from the ones that are authenticated?

rough tulip
#

I don't know what you're asking me. If link: true then there is an active session

dark quest
#

We base displaying google button on returned response of canMakePayment and if what you are saying is true, there should not be users who have both googlePay:true and link:true but we have quite a lot of those

rough tulip
#

Hmm, I don't think I said anything to imply that. Both can be true – they have a Link session and are in Chrome, and also meet the requirements for Google Pay

#

It sounds like you're using a custom button too?

dark quest
#

yes!

rough tulip
#

So link: true but there'd just be nothing rendered I think

dark quest
#

correct, but Link is not our issue, but we want to figure out if that is tampering with displaying google or apple pay

#

We can go back a bit in our steps, I just replied that stripe is not prohibited because there's a reply from stripe service for the problematic cases where googlePay:false, and link:true so it's not blocked.

rough tulip
#

I don't know what you're asking me. It's really hard to know what scenario is not working for you. Can you share the full canMakePayment response where there is no button?

#

Also, what code you use to render the button(s) in the JS

dark quest
#

Response looks like this:

{"applePay":false,"link":true,"googlePay":false}

This is how we render it if googlePlay=true for example, it is fully custom we don't use stripe's and onClick we do paymentRequest.show()

    <button
      type="submit"
      loading={isProcessing}
      disabled={isProcessing}
      onClick={handleWalletButtonClick}
    >
      Google Pay
      // icon
    </button>
rough tulip
#

And there's definitive examples in your logs where both link and googlePay are true?

dark quest
#

yes

rough tulip
#

Hmm, let me check

dark quest
#

Both this:

{
  applePay: false
  googlePay: true
}
rough tulip
#

Hmm, think Link might be disabled on that account so it's not shown at all. Looked at our source code and seems like link and googlePay/applePay can both be true

dark quest
#

Hmm, yeah the inconsistency is why our website is resolving to false for googlePay whereas when I'm opening stripe links for eligbility it says true 🤔

rough tulip
dark quest
#

Can't be though cause same code is showing the button on our staging. (same code hosted at a different address)

It's also not likely to be a domain registration issue since most of users are fine but a few are not?

rough tulip
#

As I said, more likely a device/client issue not an integration/Stripe account issue

#

It's also not likely to be a domain registration issue since most of users are fine but a few are not?
No way for me to know without your acct_xxx ID and the domain(s) you're using

dark quest
#

I can share that with you privately?

rough tulip
#

Not here, no. You'd need to write in to our team