#maddockst-mobile-subscription

1 messages · Page 1 of 1 (latest)

broken garnet
#

Hey @candid sigil! Mobile is not my forte so to be able to help I'm going to need extremely specific detail about your integration and what you are trying to do
1/ Which Mobile SDK and exact version do you use: iOS, Android, React Native
2/ What is your code doing, what are you calling, what part is confusing
3/ What exact documentation page are you following right now?

candid sigil
#

Hi @broken garnet ! Thanks for replying and sorry for the drawn out reply.

An overview of my flow:

  1. Create setupIntent + Ephemeral key
  2. Collect payment details using PaymentSheet + setupIntent client_secret + ephemeral key
  3. On PaymentSheet completion, setup subscription in the backend (passing a promotional code if provided)
  4. On subscription created, mark subscription as active in my database
  5. On Failure, Collect new paymentMethod and setup new subscription or try to use previous subscription????????

Where I am so far

  1. At the moment, I'm using just the iOS SDK (version 22.7.0)
  2. I am creating a setupIntent + ephemeral key in the backend, using that to present a PaymentSheet which is attaching the payment method perfectly.
  3. https://stripe.com/docs/payments/save-and-reuse

The parts I need some clarification on are around setting up the subscription:

  1. I'm assuming that when I attempt to create a subscription, the default payment method is already set from the setupIntent + PaymentSheet?
  2. What do I do if a subscription fails to be setup, should the user be setting up a new payment method?
  3. If a new payment method is needed, will this new payment method be set as the default automatically or will I need to update the customer?
  4. Lastly, if i get a 200 from stripe.subscriptions.create, can I assume the subscription has been successfully setup or are there any properties on the response which I need to be aware of before I consider the subscription active?
ionic crystal
#

so question - have you considered not using a SetupIntent with the PaymentSheet

and instead, create a Subscription first, which results in an "incomplete" Subscription but gives you an underlying PaymentIntent (at subscription.latest_invoice.payment_intent field)

and you use that PaymentIntent client_secret with the PaymentSheet

#

would flipping that up a bit help?

candid sigil
#

The issue I have is with trials. It'll fail trying to create a paymentIntent with no actual payment needing to be taken (initially)

#

Does that make sense? So if I offer a customer 2 months free, I get a failure saying "Payment required" if I remember correctly.

#

So my idea was to setup the payment method first, then subscription after

ionic crystal
#

when a Subscription has a trial, it has an underlying SetupIntent, so the same concept applies, right?

except that now instead of a PaymentIntent client_secret, it would be a SetupIntent client_secret

candid sigil
#

Ok, so could you show me the flow for this please?

ionic crystal
#

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

candid sigil
#

Ok, thanks for that. To confirm, this flow would handle a trial period as well as no trial period?

  1. Once I attach to the customer's invoice_settings.default_payment_method, would I assume at this point that the subscription is active? Regarding a payment that fails (e.g not enough money in their account), would the payment be retried multiple times and if it still fails, the subscription be marked as inactive and a webhook triggered?
ionic crystal
#

this flow would handle a trial period as well as no trial period?
no trial period would be the same, except in step 2/

you would do what I suggested earlier, aka

and instead, create a Subscription first, which results in an "incomplete" Subscription but gives you an underlying PaymentIntent (at subscription.latest_invoice.payment_intent field)

and you use that PaymentIntent client_secret with the PaymentSheet

so case "with trial" - pass back SetupIntent client_secret
case "without trial" - pass back PaymentIntent client_secret

#

would I assume at this point that the subscription is active?
Subscription would be active when the SetupIntent or PaymentIntent is successfully confirmed by PaymentSheet

#

would the payment be retried multiple times and if it still fails, the subscription be marked as inactive and a webhook triggered?
is this regarding the first payment? or the recurring one?

either way, webhook events would be sent yes for payment_intent.payment_failed (in the case of no-trial)

candid sigil
#

So, what would be the best way to work out if it's a trial? Some of my promotional codes offer 50% off, some offer a month free etc

ionic crystal
#

what would be the best way to work out if it's a trial?
the status of the Subscription, whether active or incomplete or trialing etc
and the status of the underlying PaymentIntent or SetupIntent

candid sigil
#

Ok. And you don't see a way without the need to switch between paymentIntent and setupIntent? Just wondering if this was easier than my original approach

#

Or will my original approach / flow not work?

ionic crystal
#

your approach works except that there is a chance a customer can be required PaymentMethod authentication on the initial SetupIntent, then another authentication when the Subscription is created (and first payment is taken if no trial) or even if there is trial

candid sigil
#

Ah ok, I see

ionic crystal
#

with my approach, you only have one point where authentication happens, after you create the Subscription and send client_secret back to PaymentSheet to prompt for PaymentMethod

candid sigil
#

Ok, so this is the flow then:

1/ create Subscription with / without trial, it has a pending_setup_intent

2/ pass back the SetupIntent (if trial) or PaymentIntent (if no trial) client_secret and EphemeralKey secret etc to the iOS app

3/ create and go through the PaymentSheet

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

ionic crystal
#

just one thing to note between steps 1/ and 2/

^ that doc covers how you do step 1/ basically but covers all the different cases you can get into. While it does not cover PaymentSheet, it is analogous, whatever you do in Stripe.js (on web), you can ~do in PaymentSheet

and the rest of the steps sound right!

#

Pass payment_behavior=default_incomplete when creating a subscription. If your subscription requires payment, it’s created with status incomplete, otherwise your subscription immediately becomes active.

passing payment_behavior=default_incomplete when creating the Subscription is important, for the approach I was pitching

candid sigil
#

Ok perfect, that makes sense now. Just 1 last thing, can the PaymentSheet be presented by passing either a SetupIntent or PaymentIntent in? The client doesn't need to be aware what type of intent it is?

ionic crystal
#

PaymentSheet be presented by passing either a SetupIntent or PaymentIntent in?
yes PaymentSheet supports both

The client doesn't need to be aware what type of intent it is?
they do not. They just interact with PaymentSheet to enter a credit card (or other PaymentMethod) to pay for a Subscription (either now, or sign up for trial with payment later)

candid sigil
#

Ok perfect. That sounds good. I'll have a go at that. Thanks a lot for your help!

ionic crystal
#

no problem, great to bounce ideas on this!