#BartekM-subscription

1 messages · Page 1 of 1 (latest)

echo forge
#

Hi! So if I understand you are first collecting the payment information with a Setup Intent, and then creating the Subscription by passing the Payment Method?

#

Instead you could use Checkout to collect payment information and create the subscription in one step.

#

Or you could first create the Subscription and then look at latest_invoice.payment_intent.client_secret to collect the payment information on your frontend.

stone smelt
#

We're using SubscriptionSchedule, so we can't use checkout.

echo forge
#

Got it! Then I would recommend the second option I wrote above.

stone smelt
#

But then should I use PaymentIntent instead of SetupIntent?

static fjord
#

you should yes(since as you say, if you use a SetupIntent when you're actually taking a payment it results in the customer seeing the "0-amount" "saving card" style of authentication instead)

#

it's a bit tricky with Schedules but you want to create the Schedule, access the underlying Subscription, access the latest_invoice , finalize it, and then use the latest_invoice.payment_intent.client_secret on the frontend to collect the details and complete the first payment

stone smelt
#

Ok. Thank you for your help. We will try this solution.

stone smelt
#

Hello! We want to use PaymentIntent instead of SetupIntent, but we have a problem with this method. As soon as we call the Stripe Payment Element with PaymentIntent, we have to create a customer and his subscription. We are afraid that this will generate a large amount of rubbish data (cancelled orders). Is there any way to counteract this?

echo forge
#

Hi! Yes, the Payment Element needs a client_secret, so you have to create a Subscription before showing the form.
If people don't submit the form, then you'll have incomplete Subscriptions in your Stripe account. Note that this is perfectly normal! But if you don't like this, then you could on your end delete these subscriptions after some period of time has passed.