#ironbeard_best-practices

1 messages · Page 1 of 1 (latest)

worthy daggerBOT
#

👋 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/1268666552824102983

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

topaz skyBOT
#

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.

normal yoke
#

Hi there 👋 that's a bit tricky to answer, as it would typically be your business requirements that dictate whether you should create multiple Subscriptions for a Customer. You are correct that payments are made for a single Invoice at a time, and can't span Subscriptions. (I think you can work around that last part by crediting payments to the Customer's balance, and letting that balance auto-pay newly finalized Invoices, but that's getting into the weeds a bit).

If you have distinct billing periods, for instance one product that bills monthly and another that bills weekly, you'd use two separate Subscriptions for that.

manic wraith
#

Yeah, hmm. Everything is annual. We also offer a Newsletter (email PDF), and I started doing separate Subscription objects for the Newsletter vs the data access bc 1) We needed to billing_cycle_anchor='now' for Subscription upgrades to guarantee that people played for the full amount of the upgrade, but 2) if someone was subscribed to the newsletter + data access on the same subscription, then the billing anchor meant they'd have to pay in adance for more time on the newsletter subscription before their existing subscription expired.

This lead to me creating separate Subscriptions for customers who wanted both, and having to use Card Element to process two payments at the same time, but it feels a little hacky

normal yoke
#

Yup, that's another great scenario where multiple Subscriptions are a good fit, where you need to be able to adjust the billing cycle for one product's subscription without impacting another.

In that case you can use Setup Intents to collect payment method details from your Customers, and then manually make requests to pay their Invoices using the Payment Method that was created.

manic wraith
#

Yeah, I'm not very familiar with SetupIntents (yet) but someone else recommended that. I'm hosting my own checkout, so does that mean I do

  1. Collect Customer info in a form, create Customer object in backend and a SetupIntent to get a client-secret
  2. Pass the SetupIntent client secret to front end PaymentElements, which will collect payment info from customer (or let them choose a default payment method if they're a returning customer).
  3. Create the multiple subscriptions on my backend after the success_url redirect?

One of the benefits of creating the Subscriptions first (and passing their payment intent client secrets to the front end) is that I could display the invoice with any prorations etc to the user. How would I get that info? Can I still create the Subscription before the payment info is collected, and then pay it after the fact?

normal yoke
#

Yup to all of that.

Here is our guide for using Setup Intents with the Payment Element to collect PM details:
https://docs.stripe.com/payments/save-and-reuse?platform=web&ui=elements

When creating the Subscriptions, you can set payment_behavior to default_incomplete, as long as they aren't free Subscriptions, which will allow you to manually process the first payment but still give you the Invoices to work with to get the amounts to show:
https://docs.stripe.com/api/subscriptions/create#create_subscription-payment_behavior

Set up future payments

Learn how to save payment details and charge your customers later.

Create a subscription | Stripe API Reference

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

worthy daggerBOT
manic wraith
#

Interesting, great! I think the last piece of the puzzle I need now is this:

If I wanted to provide the Newsletter subscription to free to people who buy the data subscription, is there a way I could automatically apply coupons to these types of invoices?

For instance, if someone was subscribed to just the newsletter, but then a few months later added the data to their subscription, if billing_cycle_anchor='now', then they'd pay the full amount for the data subscription right then, but I'd like them to not have to pay for the newsletter at that point.

tacit steppe
#

Hello again

manic wraith
#

hey 🙂

tacit steppe
manic wraith
#

Gotcha, I'm familiar with creating coupons and promo codes, but I'd need to assess whether the coupon is relevant and apply it manually, right? I dunno why there would be, but just checking that there's no kind of "automatic" type thing for subscriptions involving prices related to coupons.

tacit steppe
manic wraith
#

Yup, makes sense. Thanks so much 🙂