#coco-paymentlink-customerid
heady field
turbid hornet
What we notice is that the system will create a new custom record even if the email is that of an existing customer in our system
That is expected behaviour. We don't have any feature to "de-duplicate" Customer objects. When you use PaymentLinks, it's a low/no-code solution where you usually don't have any logic to identify a repeat customer, authenticate them, make sure you know who they are and that you can surface their card details and such. So it will always create a new Customer since you do recurring payments here.
If you want to pass an existing Customer id, you'd switch directly to Checkout itself. You'd create the Session server-side with the right Price(s) and Customer id(s) and then redirect the customer to their payment page that is only for them https://stripe.com/docs/billing/quickstart
kind goblet
The checkout link that you sent me seems to be completely custom....
what's driving us to look into this is that we are interested in creating promo codes that are specific to existing stripe customers. We would then like to use stripe checkout (eg the URL I sent before) to complete the purchase.
Is our use case just not possible with stripe checkout then?
turbid hornet
It's totally possible
Right now you are using PaymentLinks. It's a product on top of Checkout where you configure a "template" for a payment like $20/month, you get a URL like https://buy.stripe.com/12345 and then you share that URL with any customer. Each person who clicks on that Links will get a custom Checkout Session just for them where they can enter their payment method details and start a subscription.
Now you want a custom feature where you can say "hey when X loads that link, really it's Customer cus_ABCD so use that customer please". PaymentLink can't do that, it's just a link to a "template". But the underlying product, what you call Checkout, does support exactly that.
Instead of sending someone to https://buy.stripe.com/12345 you will have your server-side code call the Create Checkout Session API https://stripe.com/docs/api/checkout/sessions/create and pass the right information (Price id, customer id, email, promotion code, etc.) and then you redirect them to that Session's URL (similar to where they end up after clicking your https://buy.stripe.com/12345 link)
coco-paymentlink-customerid
kind goblet
I see let me take a look at that link.
While I do that, I have another related question to our use case. Basically, we are trying to do a winback campaign where we would like to offer a time limited discount to our customers.
Our current thought is our server would programatically create a new promo code targetted at that user. But to keep our dashboard clean, we are thinking of reusing the same promo code (eg. "WINBACK1"). However, we would need to be able to set a different customerId and expiration date each time we issue that same code.
Is that possible? Is there a better way to accomplish what we are trying to do?
turbid hornet
No that flow is impossible. You can't have the same "customer-facing code" limited to different customers. You'd need a code per customer
kind goblet
Would all those codes show up here and clutter the UI then?
turbid hornet
I mean it wouldn't call it "clutter the UI". But yes, they'll show up there.
Which seems fine for a temporary campaign.
kind goblet
Looking at this https://stripe.com/docs/api/checkout/sessions/create. I den't see a way to specify a promo code or coupon code. Am I missing something?
turbid hornet
all covered in details in that doc but in that case you would pass a Coupon id instead
I have to run but my colleague can answer future questions if you have more after reading this
kind goblet
let me see.
mmm... In https://stripe.com/docs/api/checkout/sessions/create, it talks about the call will return a checkout session object. But looking at https://stripe.com/docs/api/checkout/sessions/object, I don't see a field for the URL that I am suppose to direct a user to??
pastel surge