#marko-stripejsv2
1 messages · Page 1 of 1 (latest)
looks like you changed your code to start passing a "beta header" for https://stripe.com/docs/payments/finalize-payments-on-the-server beta, but you don't actually have access to that beta yet.
But we're not adding this ourselves, I checked already.
We just require the bundle like this:
$.getScript('https://js.stripe.com/v2/').done(() => {
Stripe = window.Stripe;
Stripe.setPublishableKey(stripeKey);
resolve(Stripe);
})
and when that returns Stripe we just invoke the following:
Stripe.card.createToken({
number,
cvc,
exp_month,
exp_year,
}
That's it.
what's the value of stripeKey when you log it?
also, a link to your page with the problem would help a lot
We got this error from one of our users after he wasn't able to add a CC.
I used a test API key and test CC details from the docs for the image you see above.
can you replicate the problem right now?
Yes, this image is from a few minutes ago.
Sec, my bad, let me provide more details (taking backend into account).
I assumed this call returns this error, but when I put a breakpoint it seems that something else happens on our backend and that's what's causing the error.
createToken returns 200, so this part is good.
ok cool, then you probably changed your backend to pass that header I mentioned in that case.
We haven't, that's for sure, it suddenly started happening and we haven't changed this part in years.
Could it be caused by the fact we are using the JAR version stripe-java-21.1.0-beta.1.jar?
But why did it start happening all of a sudden, hm.
yep must be
any particular reason you're using the beta? AFAIK we generate a beta version of the Java library for users wanting to use beta features, but since you get that error your account doesn't actually have access , so I'm not sure where you found that or were told to use it
I wish I knew. Given that we are still using JS V2 API on the frontend, which JAR version do you suggest I switch to?
Just FYI, here's a relevant part of the stack trace and the code that causes it.
why don't you know exactly?
like your code didn't just start using a beta JAR, you must have changed something like edited your pom.xml file or gradle configuration or so on
so I would just revert it back to whatever you were using before that change
I can't really suggest the right JAR version since I don't know what you were using before, and if I just tell you to use the latest version, it might not be compatible with your existing code
This is how it's declared in our build.gradle:
compile group: 'com.stripe', name: 'stripe-java', version:'latest.release'
yeah that's really really dangerous
"I don't know" - I meant the person who worked on this is not around.
you should only allow it to update to the latest major version X (from X.y.y) since we release breaking changes in the major versions.
Yeah, makes perfect sense.
cool cool, then yeah, you need to try to fix that and revert back to what you used
if you post some ID from your account I can look at your logs and try to tell you what you used in the past
like a customer ID cus_xxxx or ch_xxx charge or anything
Sure, thanks a lot, let me find out.
That will be helpful because:
we've been using latest.release since 2017
yep but we only recently started releasing a separate beta branch of the library
I flagged this internally too
Yeah, I think we've been using the latest version all along, so specifying some version 20 would probably be fine.
I'm waiting for the customer ID and I'll pass it on ASA I get it.
it's definitely suboptimal that you somehow pull in the beta branch as a dependency , I do think your pom is too broad, but still, we might have ways to set up our publishing to avoid the footgun
Right, declaring a beta release to be the "latest release" is kinda unexpected.
I got one customer ID cus_MCL0lhEwP7UH1T
you were using 20.120.0 recently
Thank you very much. Very competent and reasonable support 🙂
I'll provide feedback.