#chung-yi_wallets-save-pm
gloomy juniperBOT
👋 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/1353752264262811658
📝 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.
- chung-yi_best-practices, 2 days ago, 15 messages
- chung-yi_best-practices, 6 days ago, 45 messages
dense nexusBOT
trail axle
Hi 👋 that is correct, both Google Pay and Apple Pay are a subset of our card Payment Method Type. I can't speak to why it was built that way, but can confirm that's correct.
Can you elaborate on what advice you're looking for regarding how to model this on your end? I'm not sure what requirements you're trying to satisfy with how these need to be represented on your end, so I'm not sure what to suggest at this point.
valid eagle
Thank you for confirming the understanding! I can't seem to find Google Pay under card. The wallet type only supports apple pay and link, it seems.
trail axle
The full list of values that the card.wallet.type enum can show are below:
amex_express_checkout
apple_pay
google_pay
link
masterpass
samsung_pay
visa_checkout
and can be found in our API ref here:
https://docs.stripe.com/api/payment_methods/object#payment_method_object-card-wallet-type
valid eagle
Ohh I was looking at the Card object, and it only lists apple_pay and link in it. https://docs.stripe.com/api/cards/object#card_object-wallet
Thank you for linking to the right place.
Initially I was expecting wallets would be its own payment method, but then I realized the ones in the wallets category (https://docs.stripe.com/payments/wallets) do not map 1:1 to payment method types (https://docs.stripe.com/api/payment_methods/object#payment_method_object-type).
As you mentioned above, some of them are sub categroies of a card.
Are there sub categories other than for cards?
trail axle
Not that I'm aware of.
valid eagle
Got it. Thank you!
gloomy juniperBOT
valid eagle
Can I ask you additional questions about Apple Pay and Express Checkout Element?
karmic maple
Hi 👋
I'm stepping in as my colleague needs to go soon. What is your question about Apple pay and the Express Checkout Element?
valid eagle
Hi @karmic maple 👋 , let me summarize...
We're collecting Apple Pay payment details using Express Checkout Element, and then confirming the payment on the server with confirmation token. My understanding is that, with confirmation token, the payment method object won't be created until the payment intent is confirmed.
karmic maple
Have you built this is Test mode and tested end-to-end yet?
valid eagle
I tested it locally end-to-end, yes.
karmic maple
And when do you see the payment_method.created webhook event generated?
valid eagle
I haven't checked, actually. Was the above understanding incorrect?
karmic maple
No, I think you are correct. I'm just trying to prompt you to reason through ways you can find and understand this integration yourself. I think it will give you a better and more complete understanding of how to check things in your Stripe integration which will make your life easier in the long run.
valid eagle
Awesome. Thank you! And my question was
We want to separate the payment method creation out of the payment intent API call, like creating the payment method first and then confirm it later separately. Is switching to use setup intent the solution here?
karmic maple
May I ask why you want to separate the Payment Method and Payment Intent steps here?
I ask because adding a Setup Intent doubles the API calls required for this integration and, if we can solve your question without doing that, it will help your integration scale without running into rate limits
valid eagle
Our checkout flow has separate steps for adding a payment method and submission. We'd like to create and persist payment method as soon as possible.
karmic maple
Okay. In that case, using a Setup Intent is the recommended approach.
valid eagle
(sorry I need to step out for a bit. will be back asap...) 🙏
karmic maple
Our Live mode rate limits are 100 requests per second so, for the vast majority of our users, they aren't a consideration
valid eagle
A follow up question is that Setup Intent can't have the amount specified, right? In that case, it seems to limit how the ApplePay UI would display to the buyers. It will have to display "pending amount", and can't display the exact amount.
karmic maple
Correct
valid eagle
yeah, then it's probably not the best UX to not display the exact purchase amount.
karmic maple
Google Pay also with display Pay $0 which may not be what you are looking for either
valid eagle
yeah good point.
So there is no better way, with confirmation token, to display the exact amount on the UI AND create the payment method ahead of confirming payment intent/setup intent, right?
We'll probably need to either
- Use payment intent that we can display the exact amount but creating payment method at the time payment is confirmed, or
- Use setup intent where we can create payment method early/separately, but can't display the exact amount on the UI.
karmic maple
Those are your options, yes.
valid eagle
OK got it! Thank you for talking through it!
karmic maple
Sure thing! It's why we're here