#ebon_code
edgy ingotBOT
đ 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/1306985903662694453
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
tender parrot
With mode: subscription, amount 0/500 everything seems to work ok from our perspective. No subscriptions seem to be created in Stripe itself, and everything seems to work.
User sees the Google Pay popup with correct initila price that we will charge from them.
Our main worry is that is this very tied to actual Stripe subscriptions?
Perhaps there are some hidden effects. For example might Stripe itself cancel the payment method later, since there is no attached subscription to it on your end? For example that might mean that the initial purchase goes through, but after month or two the payments get denied once we ask Stripe to process them.
exotic dragon
hi! so what's the integration, you are confirming a SetupIntent and the you run your own logic to create off-session PaymentIntents for the recurring payments?
then I would use mode:"setup" yes.
WIll the user's still see some kind of Google popup that their card will be charged via it?
they see a popup saying that they're authorising their card for $0, which is true.
Apple Pay has some special parameters for giving more detail on the recurring payments : https://docs.stripe.com/apple-pay/merchant-tokens?pay-element=web-pe#add-apple-pay-merchant-tokens ; Google doesn't and it's just a simple $0 auth.
mode:subscription is also perfectly fine too
Our main worry is that is this very tied to actual Stripe subscriptions?
Perhaps there are some hidden effects. For example might Stripe itself cancel the payment method later, since there is no attached subscription to it on your end?
no, it doesn't work anything like that. It's purely a frontend thing with no impact on any thing else
tender parrot
"they see a popup saying that they're authorising their card for $0, which is true. "
Aah this is something our business owners want to avoid, for the case where our initial price is for example "10$". It would be misleading to the user to tell in Google popup that we will charge them "0$".
Of course the real price is visible elsewhere in the process, but many users would be confused by seeing "Hey this costs you 10$ right now" elsewhere, and then Google popup saying it's billing you 0$.
But sad if that's true for Google Pay
But yeah, if the subscription mode should work as well, with that we can set the price to be the actual price we will charge them
exotic dragon
Aah this is something our business owners want to avoid, for the case where our initial price is for example "10$". It would be misleading to the user to tell in Google popup that we will charge them "0$".
well usually the answer to that is you should just be using a PaymentIntent directly and not just saving the card.
Like if this is a flow where you're creating a subscription, you would process the payment for the first payment then-and-there, you show the $10 in the popup, and that's it.
it's an anti-pattern to create a SetupIntent and then ~immediately run a PaymentIntent to charge the resulting saved PaymentMethod; it's better to just do the PaymentIntent for the amount you wanted. (https://stripe.com/docs/payments/save-during-payment)
But yes mode:"subscription" does work well here as well. Ultimately all this is frontend only and only controls what the UI shows, once you have the PaymentMethod object you can more or less chage it for any amount.