#timothy-hahn-grow-therapy_api
pure quailBOT
👋 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. Thank you for your patience!
⏱️ We automatically close idle threads, which makes them read-only. Make sure you stick around to chat in realtime! If this thread is closed and you have another question you'll need to start a new thread.
🔗 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/1214600857329340548
📝 Have more to share? You can add more detail below, including code, screenshots, videos, etc.
smoky kayak
For more details on the first point: we are specifically curious about how long this PaymentMethod will likely remain valid (after confirming the SetupIntent) for, given that we may not charge the customer until months later. Since we would like to not charge the customer until we are sure how much they owe, we would like to avoid charging them until we are confident in the price.
For more details on the second: It does not appear that any of the Merchant token types for Apple Merchant Tokens (https://docs.stripe.com/apple-pay/merchant-tokens?pay-element=web-pe) makes sense for our use case (both an indeterminant amount and indeterminate time period), so wondering if not fitting into the merchant token type is a risk factor.
And just to reiterate, this is specific to Apple Pay on the web 🙂
Thanks in advance for your help!
weary charmBOT
wet harbor
Hi 👋 I'm not aware of those Payment Methods having validity durations on them.
The key advantages of MPANs seems to be discussed at the top of the page you referenced, was there something more specific you were looking for clarity on?
The last token type, for deferred payments, sounds to me to be a decent fit. Do you think I'm overlooking why that doesn't work for you?
smoky kayak
Got it, thanks!
And I think that makes sense - does this imply that using SetupIntents without an MPAN may risk the PaymentMethod becoming invalid when the user switches devices?
Playing around with Deferred Payment Requests, it looks as though we need a specific date and amount, which isn't always possible for us.
In our scenario, customers are charged based on appointments (so not necessarily a regular format that can be described as "every week" or "every month", etc.), as well as based on how much of their appointments are covered via other payors (which can take a few weeks to months to fully settle).
So during setup, we can provide a generic estimate of something like $5 on May 1, 2024, but I'm wondering if that will prevent us from essentially not taking that payment and then later collecting payments off session for something like $10 on April 15, $3 on May 30, $10 on June 7, etc.
(I also realize that this might payment strategy be better serviced by using Invoices for "please pay us later", but trying to see if we can fit in Apple Pay to our current model easily)
wet harbor
I think this is getting more into Apple's policy on what type of payments they would allow versus block. I don't think I have sufficient insight to explain how Apple will decide to do based on the information you give them.
smoky kayak
Totally fair, thanks for taking a look!