#zaknz
1 messages · Page 1 of 1 (latest)
Hi there, is your customer using the same email address when subscribing the products?
yes they are
Do you have the subscription IDs?
(actually it is just me & a colleague, I'm evaluating Stripe for my payment integration)
sure one sec
sub_1MwUIsJdX8lIDNiaLAHRdBZZ & sub_1MwUKlJdX8lIDNiacwKlP3eI
Thanks for the ID.
It's a limitation in pricing table that you can't specify a customer object to associate with the checkout session that the pricing table creates.
I'd suggest you to only display pricing table for the first-time customer, and programmatically create checkout session and specify a customer for returnning customer (https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer)
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
ah yea okay. I was hoping to not have to have authentication on this main website and have it just be a static site with a pricing table. So you're saying in general if I care about customers being able to see their prior subscriptions I need to ensure that they do not access the pricing table. Since I cannot really control this (they might revisit the plans section of the site after some time so aren't logged in) it basically make the pricing table useless?
tbh if this is the case it actually answers my other question about starting a free trial without payment details as I guess I just need to create a Checkout flow (which supports customisation of payment method requirement for trials) and abandon my hopes of using pricing tables, which is a shame (lots more work).
Do you require a login for returning customer?
we were intending to use the Stripe "customer portal" for existing subscribers to manage their subs
OK. Let me ask around and see if there's another way to solve this problem.
awesome, and thanks for the help
one thought we came up with is on the subscription success event we could potentially detect that there is a duplicate customer with the same id, and replicate the new subscription over to the old one using the API, and delete the newly created duplicate customer, however that feels like such a risky bodge that I'm not comfortable with the stability of such a solution.
I'll see what you come up with, but my gut feel is that we need to switch to the Checkout flow, and host our own payment table
I can't find a solution for this right now, can I suggest you to reach out to Stripe support https://support.stripe.com/contact/email, tell them that you've talked to the engineer in discord so that they'll forward the ticket to us, and I'd continue to help you from there.
oh no prob, thanks for the investigation, will do.