#nerder-Subscription

1 messages · Page 1 of 1 (latest)

wet dust
#

Hi there, are you using Checkout in your integration?

woven ore
#

Hey Jack, no

#

we have a custom integration

dire pawn
#

Im doing the same here.. i have a trial without a payment method.

woven ore
# 
    const stripeSub: Stripe.Subscription = await this.stripe.subscriptions.create(
      {
        customer: customerId,
        items: [
          {
            price: priceId,
          },
        ],
        application_fee_percent: feePercentage,
        payment_behavior: 'default_incomplete',
        expand: ['latest_invoice.payment_intent', 'pending_setup_intent'],
        trial_period_days: trialDays,
      },
      {
        stripeAccount: stripeAccountId,
      },
    );
#

this is how the code looks like

wet dust
#

Ok, since you have trial_peroid here, the first invoice doesn't requires payment, so I think the latest_invoice.payment_intent should be null.

#

@dire pawn Thank you for jumping in! and welcome to join the discussion!

woven ore
#

that's why we need to so something like this:

    let clientSecret = ((stripeSub.latest_invoice as Stripe.Invoice).payment_intent as Stripe.PaymentIntent)
      ?.client_secret;
    let isSetupSecret = false;

    // https://stripe.com/docs/billing/subscriptions/overview#non-payment
    if (clientSecret === undefined) {
      clientSecret = (stripeSub.pending_setup_intent as Stripe.SetupIntent).client_secret;
      isSetupSecret = true;
    }

    if (clientSecret === undefined) {
      throw new Error(`Could not extract client secret from subscription ${stripeSub.id}`);
    }
#

we try to find the client secret from the latest_invoice payment intent, but since when there is a trial there is none

#

than we get that from the pending_setup_intent

wet dust
#

OK it looks good to me. So when do you plan to remind your customer to set up the payment method? are you listening to the customer.subscription.trial_will_end events?

woven ore
#

At the moment we don't, basically we simply fallback on the frontend on a screen that ask them for their payment method

#

But ideally we would love to not go there and don't activate the sub entirely in such scenario

wet dust
#

OK. Maybe you should consider listening to this event and remind your customer later.

woven ore
#

This is one great option, we will consider it for sure

#

but still seems like a workaround and not the ideal UX

wet dust
#

Sorry I'm confused, what do you mean by not activating the subscription?

#

Or can you tell me a bit more on what you want to achieve?

woven ore
#

Ideally I would not have customer with a sub in trialing without a payment method attach to it

#

basically I would like to have a similar UX, as to when there is no trial

dire pawn
#

I think it you set a customer in to a trial, it will be "trailing" for that period (with a subscription attached) then a webhook will send you 3 days before it expires. you can use that hook to do anything, send email, extend trail etc.

woven ore
#

so if for some reason (ie: 3D Secure auth fails) the customer could not attach is payment details than the subscription doesn't get created

dire pawn
#

the subscription is always created , i think

woven ore
#

What is weird for me of needing to use the reminder, is that from the prospective of the client they don't understand why we ask them for their payment details again since we already done that

dire pawn
#

if your in a trial you must have a subscription.

#

if you have asked them for the payment upfront, and it is default payment, then it will go from trial to active.

woven ore
#

From their prospective this happens:

  1. They choose a sub (with trial)
  2. Insert their payment details
  3. See the sub created, but they have no payment method
#

what is actually happening is this:

  1. They choose a sub (with trial)
  2. Insert their payment details
  3. They fail 3D secure auth
  4. A sub is created, but no payment method is attached to it
dire pawn
#

Ahh.

woven ore
#

Of course this does not happen to every customer, only the ones in this scenario

dire pawn
#

then dont call the create subscription api if the payment fails no?

woven ore
#

and this makes the experience a bit clunky, because they need to insert again their payment details and don't understand why since we don't show any error or anything (since from the Stripe prospective is all good)

dire pawn
#

so you need to clean up your ui, to show them their credit card didn't go through ( i assume you are using stripe elements and not checkout)

#

ill let @wet dust chime in here, now that its more clear

woven ore
#

Thank you @dire pawn, this and the reminder are 2 very valid options. But ideally I would like to error if incomplete

dire pawn
#

i think you will get an error in the response on the front end and improve your flow there so as to not confuse the user.. update your backend database as well that no cc is on file or status inactive or soemthing, next time they log in, they can be prompted to update payment again.. trigger an email as well.

woven ore
#

But using that in the payment_behaviour of course doesn't work since the first invoice is automatically paid

dire pawn
#

yes because a subscription was created, that wont happen unless you called the api to do so.

woven ore
#

Yes I got you, I need to make it in 2 steps. First collect the payment method and then let them create the sub

#

at the moment we are doing it at the same time as for non trialing sub, this wasn't the issue. If the payment method fails then the sub creation fails and is all good

dire pawn
#

i kinda wish stripe had a best practice flow page for saas subscriptions.. there are many ways to do the same thing.

#

Although i hope asking customers for cards up front (in a trial) works out for you seems like a tough sell, although i do see some apps do that nowadays

woven ore
#

I'll fail for an input from @wet dust on this tho

dire pawn
#

yes he's the expert

#

sorry i added my 2cents

woven ore
#

Yes, but in our scenario is a gym subscription not a SAAS sub

#

so it doesn't feel that weird to put down your payment details upfront

wet dust
#

Hi @woven ore @dire pawn my shift is over, my colleague Soma has joined this thread to continue helping you.

woven ore
#

Thank you @wet dust, have a good rest of the day

hollow notch
#

Hi there! Could you summarise your question?

woven ore
#

Hey @hollow notch, basically I would like to be able to make the sub creation fails when the customer has no default payment method attached

hollow notch
#

If you create a subscription with payment_behavior: "allow_incomplete" and the customer doesn't have a default payment method, you will get an error. Is this what you are looking for?

woven ore
#

but please take a moment to read the thread, as will it be more clear

#

the important detail here is that we have an initial trial period for this subscription

#

so I don't know how payment_behaviour plays here, being the first invoce for 0$ automatically paid

hollow notch
#

I see, creating a subscription with payment_behavior: "allow_incomplete" and without a default payment method, but with a free trial will successfully create a subscription. Let me run some tests.

woven ore
#

The behavior we want is error_if_incomplete for trialing subs basically

hollow notch
#

Unfortunately I don't think that's possible to do. That's something that you would need to manually handle by checking if the customer has a default payment method before creating the subscription.

woven ore
#

:(

#

Ok I'll try that, even if I'm a bit afraid that it might cause some weird concurrency issues

#

As a feedback I feel like that this behaviour should be handled by the Stripe backend

#

so that will support the 2 possible way of creating a trial, with mandatory payment details or without