#Indira
1 messages · Page 1 of 1 (latest)
Hi there
Hello...
So sounds like you are trying to set metadata on a Checkout Session created by a Payment Link?
I am not creating a new session as such but I am just trying to send out some parameters so that I would be able to update my database with the payment status example Paid etc... We are using Payment Links in the process... While reading the documentation I understood that we are supposed to use metadata in such cases...
So yeah metadata would be a way to do this if you are creating a Payment Link via the API
To be clear, the metadata that you set when creating the Payment Link would then be carried down to every Checkout Session that results from that Payment Link
That is what you want?
Or you want each session from the Payment Link to be dynamic?
Payment Links are already created through the dashboard... And sorry, I didn't understand what you meant by being it dynamic...
My scenario is say, user-123 has to pay some amount, while navigating to the payment link page, I set three parameters.. one client-reference-id(this part is clear to me) the other two values if I have to set through metadata, I saw that the whole payment link is getting updated...like {metadata: {userId: 123, appURL: "abc.com"}} is seen on the payment link on the dashboard directly. At the same time, say if other user, say user-345 wants to do a payment, will there not be any conflict or overlap of data? Is this the right way to do? Please let me know if you need more information.
no problem, i understand
Yeah so if you set metadata on a Payment Link then that metadata will be associated with every Checkout Session that the Payment Link creates
So if that metadata is supposed to be specific to one customer, it won't work.
Are you storing the client-reference-id in your own database?
I'd assume so
In which case you should just store this other data alongside that in your own database
Then you can retrieve it all via the cleint-reference-id
yes, I am doing that already but I received a feedback from my team that we should be using some other checks also to update the database... by some other checks I mean, those two values that I was talking about, userId and app url...
Yeah this isn't really possible with Payment Links
To have this level of granularity you need to be creating Checkout Sessions directly
oh! So here in this case, while navigating to the payment link from the UI, do you think it's a correct way to keep updating the metadata for every user?
No, that really isn't the design of Payment Links and I would never recommend it
If two users try to pay at the same time they are going to have the wrong data
exactly...I too got stuck there
So, thinking out loud here, how can we utilize metadata, in such scenarios? You mean payment links are used when the metadata remains the same for every user?
Yes
Payment Links are meant for a one-to-many type of situation
Not one-to-one
If you need one-to-one then you need to create a Checkout integration that doesn't rely on Payment Links (you create the Checkout Sessions yourself so you can customize them)
oh! 😦
I really don't understand the issue here overall.... all you really need for your scenario is to use the client_reference_id that you are already using
There is no need to attach this other data to the Checkout Session itself
Just store it in your database alongside the reference_id and you are good to go
Basically, the client_reference_id is kind of a primary key (integer) in my case and I have my app hosted on multiple domains, say eu-site.com and na-site.com and different databases for each. So, in this case, I cannot just update based on the client_reference_id because all the webhooks will be called at once and I need to write specifically for which server and user I want to update...
Then you should have a UUID for each customer in your database and that should be your client_reference_id
ok...sure thank you so much Bismarck, for your time...:) I will check for the possible options at my side and get back to you in case there are any gaps.