steve-rector_api

[still oriole]

👋 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/1509239440533487696

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[split hound]

here is the full message from them since it cuts off too early in the request form

on our side, we're already running a flow with Stripe that creates the subscription after the initial checkout, and it works in production today. Roughly what we do:

At checkout, we create and finalize a first-month invoice for the customer (one-time charge, not a subscription yet).

We hand the PaymentIntent's client_secret from that invoice to our frontend so Stripe.js can render the payment form.

The customer enters their card and pays the first-month invoice. As part of paying for it, the payment method is stored with the customer.

Later, when the order is fulfilled, we call Stripe::SubscriptionSchedule.create against that saved customer, and Stripe charges the default payment method on the second invoice (and forward) normally.

[tardy sapphire]

hello!

so what you're describing here is a little more nuanced than "using auth and capture with subscriptions"

basically they're doing an initial payment intent with capture_method: "manual" and setup_future_usage: "off_session"

so this creates the initial payment which can be captured manually, and then sets up the card to be a payment method that you can attach to the subscription for subsequent payments

but those subsequent payments will not be able to use capture_method: "manual"

[split hound]

hey sorry got pulled away for a second taking a look 👁️

[split hound]

oh ok so just to make sure im understanding:

1. one off payment with off_session setup so payment method is stored for later use
2. Later create a subscription using that off session payment method (aka customer isn't there)

So the first payment is essentially mimicing the "first month" or whatever cadence but under the hood is a one time purchase, and then the actual subscription is created via that off session flow for the following months, is that correct?

[tiny mango]

Hi there - I'll be taking over for solanum here

[split hound]

sounds good!

[tiny mango]

Correct, and the Subscription is always automatic capture

[split hound]

ok I see so it is indeed not supported and what the customer presented is a workaround, I think that makes sense

[tiny mango]

I mean you could model Subscriptions with automatic capture on the PaymentIntents API but you would get none of the power/built-in features that Stripe brings with it

[split hound]

ya i think that would be way too heavy of a lift for the scenario though it is a good idea. I think we would be able to support the same workaround flow they are using if our off session implementation allowed for subscriptions, but at the moment it doesn't so i think that would probably be the road we went down