#sodium-paymentlink-tracking

1 messages · Page 1 of 1 (latest)

amber scrollBOT
outer bridge
#

sodium-paymentlink-tracking

#

Hey @void dust, I'm not entirely sure I follow the ask. A PaymentLink usually is used to sell one thing to N people, not to identify a specific customer so I don't really get what UID you are referring to

void dust
#

context:

I'm selling a subscription to my product and on every customer request to my services, I need to know whether or not the customer is paying by querying stripe's api's with the customerID.

However, I have no way of knowing what the customerID of the user is if the customerID and userID aren't associated with each other in my database.

I need a way to associate the two fields together when a customer purchases a subscription.

outer bridge
#

yeah I don't really get it yet I'm sorry. If you use PaymentLink, you're going to like get a URL like https://buy.stripe.com/1234 and you're can like tweet this or something. There's no customer yet

#

if you already have an existing customer in your system and you want to start a subscription for them, you usually would use Checkout instead

void dust
#

forget the stripe link for a second --

when a customer buys a subscription to my product I need to know which userID in my database is associated with that customerID field from stripe so I can save the two together? Do you know how I can go about this

outer bridge
void dust
#

ok makes sense. and from there when the user decides to purchase the product I can generate a payment link asocaited with that customer id?

outer bridge
#

kind of. Really a PaymentLink is like a "factory for orders". You say "Oh I sell my book for $10, give me a link to email 50k people" you don't do a unique link per person.
So if your customer is on your app ready to pay, usually you just create a Checkout Session for their specific payment and tied to their Stripe Customer id already

void dust
outer bridge
#

I mean there are ways, but that doesn't seem like the right fit for you in the way you describe it at least

#

how are you sending the customer to the payment? Emailing them a link? Or they are on your app already ready to pay?

void dust
#

It's a small menubar app built in electron, so paying inside the window would be tough.

I guess emailing them a link, since I have this info, would be a good bet?

outer bridge
#

I mean not really, that's why I ask

#

If your customer is in your app and ready to pay, you redirect them to Checkout in real time

#

if your plan is to email them a link, it's different, because by default a Checkout Session's URL expires after 1 day so it wouldn't work

void dust
#

sorry if this isn’t making sense, kind of a niche use case

outer bridge
#

all good, you mostly really just need to use Checkout

#

does that make sense?

void dust
#

yes. I am creating a stripe customer when a user creates an account on my app.

when the user decides they want to buy the product, I create a checkout session passing in that customerID from stripe.

#

does that make sense? 🙂

outer bridge
#

yes!

void dust
#

thank uuu and best of luck with stock options 😉

#

or RSUs* hehe

outer bridge
#

lol thank you

amber scrollBOT
void dust
#

lmao

amber scrollBOT
void dust
#

chill dingbot we good here

outer bridge
#

haha sorry we're testing a new feature 😹

#

usually we have to join existing threads one by one and it takes like 4 clicks each time and @misty mantle just built a command for us that joins them all automatically

void dust
#

oh sweet. can you tell the colly bois to opensource dingbot though?

#

not a joke

outer bridge
#

lol one day maybe

void dust
#

@misty mantle I have a fat angel check for dingbot spinoff. ya'll know where to find me...