#mjbc

1 messages · Page 1 of 1 (latest)

frigid inletBOT
somber gull
#

Hi 👋

Wallets like Google Pay and Apple Pay are convenience wrappers around Card data so we don't treat them as separate Payment Methods.

But just so I'm clear, you want to know programmatically where an account is configured to accept payments via a wallet?

covert summit
#

yes. we have a custom flow, since we also have other non-stripe payment methods, and we have a pretty standard list of available payment methods. that list comes from the backend and reflects what's been configured to be accepted or not. We could add config for each one of the Stripe payment methods, but if our customers activate google pay/apple pay or worse, if they turn them off, we would not have a way, other than with the canMakePayment to hide that option

#

we could have a hook before they are rendered and call the canMakePayment, but I don't know how long that can take to check

somber gull
#

When you say "activate or turn them off" I am assuming you are talking about the Google/Apple pay settings in their Stripe dashboards. Is that correct?

covert summit
#

yes

#

because, one reason we are adopting stripe is to have a more standard way to implement new payment methods

#

we have a few online shops implemented with our system

#

it's easier for our customers to just turn things on and off in 1 one place and for them to work

somber gull
#

And what is the front-end integration where you are concerned about this? If you are using the Stripe Payment Element this will automatically surface (or not) depending on the payment methods activated on the Account.
https://stripe.com/docs/payments/payment-element

covert summit
#

it's a custom flow, like i said, we have other non-stripe methods

#

we have a list of payment methods. the payment element doesn't fit our UI/UX

somber gull
#

So how are you rendering the Stripe methods?

covert summit
#

the stripe methods will be rendered just like the other methods, when the user checks what they want to use, the additional fields will be rendered below the selected option

#

it's not yet implemented, since we have to understand how to integrate it with our flow

#

but I can show you one example of what we have now

#

gimme a sec

somber gull
#

I don't think that is necessary

covert summit
#

oh, ok.

#

this is a live example, from one of our online stores.

somber gull
#

In that case the .canMakePayment function on the Payment Request object is likely your best bet

covert summit
#

yeah, I was afraid so. too bad there's no backend way of achieving that.

#

oh well, thank you for your help

somber gull
#

I would test with the .canMakePaymet() approach, I don't think it will introduce sufficient lag to your front-end

#

Especially since it's an async function you can kick-off before you render the interface