#laurentiu_webhooks
wicked garnetBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1336779729319104522
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
trim haven
Hi, you pass the client reference id from your code: https://docs.stripe.com/payments/checkout/pricing-table#track-subscriptions . Are you setting the client-reference-id property on your end on all Pricing Tables?
marsh ridge
return (
<div className='flex flex-1 flex-col w-full'>
<stripe-pricing-table
pricing-table-id="prctbl_1O5CcnGesZuzMkZwMIJlj9hg"
publishable-key="pk_live_51Mc9giGesZuzMkZwRseaiuwIZ7z3CaFq0LcCfYihxjrwbuQxTmOra6P5xdw4Pnw1KqqaCWW7sulHOdCSMghVS7HW00ggpkXTj9"
client-reference-id={user.id}
customer-email={user.email}
>
</stripe-pricing-table>
<div className='mt-4 flex justify-center w-full'>
<Link className="px-4 py-2 bg-blue-600 text-white rounded-md hover:bg-blue-700 transition" href="/get-subscription">
Want a Subscription? Click Here!
</Link>
</div>
</div>
);
It's just a single pricing table I am using
lusty sand
Hi there 👋 jumping in as my teammate needs to step away.
Are you able to reproduce this behavior when using a static string for client-reference-id rather than a variable?
I'm looking to see if this behavior has already been flagged with our teams.
marsh ridge
hello! I can create a test for that, but I will not know if the customer ref ID is set as null in the pricing table js script. In PROD I cannot do that because I will lose the user ID information and I don't know for which user should I add the credits. Currently I do it via the webhook.
lusty sand
Events are still generated in testmode, you can still check those.
marsh ridge
the issue happens randomly, it might take a while to reproduce it in a test, plus there might be variations if the test is run through Playwright with headless browser. In the meantime, it can happen 2-3 times per day in PROD.
for me it's clear, since I return an error if the user id is null. I also log every time the user id is being retrieved, and it's never null. It's clearly a problem in the js script of the pricing table.
lusty sand
I saw the check that you described, and agree that would throw an error if either field is null, and why I think if the problem is within our script it should still be fast to reproduce with a static value.
marsh ridge
oh so you suspect that we can reproduce it right away with a static value?
lusty sand
If you have a hunch about the conditions that would cause it to not be picked up by our script, then yeah I'd suspect so.
marsh ridge
actually I don't think this could be the issue. I think the DOM sometimes is just not loaded yet, and the script tries to fetch it too early. The best way would be to do some polling on that attribute.
lusty sand
The value should be set before you reference it. Wouldn't your check throw an error if the value isn't available yet?
marsh ridge
yes absolutely, but I am just thinking since the pricing table script is creating an iframe, it could be that I have set it, but the value is not available right away for the script to fetch. Was there any similar complaint raised before? I can also see almost the same issue by searching the web:
lusty sand
No, I didn't find any mentions of this internally.
marsh ridge
also, I saw in the docs that you guys drop client ref ids that have unsupported chars or more than 200 chars. This is one example that failed: 29e9f2be-1f11-41fa-8a57-a1b3b6d4fd98. It looks valid, as the dashes are supported.
lusty sand
Yeah, that seems valid.
wicked garnetBOT
marsh ridge
do you guys have results for this post request which is inside the pricing table script?
{
key: "messageIframe",
value: function(e) {
var t = p(b);
if (!t) throw Error("stripe-pricing-table: target origin is null");
this.frame.contentWindow && this.frame.contentWindow.postMessage(e, t);
}
}
It's done inside the iframe that is being created. If the post fails, I think the client-ref-id is also lost.
pallid summit
👋 stepping in here as toby needs to step away
marsh ridge
Hey there! no probs
pallid summit
I don't know what specific network request that is so I can't say, sorry.
The only real way for us to be able to debug here would be to reproduce the issue.
Can you reproduce it?
marsh ridge
not consistently. It appears in PROD from time to time but I cannot see the pattern.
What I know is that if user id (which is the value I use for customer reference id) is null, I return an error and the pricing table is not even rendered.
The issue appears once per week at least. I am processing around 10-20 payments per day.
pallid summit
Okay well the next step then would be to collect a specific timestamp where this occurs and specific Checkout Session and then reach out to our Support team via https://support.stripe.com/contact/login so they can investigate and see if they can tell anything from our side. I can't really help you without a way to reproduce and there is no guarantee that there isn't something else going on on your end in terms of populating the client_reference_id here so I'd also ensure you log that out and track that to associate with each occurrence.