#zakmckraken_subscription-deferred-intent
dire wharfBOT
👋 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/1379119172348543141
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
long void
Hi 👋 I don't believe that's possible, because you're setting mode to setup, so the wallets know you aren't processing a payment immediately and therefore aren't showing an amount to the customer.
I don't think it will work, but let me try something on one of my test pages and get back to you.
My attmpt at a workaround also didn't work, so I don't think this is possible.
Is your plan to collect Payment Method details via a Setup Intent, and then immediately create a Subscription using that Payment Method?
cloud flicker
Hi Toby
yeah that's what we have been doing. We send the payment method id to the backend and process things in the backend
sometimes it's through an invoice (when it's only products), sometimes it's through a subscription
long void
What you're seeing is expected then.
Did you have motivation for building the flow this way? Typically it's not what I'd recommend.
Instead I'd usually suggest creating the Invoice/Subscription first, and use the client-secrets of the intents that those generate to use the Payment Element to process the associated payment.
cloud flicker
so the original implementation, before Stripe Elements was introduced, was doing things similarly. in this version we didn't want to create unnecessary data or give unnecessary access until the payment was approved
it's unfortunate because it works fine aside from this $0 showing up in the Google Pay prompt
long void
We do have a flow where you can use the Payment Element to collect payment method details before creating the Subscription object:
https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription
It's similar to the flow you're already using for your Setup Intents (or at least it seems that way since you're initializing the Payment Element with a mode of setup)
cloud flicker
Yeah, currently we really just collect the payment method id and then send it to the backend to finish processing and create the order/subscription
oh I see this one has a "subscription" mode
dire wharfBOT
cloud flicker
that could work, but since we also support payment methods like iDEAL I wonder if that would break that flow...
harsh dawn
Hello 👋
I"m stepping in as my colleague needs to go soon
cloud flicker
Hi, no worries
harsh dawn
There are a few payment methods that don't work with this approach and we call those out in our doc
This integration path doesn’t support BLIK or pre-authorized debits that use the Automated Clearing Settlement System (ACSS).
But iDEAL should convert into a SEPA Debit payment method that you can use for off-session payments.
We handle that part internally for you
cloud flicker
yeah iDEAL and 3DS already work with our implementation
I was just wondering if they would still work if we switch to the suggested implementation
harsh dawn
Yes, the revised apporach in the docs my colleague shared should not impact 3DS or iDEAL payments.
cloud flicker
the approach we are using, just for the sake of clarity, is based on https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription
harsh dawn
That is the doc my colleague shared and the one I am referring to
cloud flicker
but I guess we used type setup instead of sub
(yeah sorry just realized it's the same link I had added as a comment in the code :D)
harsh dawn
Ah yeah, if you use subscription instead that will allow you to preview the payment method first without having to create an additional setup intent
And you really want to be explicitly confirming setup intents and/or payment intents over just creating payment methods
cloud flicker
will that affect the situation where the user is ordering a subscription and a product at the same time? I guess not, we would get a payment method for the sub that we can use in the invoice?
cloud flicker
And you _really_ want to be explicitly confirming setup intents and/or payment i...
I'm guessing you mean that the user should really be aware of what the charge is going to be when going through Google Pay/Apple Pay, I agree
harsh dawn
ordering a subscription and a product
That phrasing does not make sense. Subscriptions are still relating Products to Customers. Do you mean a payment that includes both a one-off payment and a Subscription?
I'm guessing you mean that the user should really be aware of what the charge is going to be
No, I mean that you should be using our Stripe.jsconfirmmethods over creating payment methods because it will better handle next actions.
cloud flicker
> ordering a subscription and a product
That phrasing does not make sense. Sub...
yes sorry
harsh dawn
OKay and what do you mean by "will affect"? Are you still referring solely to the amount rendered in the Google/Apple pay modal window?
cloud flicker
yes
harsh dawn
Have you tried doing this in test mode yet?
cloud flicker
I'll do that soon and reach back if there is an issue.
I appreciate the help!
I'm just hoping we dont have to change too many things because QA is gnarly 🙂 (and our QA person is on vacation)
harsh dawn
Okay yeah, I can understand the hesitation there 😅
cloud flicker
hopefully we just change "setup" to "subscription" and it all works 😄