#christhornham_best-practices

1 messages · Page 1 of 1 (latest)

tough relicBOT
wind escarpBOT
#

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.

tough relicBOT
#

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

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

olive laurel
#

Here's the additional information you requested:

#

I'm building a basic SaaS app with a paywall. Customers sign up, make a payment, and then get access to paid features.

At a high level, this is straightforward:

1 Customers sign up with an email address.
2 Customers make a payment with that email address.
3 Stripe sends a webhook indicating a payment was received.
4 I add the Stripe customer ID and a "paid user" boolean to my database.
5 When the customer logs in, I check my database to verify they are a "paid user" and grant access to my app.

But from a detailed perspective, this isn’t so straightforward.

For example, after receiving a "checkout.session.completed" webhook event, I tried to get the customer ID, but it was null. After digging around, I learned I needed to add a "customer_creation: 'always'" property when creating my checkout session. This important point isn’t mentioned in the quickstart.

Here’s another example: after my embedded checkout completes, I receive several webhooks, including:

  • payment_intent.succeeded: This occurs when a PaymentIntent has successfully completed payment.
  • checkout.session.completed: This occurs when a Checkout Session has been successfully completed.

To someone with limited Stripe knowledge, it seems like both events indicate a successful payment. So, why do I need both?

This is just scratching the surface. What about handling subscription cancellations or refunds? I’m not sure where to start.

I know the information is in the docs, but docs are enormous. It would take a week or more to read through everything. Even then, I might struggle to answer specific questions like whether to use "payment_intent.succeeded" or "checkout.session.completed" to respond to completed payments.

I understand Stripe offers extensive payment solutions, but I’d guess most SaaS businesses need a setup similar to what I described.

So, is there a practical guide for setting up this kind of payment system?

Thanks for your help!

craggy pivot
#

payment_intent.* events are only needed if direct Payment Intent integration is used

olive laurel
#

Ok. Let me dig into this tomorrow. I’ll likely just have to spend the time reading through all of the docs. I know that sounds like the obvious solution, but I didn’t realize stripe was so in depth and I’m trying to not waste time reading about hundreds of features I’ll never use.

Thanks.