#rahatkuk - subscription flow

1 messages · Page 1 of 1 (latest)

idle stone
#

Hi there! Reading this plan, will respond shortly

grizzled plank
#

👋 I'm also hopping in since @idle stone needs to head out soon

#

Reading through your overall approach it sounds good to me, but was there a specific piece/step you were particularly worried about?

magic stratus
#

Can you please list how it would be implemented with Stripe (with APIs paymentIntent, setupIntent...) for this flow for both a product with and without free trial?

grizzled plank
magic stratus
#

Yes, I understand and have read through the docs. I would like to hear from you on what you do support and what you don't on the flow I listed above.

#

To me, it's not clear from the docs.

grizzled plank
#

We support your whole flow - the doc I linked you to covers how to do this in the non-trial use case. For trials instead of using the Payment Intent you'd use the Setup Intent found at pending_setup_intent on the Subscription (see https://stripe.com/docs/api/subscriptions/object#subscription_object-pending_setup_intent) and you'd use that with Elements to collect the card details. From there, as long as the Payment Method generated from the Setup Intent is set as the default on the Customer, we will automatically use it to charge when the subscription renews

Stripe API reference – The subscription object – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

magic stratus
#

Can you explain when a subscription object is created? and whether the paymentIntent or setupPaymentIntent need to be completed in order for the subscription to be created? We are having trouble understanding how these states are transitioned. thanks!

grizzled plank
#

If you're working with Subscriptions you don't need to create Setup or Payment Intents yourself - you create the Subscription first, and we generate the intents for you

magic stratus
#

Ok, and if you generate the intents for us - can we ensure that the service is only provisioned once payment is collected and verified successully?

#

We are indeed working with subscriptions as I mentioned above.

grizzled plank
#

Well what do you mean by "the service is provisioned once payment is collected and verified successfully" - provisioning the service would be something you do on your end, and you'd want to do that after the Subscription transitions to the "paid" state

magic stratus
#

Yes, of course we would provision the service. I'm referring to the fact that before we initiate - 'start trial' or 'provision service' we look for what you just said which is the subscriptionStatus transition to "paid"

mortal dock
#

I want to chime in here. I am working with Rahat to implement this. The concern here is when a subscription with a trial is created, which would be the first step, it is automatically active (or in 'trialing') state. Is there a way to create a subscription that is incomplete until we collect payment (trial or not) ?

grizzled plank
#

For the non-trialing subscriptions where collection_method: charge_automatically ) that's the default behavior - the subscription will be in an incomplete state if payment is due. The issue is I don't think we have anything like that for trialing subs, but something you could do instead is check that the Subscription or Customer has a default Payment Method to verify they've submitted payment details

magic stratus
#

I thought you just said that you support the full flow I listed above? I still don't understand what you don't support.

grizzled plank
#

We specifically don't support a Subscription being incomplete if it's trialing, but that doesn't mean there aren't other ways to accomplish the flow you want. I already gave one suggestion of checking that payment method details has been submitted before "provisioning" the service. Another alternative would be to collect payment details through a Setup Intent (that you create yourself) and only continue with creating the trialing subscription once the Setup Intent is confirmed

mortal dock
#
  1. The creation of setup intent works but i was told by a member of your team that this WILL cause 3ds issues, because we first call setupPayment(which may prompt for 3ds) and then create a subscription which may also prompts 3DS
  2. Check suggestion of checking the payment method doesn't really work because once a subscription is created with a trial, its trialing, which means that all the dates and emails are going out to the customer, without us collecting a payment. If the customer quits before collecting payment (closing window or their payment doesn't go through), they are left with this active ('trialing') subscription.
grizzled plank
#
  1. Yeah that's correct, and it's why I'm trying to nudge you in a direction where you don't need to create this separate Setup Intent. If you do go down this route, I'd only suggest doing it for the trialing Subscriptions, not for Subscriptions that need payment.
mortal dock
#

so if i did that there will not be a 3ds issue for the trialing subscriptions?

magic stratus
#

Yes, can you please confirm that for trialing subscriptions, we can complete payment "off-session" without a 3ds requirement?

grizzled plank
#

one quick question - are you planning on using payment element, or are you just planning on accepting cards (so you can then use just the card element)?

mortal dock
#

we are using StripeElements

#

and we will be using wallet options (googlePay, applePay)

#

and card

grizzled plank
#

So you specifically mean the Payment Element? There was a different workaround I could think of if you were using Card Element, but it wouldn't work for Payment Element

mortal dock
#

correct, PaymentElement is what we are using

#

beucase from what i understood, card element is only for card and there are no wallet options

grizzled plank
#

Yeah, that's correct - the benefit would've been that you could've used the Card Element to generate a Payment Method object, and then use that Payment Method with the pending_setup_intent

#

I think limiting this workaround (the creating a Setup Intent beforehand) will be okay if you limit it specifically to trialing Subscriptions that have no one-off Invoice Items (so no payment is required at all for the Subscription), but let me just think through this a bit more

#

I'm sorry we don't better support this - most merchants want the exact opposite of what you want. They want to allow customers to be able to trial w/o proving any payment method and be able to add it before the renewal

magic stratus
#

We are like every streaming subscription service out there. None of them provide a free trial without payment method collection.

grizzled plank
#

That's fair, and it's one of the downsides of our Subscriptions API - there's so much variation in what merchants want that it's hard to build something that's ideal for everyone

#

Let me just try a couple of tests on my end to check some things - give me a few minutes

magic stratus
#

Ok, thanks for trying. Seems like an obvious use case for subscriptions to us but part of the problem is that your documentation is a bit of a maze to figure out which routes make sense for us and which don't.

grizzled plank
#

Okay, so when you create the trialing Subscription you need to be careful and make sure you set payment_behavior: default_incomplete . And again, I don't think this is a good idea, but if it's something you want to explore then you should only do this with trialing subscriptions/subscriptions that require $0 payment on creation.

#

I think a much safer workaround would be to use the Card Element + Payment Request Button to create Payment Methods before creating the Subscription (do not attach them to the customer at this point) and then pass those payment methods in to the Setup Intents that are created with the Subscription

mortal dock
#

to your first message: so for subscription products that do not have a trial and require payment, what do we set the payment_behavior to?
to your second message: but if we use card element, then we won't be able to provide wallet options, right? is there another way to achieve using wallet options along with card besides using PaymentElement?

grizzled plank
#

For the non-trialing/requires payment subs you'd also probably want to use payment_behavior: default_incomplete - I just want to be sure to call this out for the trialing case since the difference in behavior when no payment is required is more subtle. When payment is required the difference is more obvious because we won't attempt payment/confirm the intent with default_incomplete

#

I need to head out, but hopefully that helps! If you need anything else @sand eagle can answer your questions

mortal dock
#

before you go, could you tell me a bit more about this:
I think a much safer workaround would be to use the Card Element + Payment Request Button to create Payment Methods before creating the Subscription (do not attach them to the customer at this point) and then pass those payment methods in to the Setup Intents that are created with the Subscription

sand eagle
#

Yes - let me catch up here

mortal dock
#

trying to understand the flow or steps on what needs to be done as part of this flow thats described

#

when is setupintent created how its attached to customer and when is setupPayment called and when is subscription created

#

and will it be the same flow for both subscriptions with trials or without trials?

sand eagle
#

You'd collect the card details with Card Elements and support wallets separately by using the Payment Request button which you can then creates the PaymentMethods

mortal dock
#

ok so then once i have the paymentMethod, i create a subscription with that payment method? What do i call instead of stripe.setupPayment to validate the card?

#

could you write out the full flow if possible please

#

also, it looks like it requires a payment intent first. Our product selection is on the payment page, which means that i'd have to create a payment intent for every product (due to different amounts).

sand eagle
#

Typing..

mortal dock
#

and this will work for BOTH products with a trial and without a trial?

sand eagle
#

yes!

mortal dock
#

reading the card element docs, it talks about creating a payment intent first. Won't this charge the customer as soon as i call confirmPayment?

#

I don't want to charge until trial expires ( in a case of a product with trial)

grizzled plank
#

👋 Hopping back in - give me a minute

#

The card element docs talk about creating a Payment Intent, but it's not a requirement - you'd use createPaymentMethod with the card Element (https://stripe.com/docs/js/payment_methods/create_payment_method) to JUST create the Payment Method. These flows aren't well documented because for most users they want to collect the payment details at the same time as confirming the intent.

#

Generally, I'd recommend limiting this to just your trialing flows so that you can stick with the recommended flow for the majority of cases, but it's really up to you

mortal dock
#

ok, could you please write out the flow step by step, because i am still unclear on what needs to be done

#

oh i thought @sand eagle said that i could use this flow for both

#

i am trying to reduce complexity which is why i was interested in this flow

grizzled plank
#

I see - so you're hoping for an integration that would be able to be consistent across both

#

Give me a minute to just write out all these steps

mortal dock
#

yeah

#

thank you

grizzled plank
#

(I'm just talking through the Card Element here, you'll need additional logic for the PaymentRequestButton)

  • Mount the card element
  • Call stripe.createPaymentMethod on submission (you can see a small snippet/example of how to call this w/ the card element at https://stripe.com/docs/js/payment_methods/create_payment_method)
  • If it fails, then you don't want to continue w/ your subs flow
  • If it's successful, you'll get back a Payment Method and you have the guarantee that they've provided payment details
  • At this point you can now proceed with creating your Subscription. You'll want to create it with payment_behavior: default_incomplete so that it doesn't attempt payment right with creation
  • After creating the Sub you'll get back a Payment Intent or Setup Intent - you would use those intents with either stripe.confirmCardPayment or stripe.confirmCardSetup depending on which intent you're working with. You can pass the Payment Method ID that you previously generated when you call these (see https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-data-payment_method for where you'd pass it in with confirmCardPayment)
  • For Payment Intents if confirmation + payment is successful then the Subscription will then transition to an active state.
#

Ah, and you'll also probably want to set payment_settings.save_default_payment_method to on_subscription so that the Payment Method is automatically saved as the default for the Subscription to be used for renewals

mortal dock
#

ok this is interesting. What happens if i've created a subscription with trial and the call to stripe.confirmCardSetup requires 3ds and customer is not able to get through that?

grizzled plank
#

Mmmm that's an interesting one

#

Yeah if you get into that state then the PM won't be set up correctly for the future renewals - which gets you back to needing the extra Setup Intent before you create the Subscription

#

😦

mortal dock
#

yeah 😦

#

any other options that you can think of? looks like i am only stuck with the one which you don't really recommend either

grizzled plank
#

I think Checkout got recommended to you earlier?

#

That's the only other option I can think of - Checkout requires a Payment Method no matter what, and I'm fairly sure it'd do exactly what you want

mortal dock
#

Checkout means your checkout experience, not our custom one right?

grizzled plank
#

I need to head out soon, but is there anything else I can clarify before I leave?

mortal dock
#

i was told previously by another rep that Checkout also doesn't support requiring payments on trials

#

and that this is something that is in the works for you guys

grizzled plank
#

Let me double check, but I was fairly sure that this was the default behavior of checkout

#

I'd recommend testing this out yourself as well, but from testing it looks like:

  • Trialing subscriptions will NOT create the Subscription if setup fails during the CHeckout process
  • Normal subs will create the Subscription if payment fails, but they will be in an incomplete state and will automatically expire
mortal dock
#

ok thank you, i'll ask the PM if they want to use Checkout

grizzled plank
#

👍 Yeah i'd illustrate to them that this will be WAY easier than any of the other alternatives

#

good luck!

mortal dock
#

thanks for your help