#zombie-lord_api

1 messages ยท Page 1 of 1 (latest)

fallen hedgeBOT
#

๐Ÿ‘‹ Welcome to your new thread!

โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

๐Ÿ”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1318713744683040858

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

boreal wren
#

Hi there

earnest steeple
#

Hey

boreal wren
earnest steeple
#

This is for a subscription

boreal wren
#

Got it

earnest steeple
#

There's a 14-day trial

#

Ideal scenario is for them to put their payment info during the trial, in which case the scenario is a "setup" for later payment. But if their subscription expires then the scenario becomes "pay now to re-activate"

boreal wren
#

In that case, I recommend creating a Customer server side, creating a Checkout Session in subscription mode server side and pass subscription_data.trial_period_days or subscription_data.trial_period_end depending on how you want to handle it

earnest steeple
#

Hmm. I currently create the customer and their subscription at the time they sign up for the app. Then they go to a Billing page and can enter their payment info

boreal wren
#

Hold on a second. If you're using Checkout, you shouldn't create the Subscription server side. Checkout will take care of creating the Subscription object when you use subscription mode

earnest steeple
#

So the customer signs up for the app, and at that point I create a Checkout Session with subscription mode, instead of creating a subscription?

boreal wren
#

Correct

#

In subscription mode, Checkout will always collect payment details even if you're starting with a trial.

earnest steeple
#

But the customer will not be shown the Checkout form until up to 14 days after they sign up

boreal wren
#

No, that's not correct. You should show them the Checkout form when they sign up so they can share their payment details on sign up. They won't be charged until after the trial is over

earnest steeple
#

OK yeah that will hurt conversions a lot, I can't do that

#

My desire is to get rid of the initial version of the checkout form and switch to the fancy, modern-looking one, like in this screenshot

fallen hedgeBOT
earnest steeple
#

The goal:

  1. Customer signs up, and only provides email and password. As low friction as possible.
  2. I create a customer record and a subscription with a 14 day trial.
  3. As they use the app during the trial, I periodically remind them they should provide their payment info so they can continue using the product.
  4. At some point, they go to the Billing page and click a button to enter their payment info. This can happen during their trial, or it can happen after their trial ends and there is no payment on file and the subscription status becomes past-due.

Currently, clicking the button on the Billing page launches the modal on the left. It's old and looks outdated. I want it to launch the modal on the right. Ideally, everything else will stay the same. Is this possible? My understanding is that the new form also has the added benefit of supporting Apple/Google Pay.

copper yarrow
#

Hello! I'm taking over and catching up...

#

Yes, that's possible. For #1โ€“3 that's all stuff you would do on your end. For #4 you can use Checkout in setup mode to collect their payment information: https://docs.stripe.com/payments/save-and-reuse?platform=web&ui=stripe-hosted

Once you've set up their Payment Method for future use you can then add it as the default for the Invoices the Subscription will create at the Customer level: https://docs.stripe.com/api/customers/update#update_customer-invoice_settings-default_payment_method

Or you can set it as the default on the Subscription itself, if you don't want a Customer-level default: https://docs.stripe.com/api/subscriptions/update#update_subscription-default_payment_method

earnest steeple
#

OK, in your first link, steps 4 and 5 (actually just 4) seems to be what I need. Specifically:

const fetchClientSecret = async () => {
  const response = await     this.axios.get(`${this.$store.getters.getApiUrl}/subscriptions/create_checkout_session`);
    const clientSecret = await response.data;
    return clientSecret;
  };

  const checkout = await this.stripe.initEmbeddedCheckout({
    fetchClientSecret,
    onComplete: function() {
      this.verifyCheckoutSession(clientSecret)
      this.checkoutDialog = false
    }
});

Where I wait for the onComplete callback, then send the clientSecret back to the server, retrieve the checkout session with the expanded SetupIntent, and grab the payment_method from the setup intent and attach it to the customer using https://docs.stripe.com/api/payment_methods/attach.

copper yarrow
#

That seems worth trying in test mode to see if it works the way you want, yep!

earnest steeple
#

It's a bit weird that all this song-and-dance is needed though... if ultimately you guys have the payment method, why not attach it to the customer at the time they submit the checkout session form? ๐Ÿ™‚

copper yarrow
#

We do attach it to them. What we don't do is set it as their default.

#

Ah, that last part of what you said doesn't make sense, actually. It's already attached to the Customer, so you don't need to attach it again. I missed that on my first read through.

#

In fact, you should never directly attach a Payment Method to a Customer. You should use either a Setup Intent or a Payment Intent with setup_future_usage so the Payment Method is properly set up for future use. Checkout does this for you automatically in setup mode.

earnest steeple
#

So if the mode is setup, I don't need to do anything after the user completes the form in order for their payment method to get charged automatically once their trial ends?

#

I'm getting more confused as this conversation goes on

copper yarrow
#

Ah, sorry, I should have said that Checkout does this automatically in both setup and subscription modes.

#

So yes, Checkout will collect payment details, then the free trial will happen, then at the end of the trial those saved payment details will be charged.

#

I recommend you give this all a try in test mode. Seeing it all in action will make things much more clear. Note that you can advance time in test mode using Test Clocks, so you don't have to actually wait the 7 days: https://docs.stripe.com/billing/testing/test-clocks

earnest steeple
#

Okay, I'll try it tonight in test mode. I have the embedded form rendering, so now I just need to submit it. And also see what happens in failure modes etc.

Two more questions:

  1. If the user's trial has expired, and they have no payment method on file, and the subscription becomes past due, is this something I have to detect on the server side so that I can configure the correct mode for the checkout session I'm preparing? i.e. I assume it would be something other than setup in that case? Or does it all "just work"?

  2. After a successful submission of the checkout session form, how do I then display stuff like the last 4 digits of the card they have stored on file? Previously, I could fetch it from the response of the PUT request to the customer endpoint with [source: stripe_token]. Do I have to make a separate request to fetch the updated customer record?

copper yarrow
#

For #2, yeah, you fetch the Payment Method from the API and access the last4 on that.

earnest steeple
#

How does customer portal work if I don't want the user to leave my app?

#

My understanding is that it's a Stripe-hosted page.

copper yarrow
#

It doesn't. If you don't want them to leave your app that won't work.

#

In that case you'd need to use Checkout in setup mode, then after the payment details are collected you'd need to set them up as the default for either the Customer or Subscription and then attempt to pay the Subscription's latest Invoice.

earnest steeple
#

OK, that makes sense. I'll tackle the happy path first, then play with the other one

#

Thanks a lot for the help!