#mjbc
1 messages · Page 1 of 1 (latest)
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?
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
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?
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
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
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
So how are you rendering the Stripe methods?
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
I don't think that is necessary
In that case the .canMakePayment function on the Payment Request object is likely your best bet