#maddockst-collect-pm-subscription

1 messages ยท Page 1 of 1 (latest)

lilac pecan
#

Hello ๐Ÿ‘‹
I see that my colleague suggested following

1/ create Subscription with trial, it has a pending_setup_intent

2/ pass back the SetupIntent client_secret and EphemeralKey secret etc to the iOS app

3/ create and go through the PaymentSheet

4/ once the SetupIntent is successfully authenticated, you have a PaymentMethod that you attach to the Customer's invoice_settings.default_payment_method

If the customer abandons the flow, I believe you can still check if the subscription still has a pending_setup_intent on it and pause their services until they put it the payment method info

desert swan
#

Ok. So am I right in thinking that the customer will still be marked in stripe as active but I could check pending_setup_intent from the webhook event and set my own flag?

lilac pecan
#

that's correct

desert swan
#

Ok. What happens for paymentIntents?

lilac pecan
#

other options would be to check if the customer or subscriptions have a default payment method

desert swan
#

Ah, I think that's better

#

customer.subscription.created wouldn't have the default payment method setup at this point (for trials). Do you know what WebHook event I'd need to listen to? Something like customer.subscription.updated or would it be customer.updated?

lilac pecan
#

You can just call the API to retrieve the customer to check if they have default pm

#

or are you asking about the event that fires when the customer does put in the payment method information?

desert swan
#

Yes, so like this:

Subscription is setup as trialling
<WebHook Event (No payment method here)
Payment method attached
<WebHook Event?

tame zenith
desert swan
#

Ok, that event is perfect.

#

Before I go down this route, is there any way that I could create the subscription only once the payment method is attached to the customer (for trials and non-trials)?

#

This is using PaymentSheet

tame zenith
#

You can create your own setup intent separately but that is only suggested if the subscription has a trial or doesn't take payment up front. Mostly that is because if a user has a card that needs 3DS auth, they might have to do it for the initial setup and for the first subscription payment which adds friction to the experience

desert swan
#

Ok, I think that could complicate the flow to be honest.

#

Another thing sorry, will one of either subscription.latest_invoice.payment_intent or subscription.pending_setup_intent be present, but not both?

#

For a trial, subscription.pending_setup_intent will be present

#

For non-trial, subscription.latest_invoice.payment_intent will be present?

tame zenith
#

Yes, it should only be one or the other

#

To split hairs a bit, the distinction is whether the subscription needs payment upfront or not. Trials are one reason a subscription wouldn't require payment but there are use cases like using a $0 price for an active subscription or if you are using metered subscriptions those don't charge until the end of the cycle

#

Those probably aren't relevant to what you are doing but I thought it was worth mentioning

desert swan
#

Ok, I appreciate that. So basically, my payment sheet can be given the client secret as follows:

subscription.latest_invoice?.payment_intent?.client_secret || subscription.pending_setup_intent?.client_secret