#dchao_api
delicate irisBOT
👋 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/1377329609887973388
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
eager sand
Hello 👋
What steps are you taking when you collect payment method details from your customers? It might be possible but I'm less familiar with the Card Element since the Payment Element has been the preferred approach for custom Stripe integrations for about 4 years.
If you save the Payment Method for the Customer first, you should be able to inspect the Payment Method object and check the card.funding property
pseudo spade
Ah sorry, let me clarify. We have 2 main entrypoints for collecting payment method details:
- We're using the Payment Element, with only the card option enabled
- We're using an Apple Pay button via the PaymentRequest API
We collect the payment method details and use a setup intent to prepare the method for future subscription purchases (after the free trial, and on renewal)
eager sand
We're using an Apple Pay button via the PaymentRequest API
Does that mean you are not using the Express Checkout Element or Payment Request Button?
pseudo spade
Correct
eager sand
Okay, when you confirm the Setup Intent, that happens client-side right? You are using Stripe.js?
pseudo spade
Yes
pseudo spade
We're using the payment request api listed here: https://docs.stripe.com/js/payment_request/create
stripe's payment request api - not the browser's
eager sand
Right but that's just a wrapper around the browser API
If you want to block the debit cards prior to confirming the Setup Intent, we have a deferred intent integration approach you can use. We document that approach here
pseudo spade
Ah, actually i think we're already using that deferred intent integration
pseudo spade
No I don't think so
eager sand
Ah, the confirmation token returns a preview of the Payment Method you will create with the Setup Intent
pseudo spade
We do have access to the payment method's funding field prior to creating the setup intent though
We might be using the stripe API in a slightly janky way - it was last touched around 2 years ago
eager sand
You can use that on your client-side to check if the card.funding property is debit and show a warning message to your customers before they save their card
pseudo spade
Yeah, I think we're able to do that!
eager sand
That's understandable
pseudo spade
That'll work for option 1 for us
But for option 2, we'd rather not have the following experience:
- Apple pay modal shows up
- User selects debit card
- We check funding
- We close the modal, show an error message
- User has to click apple pay button again to input a credit card this time
And would rather just have:
- Apple pay modal shows up
- User has no choice but to select credit card ( I believe this is possible / behavior supported by apple pay?)
eager sand
Hmmm.... yeah that situation is more difficult. As far as I know, the Payment Request API does not allow that kind of specificity. I can raise this as a feature request internally to see if we can get Apple/Google to consider the option but I don't know that we could get anything done quickly.
pseudo spade
Makes sense - I saw that apple pay has this field merchant capabilities: https://developer.apple.com/documentation/applepayontheweb/applepaypaymentrequest/merchantcapabilities
that seems like what we'd want?
I also saw that stripe on react-native has some support for that: https://github.com/stripe/stripe-react-native/issues/728
Would it make sense to just go through the paymentRequest/applePay API directly rather than using stripe's wrapper functions? Would that mess up some integration with the rest of the flow?
eager sand
Well I'm not sure if that would mean the payment methods you save cannot be used with Stripe, since they wouldn't be saved to your Stripe Account. But there may be ways around that.
pseudo spade
Hmm ok, yeah it sounds like it would be hard to get that capability in the short-term
Thanks for the help!
delicate irisBOT
pseudo spade
If you have any other ideas on how we might be able to make the "disallow debit card" behavior a little more smooth - that would be amazing
eager sand
Yeah. I will definitely file this feedback though! It seems like something we should expose through the Payment Request or Express Checkout Element
Okay feedback filed
ornate skiff
Hi there 👋 jumping in as my teammate needed to step away. I think Express Checkout Element can be used to provide a flow that is smoother for your customers than what you're seeing when using our Payment Request Button, but it still won't be as smooth as what you ideally want (that my teammate filed feedback for).
I'm going to stand up a test flow to confirm I can do the following:
- Create and mount an Express Checkout Element
- Use it to create a Confirmation Token
- Inspect the pm preview in the Confirmation Token, and if
fundingisn'tcreditthen respond usingpaymentFailedwith a custommessageindicating a credit card must be used.
If I can do that the way I think I can, then the result will be the customer seeing a custom error message in the wallet modal indicating they must use a debit card. So the flow would be:
- Apple Pay modal shows up
- User selects a debit card
- User encounters an error in the Apple Pay modal indicating they have to use a credit card
bbuutt, I'm realizing I won't really be able to test that, since testing Apple Pay causes us to always use the 4242 test card, which shows up as a credit card. Hm, may have to get a little hacky to test this.
pseudo spade
Hi! Thank you for looking into this!
You've probably got an idea already, but could we check if funding = credit and show a custom message, and then hope that it works for funding = debit 😛
We've also been avoiding the express checkout element because we'd really like to be able to render our own payment button (stripe documentation). Is that possible with express checkout?
ornate skiff
Ah, no, it's not possible to use your own with an Express Checkout Element integration the way the Payment Request Button flow permits.
pseudo spade
That's okay, that's not necessarily a blocker for us
ornate skiff
Hm, I'm running into an error that I wasn't expecting in my testing, that I'm trying to get past right now.
Alright, I don't think my other approach will work right now. It looks like we close the wallet modal when a Confirmation Token is created, so at that point it's too late to call paymentFailed and surface your own error in the wallet UI.