#maddockst-collect-pm-subscription
1 messages ยท Page 1 of 1 (latest)
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
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?
that's correct
Ok. What happens for paymentIntents?
other options would be to check if the customer or subscriptions have a default payment method
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?
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?
Yes, so like this:
Subscription is setup as trialling
<WebHook Event (No payment method here)
Payment method attached
<WebHook Event?
We have a payment_method.attached event for that https://stripe.com/docs/api/events/types#event_types-payment_method.attached
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
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
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
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?
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
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