#SouffleAuChocola
undone cedar
Hi there
patent rune
Hello
undone cedar
What issue are you seeing on your prod account?
patent rune
is there any chance we could start a call?
I think it would be easier for me to explain
undone cedar
No I can only do chat, sorry
patent rune
Alright
Well , this code is used inside our API to send invitations to the users registering through a payment link
everything is working just fine with testing accounts but it does not work with production
patent rune
that's the thing , I am not returning any response/no errors are being shown
And I cannot attach the debugger to my azure production for a reason...
So the only thing I am left as options is to start treating those validations and return a response , or to check with you guys why it's not working
undone cedar
Okay well let's start with an example Event
patent rune
is there any way to see a sessions object based on a subscription ID without actually making an api call?
undone cedar
Can you provide an example Event ID that was supposed to be sent to that endpoint?
patent rune
well it is sent
and it goes throguh our API
everything goes well except that my function doesent work
is there any way I can see the sessions for this sub_1MlTlvH68GGkvBRApJQy2LjA subscription?
without having to make an api call and use those service.list?
because within the dashboard I've kept searching for it and I cannot see it
(Stripe dashboard)
undone cedar
You mean you want to see the Checkout Session List request response?
patent rune
for that subscription ID
for debugging purposes
to see if the custom fields appears there
and if a values is selected
undone cedar
No you can't see that. We don't return responses in the Dashboard for GET requests
One sec though
Let me check something
Hmm no thought you might be on too early a version of our .NET library but looks like you are using 41.8.0
You can look at an Event like https://dashboard.stripe.com/events/evt_1MlTlwH68GGkvBRA6ezuNxtg to see what would be returned for the object
You can see custom_fields are indeed present
patent rune
do these events differ from testing events?
patent rune
well , we clearly have to
but we've got a really pushy client...
and things like this happend...
undone cedar
Were you testing on a different Stripe account previously?
patent rune
well, I've just found the issue....
undone cedar
Oh?
patent rune
I think you should keep the same logic for both live and tests account when generating dropdown values
especially that these are not customisable by us
undone cedar
Hmmm that's strange
patent rune
- it's tranformed into and "and"
undone cedar
That feels like a bug to me on our end
patent rune
even if it has the same label
undone cedar
Can you give me the two examples where you are seeing that?
patent rune
2 payment links
configured exactly the same
"Something + Something" will end up having 2 different values between live and test accounts
on live would end up beeing "somethingsomething"
and on test would be "somethingandsomething"
does that make sense ?:))
patent rune
That feels like a bug to me on our end
I am aware that my functionality is lacking , but I think you should be consistent between live and tests account when generating background stuff which cannot be customized by us
Anyway , I love you for helping me finding this out ❤️
undone cedar
Yes I agree
Let me reproduce this
And assuming it is as you say then I'll file a bug report
patent rune
It destroyed my brains
undone cedar
And we will get this fixed up
Glad you were able to catch it!
And sorry for the hassle
patent rune
I think the best "fix" would be to let the users customize both values and labels for those dropdowns
just as a suggestion
can you let me know if that is indeed reproducing the way I've described or is it something particular for my account?
undone cedar
Yep give me a moment to test it
Hmm actually might be hard for me to test since requires livemode
One moment though, let me look a bit
sudden horizonBOT
undone cedar
Actually do you have the ID of the two Payment Links from above?
That would be helpful
patent rune
yes
actually no , I don't know how to get that ID , is not shown like usual inside the dashboard
oh , there you go
plink_1MlZ6vH68GGkvBRA8sK9jdGy
plink_1MeJoZH68GGkvBRAAjDpgD4t
first one is test
undone cedar
Perfect thanks
Okay so specifically you are talking about the difference in the options.value correct?
patent rune
ye
undone cedar
Okay yeah you do control that
patent rune
we control that?
undone cedar
So you created both of these PaymentLinks via the Dashboard. When you use Dropdown you create the Label name and then there is a "Add options" button
In the "Add options" you set the value
patent rune
yes
but how do I control the option.value not option.label
because my logic is based on the value of the option
undone cedar
You specify the value in that "Add options" modal
patent rune
There is no modal
which I think is automatically generated by you with an algorithm which is inconsistent between live and test modes.
does this make sense?
undone cedar
Ah I do see what you are saying now, sorry.
So you are seeing difference from inputting xxx + xxx
Where the value output is xxxANDxxx versus xxxAxxx
patent rune
is xxxandxxx and the other is xxxxxx
but would be nice to also control the VALUE of those dropdowns options
undone cedar
Yep I hear ya
I think the bug might have to do with the fact that you performed an update here
And we didn't correct the value
First you updated the livemode PaymentLink here: https://dashboard.stripe.com/logs/req_bV5lAwHnppD0cv
That set the xxxandxxx
Then when you updated the label it looks like we kept the same value here: https://dashboard.stripe.com/logs/req_7R2IW3g8vQSqB0
I can test that and confirm if that is the underlying bug
Either way I'll file this and we will get it fixed up
Yep okay doesn't look to be a live vs. test thing. Seems like a bug on updating the options where we don't then update the value
So yeah @patent rune you can work around this for now by creating new Payment Links each time instead of updating the custom_fields. That said, we will fix this so they update accordingly