#dbugger-pricingtable-login

1 messages · Page 1 of 1 (latest)

silk whaleBOT
terse yacht
#

Hi there 👋 we're happy to help answer questions about our (Stripe's) APIs, SDKs, or features, but how you plumb that into the rest of your system is largely up to you. We aren't familiar with your entire system landscape, and likely aren't familiar with the specific pieces you're using to build your stack.

Is there something about the Stripe side of this that I can help answer?

uncut arrow
#

Well, I am not really asking to help me "plumb it into my system" as I am asking "what is the default/usual/recommended way to plumb it in this case?"

#

It kinda confuses me that it is possible to buy a subscription plan for a Saas before even an account for that service has been made

terse yacht
#

Agreed, if you need your users/customers to have an account with you first, I would expect you to require them to create one before allowing them to get to a surface where they can start a Subscription.

uncut arrow
#

It is not that I "need" my users to have an account with me first... but it just confuses me that this is actually possible. Like... how would that even work?

I have a pricing table done in the dashboard, which I have put on my landing page (to show the possible plans) but those buttons land me directly into a checkout process. So a user can pay for a subscription plan in a system that has not even signed up yet. That seems kinda bizarre.

And leaving that aside, if they make an account after buying the subscription plan... how is my system supposed to know which one they bought?

terse yacht
#

What you're describing is largely the flow of your own site it sounds like. If you don't want to allow your users/customers to start a subscription without an account, I would not recommend surfacing the Pricing Table to non-logged in users.

Have you taken a look at this section about handling fulfillment after a customer completes payment from a Pricing Table?
https://stripe.com/docs/payments/checkout/pricing-table#track-subscriptions
You'll need to build a webhook endpoint that we can send Events to as Customers complete the checkout experience, so we can notify you about their payments/subscriptions.
https://stripe.com/docs/billing/subscriptions/webhooks

uncut arrow
#

Yeah, I read that page, and made the endpoint already

#

Give me 5 min to read the whole page again, just to be sure I didnt miss anything

silk whaleBOT
undone crater
#

dbugger-pricingtable-login

uncut arrow
#

Yeah, pretty much what I remembered

#

What you're describing is largely the flow of your own site it sounds like

My site still has no flow. That is what I am trying to decide now.

undone crater
#

We don't really have a specific recommendation for something like this. Most options work, depends on how you want this to work

uncut arrow
#

What I am trying to find out is... let's say that I offer the pricing table before the sure even makes an account on my system.

How would I be able to know what subscription they purchased, once they do register?

undone crater
#

They would pay on Checkout and you'd get a checkout.session.completed Event and can do fulfillment, including getting them back on your website to claim an account for example

uncut arrow
#

So, once the checkout is completed, Stripe calls my webhook with "checkout.session.completed", right?

undone crater
uncut arrow
#

But if when I receive that call on my webhook, the user still has not made an account... how would I know what I am supposed to do with that event?

undone crater
#

I'm sorry, I'm not sure how to explain this differently, that's up to you here. If you absolutely need an account then you should require one upfront. If you don't need one, then you don't and get them to create one after they paid.
Both flows are extremely common on the web where some websites require you to register first, others will let you pay as a guest and at the end ask you to create an account optionally with a password linked to the email address you used

uncut arrow
#

I do not need an account. I am asking how would that be doable, without one.

undone crater
#

We (Stripe) have no concept of an account and this is purely in your app

uncut arrow
#

Of course, but when a user registers in my app/system/service, I need a way to find out if they have already purchased the subscription

#

And I have no clue how to do that

undone crater
#

but when a user registers in my app/system/service
so then you do need an account? You said the opposite earlier?

uncut arrow
#

Users do need an account to use my service. But what I am asking is, if I let them purchase the subscription before they register... how can I know if they purchased it, once they register?

undone crater
#

you can match on the email address for example. You can email them a one-time use link to get them back to sign up. Many possibilities I would say but those are the 2 options I can think of in a few seconds

uncut arrow
#

That is assuming the email of their stripe account is the same email as the one they use on my service, no?

undone crater
#

Correct

uncut arrow
#

That doesn't seem like good idea...

When I receive a checkout.session.completed event, is the email of the buyer in the data object?

undone crater
#

yes

#

If you absolutely want a match then force an account upfront

uncut arrow
#

Well, leaving all that aside... Let's say that I do create an account before the purchase. Then the workflow sounds like it should be like:

  1. The user signs up
  2. The user sees a pricing table.
  3. The user chooses "Premium plan" and completes the checkoug
  4. My app receives an event on my webhook,
  5. I update the "subscriptionPlan" field in my user table as "premium".
#

But what would happen if (by whatever reason) the webhook were to fail?

#

How can I now afterwards figure out if the user paid for the premium account or not?

undone crater
uncut arrow
#

ahmmm...

#

Dunno, I am still quite confused by the whole topic, not sure how to plumb it all together...

#

The fact that the users have the ability to sign up for a subscription without an account (let's say for the sake of the argument, that I mess up and I render the table outside of my webapp), seems kinda like a risk that I wouldnt know how to handle later on

undone crater
#

Yeah not sure what to tell you further I'm sorry. I don't really see the risk

uncut arrow
#

Well, the risk is that, if they managed to buy the subscription before making the account, I would have to find a way to check this

undone crater
#

you can use this to tie an existing Customer id to your PricingTable.

#

So if someone pays on Checkout for some reason with a different cus_123 you never saw before in your database, you can alert and reconcile manually by reaching out to them for example

uncut arrow
#

That doesnt help, because to provide a "customer id", I must have created it before, and to do that, I must have linked it to an existing account

undone crater
#

Sorry that seems like an "off the cuff" response with no digging

uncut arrow
#

why?

#

That solution suggest that I can provide a client id

#

Which I cant, if I assume the account comes after the checkout

undone crater
#

This is absolutely not correct. You create the Customer, so you know you are doing it. You do it when they have an account with you. So if you ever get a Checkout Session Event with a different customrer id you have never heard of then you know for a fact it's not one of yours

uncut arrow
#

Yeah, of course. If you assume the account comes before the checkout, that makes sense

uncut arrow
undone crater
#

sure and what I said after is my response to that

uncut arrow
#

Your response to that was that I can use a customer id, but as you said yourself:

You create the Customer, so you know you are doing it. You do it when they have an account with you

Which is the opposite of what I was asking:

Well, the risk is that, if they managed to buy the subscription before making the account

undone crater
#

it's not, you just think it is

#

If it's not one of your customer ids, then you know they found a way to pay on Checkout without having an account with you.

uncut arrow
#

"One of my customer ids"? I cannot have those without making an account first.

#

or at least, I wouldnt know how

undone crater
#

😅

#

I'm sorry you're looking at it differently and you aren't really seeing my point right now you just push back.

uncut arrow
#

Why are you saying that?

#

I understand what you are saying, but I am not understanding how to use that system without creating accounts before checkout

undone crater
#

You are trying to catch when someone has paid on Checkout but haven't created an account with you.
I am giving you a way to do that: make sure to associate an existing Customer id with your PricingTable and hide it being the creation of an account in your system. This guarantees that anyone signing up with your service first and then paying on Checkout has an existing Customer id.
With that in mind, anyone who pays on Checkout without a Customer id you have in your database is explicitly a customer that figured out a way to do this without signing up first. Now you know who they are and you can have them create an account with a manual recovery flow

uncut arrow
#

and hide it being the creation of an account in your system.

Is there a typo there? Sorry, I did not understand that

#

(English is not my first language)

undone crater
#

No there's no typo there. We are discussing a flow where you force customers to create an account before they get to Checkout

uncut arrow
#

The word "being" there is kinda throwing me off, I meant

undone crater
#

ah yes my bad you're right, this should read behind

uncut arrow
#

Oh wait, I think I get it... you are suggesting it as a sort of "secret sign up"??

undone crater
#

and no, nothing is secret

uncut arrow
#

Ok, let me reread it

undone crater
#

Really it boils down to: either create an account upfront, or create an account after the payment. There aren't really alternatives. So you have to pick one and start building and get a feel for it

uncut arrow
#

Ok, so if I understand correctly, what you are saying is:

"Just show the checkout buttons to the users that have already registered, and if someone manages to do the checkout without registering first, it's their fault for hacking the system"

#

Is that right?

undone crater
#

yes and I explained how to detect it so that you can manually fix it

uncut arrow
#

Now you know who they are and you can have them create an account with a manual recovery flow

What is the "manual recovery flow"?

silk whaleBOT
undone crater
#

You alert someone at your company "Customer cus_123 signed up for Subscription sub_123 with the email address test@example.com and doesn't have an account in our system" and then that human goes and figures out what happened, reaches out to the customer to have them create an account, etc.

uncut arrow
#

Ahmm...

#

I was hoping there would be a way to prevent people from purchasing the subscription without the account done... but I guess there isnt

undone crater
#

no if there was we'd have said that a long time ago in this thread 🙂

#

Like it's on you to block showing PricingTable at all without an account. This shoul be really simple to guarantee as the developer honestly

#

I just addressed your concern if there's a bug and showed you a way to alert if it happens. It should never happen though.

uncut arrow
#

So, all in all, it never really makes a sense to offer a pricing table with checkout in a Saas landing page, no...? I mean, I cannot imagine a case where this could make sense

undone crater
#

Not at all, it doesn't make sense for you

#

the majority of merchants I've spoken to in the past year use PricingTable and do the account creation async later (what I recommended you did earlier). It just worries you (which is fair) and I gave you an alternative.

#

If it were me I would make it as easy as possible to sign up and then figure out account creation after the payment

#

I have to run but @zinc dove can help if you have more questions

zinc dove
#

👋 Hello!

uncut arrow
#

Hello Rubeus, thanks for coming

#

Did you catch up on the conversation?

zinc dove
#

Yep. Most people in this situation listen for checkout.session.completed and create an account using the information provided during Checkout. They then send an email with a special link that lets them set up their new account.

uncut arrow
#

So you mean, like, creating a "uninitialized account", that needs to be setup up by the owner of the email (like giving it a password or username)?

zinc dove
#

Yeah, if that's what you need to do. As my collegage mentioned above, we have no idea how accounts work on your end. Some systems only use an email address and have no separate username. Some systems don't use passwords and instead send login links via email. All of that is entirely up to you and is something that happens outside of Stripe.

uncut arrow
#

The way account work on my end is not decided, so I can change it if necessary, you do not need to worry about that

uncut arrow
zinc dove
#

Which email? The one you tried to send them?

uncut arrow
#

Yeah

zinc dove
#

You can handle that however you want. Again, that happens entirely outside of Stripe, so we don't have any involvement or recommendations there.

uncut arrow
#

So I guess that means that... there is no way for me to enforce someone to make an account on my site, before purchasing my product

#

right?

zinc dove
#

You can do that if you want to. Don't display the Pricing Table unless someone is logged in.

uncut arrow
#

Yeah, of course I can do that. But I can do a mistake and render the table outside of the "User area".

#

I was just wondering if there was a way to enforce it, outside of the domain of my product

#

But I guess there isnt

zinc dove
#

Can you explain how you envision such a system working? Maybe I'm not understanding what kind of feature you're looking for.

uncut arrow
#

It is not really about "feature". It is more about "security". I just want to avoid me problems, by assuming that "users are stupid" 😛

zinc dove
#

If Stripe has no concept of user accounts on your end or how they work how could we use those accounts when determining a course of action?

uncut arrow
#

I want to avoid them doing things that might give me trouble later

zinc dove
#

That's something you need to handle on your end.

uncut arrow
#

Yeah, of course. I was just wondering if there are ways to do it outside of the domain of my project.

#

As in... for example... if a user send a "payment link" via email to a friend without an account, you know?

#

(just an example, not saying that I will have payment links)

#

But yeah, if you say that I can only control that from within the domain of my project... then I guess that is that

zinc dove
#

No. In such a system using Payment Links would not be a good idea, you should instead have links that point to your server, and your server would perform checks to see if someone was logged in before generating a Checkout Session for that specific visit.

#

Payment Links are designed to be shared with many different people and allow anyone to pay, so they wouldn't be the right fit for that use case.

uncut arrow
#

It was just a way of saying: "I can make mistakes, and I could render things in my system where they shouldn't. So I would like to know if Stripe could be configured to back me up in the security department, in case I made those mistakes"

#

But yeah, I guess it cant

zinc dove
#

Not in the way you're describing, no.

uncut arrow
#

Would you happen to know a couple of sites that do what I am trying? I would love to see how others are handling this scenario

zinc dove
#

I don't know any offhand, no.

uncut arrow
#

Well, thank you and @undone crater and @terse yacht for your help

zinc dove
#

No problem, good luck with your project!

uncut arrow
#

I will need it. Stripe is hard 🤣