- This topic has 4 replies, 3 voices, and was last updated 6 years, 5 months ago by
.
-
Posts
-
Hello!
TL;DR: Remove usage of
urlparameter in Checkout’s configuration.I work for Stripe on the support engineering team and I wanted to reach out about the “referrer” issue you experienced recently.
I was digging into this for another user and stumbled upon your post which helped me reproduce the error on our end. I found the fix you deployed here and after digging for a bit I figured out that the issue was due to the
urlparameter and how we handle empty strings for that value.We’re working on a fix to make sure this does not happen again to other users as this was an unexpected change. The issue is that the
urlparameter is not documented on our end and not something we expected anyone to set in Checkout. This is an internal parameter (or at least it has been for a long time).I’m reaching out because I wanted to flag this and see whether it’s something you could fix for good in a future release in your plugin. I don’t think there’s any reason to be passing the
urlparameter in the code here. Would you be able to remove this parameter? If not, can you clarify why you need this today?I hope it’s okay to discuss this here, as I was not sure of a better way to reach out.
Best,
RemiHi Remi.
Thank you for reaching out. It’s ok to do it here if it’s comfortable for you.
As a developer myself, I think it would be much better to inform about API changes in some other way before making them? By some email to API users or something. But I do realize you personally is not the one who made this change without prior notice, so please don’t take it personally, just take it as a random rant from someone who had to reply to numerous users complaints regarding this issue. Also, I think it’s a good thing to call “url” parameter how it’s actually called, not “referrer” or something else. And also display corresponding error message. Hey, just another random rant, sorry 🙂
To answer your question why the “url” parameter is used, I’m pretty sure I found an example with it on Stripe website. I cannot find it again, I assume it was removed from documentation not long ago. But, as you might understand, I haven’t seen it in a dream and decided to put it in the code 😉
Since there is no reason to use it anymore, it will be removed from plugin code in the next release.
Thank you once again for your time and effort. And sorry in advance for any offence as none meant. Just ranting. Can a man rant once in a while? 😉
Hey,
Thanks a lot for the quick answer! And I totally hear your feedback. I like rants too 🙂
We made the change internally to a parameter that is supposed to be for internal use only. I don’t think this parameter has been documented in years either. So we did not expected anyone to be relying on its usage.
We take backwards-compatibility really seriously as you can see on our documentation page here and we’re really careful to ensure that we push changes that don’t affect existing integrations.
Unfortunately, it’s not always easy to know when some integrations rely on undocumented behavior as we have no way to track this easily, especially when it all happens client-side like in this case.
We’re really sorry that this broke some of your customers’ integration. It’s not the experience that we want to offer to our users.
In the future, you should feel free to contact us whenever something like this happens. We would have been able to find the issue immediately and pushed a fix that did not require you to make an urgent change on your end. I’d recommend trying #stripe on Freenode or our contact form here: https://support.stripe.com/email if you ever discover another regression like this one. Or you can always email me directly (remi at stripe dot com).
Cheers!
RemiHi Remi, Thanks for reaching out. This kind of issues can happen on rare occasions so its totally fine. We will update the plugin.
- You must be logged in to reply to this topic.