#oranges13-php
dawn ferry
analog zephyr
Hello do you have a request ID (req_123) from a time that you got this error?
woven jolt
Hi there! No -- because of the API key error it doesn't resolve in our dashboard
analog zephyr
And can you send me the snippet of your PHP code where you make the call that gets this error?
Gotcha, that makes sense
woven jolt
Yes, I can give you the before -- what I attempted to change it to that is still failing. One moment, gotta copy / paste in discord with formatting 🙂
analog zephyr
Also are you working directly with one of our stripe-php libraries or are you working with Laravel cashier?
Stripe doesn't develop Cashier so for questions with that library you have to ask Laravel
woven jolt
We are using stripe\stripe-php:^9.0 in our composer.josn
analog zephyr
Gotcha. And when you say intermittent errors, that means that some of these calls from your v9 code are working but some get this key error?
woven jolt
OK initial approach was the old way:
<?php
\Stripe\Stripe::setApiKey(config('services.stripe.secret')); // Laravel configuration of secret
$request = ['id' => 'cus_xxxxx', 'expand' => ['default_source']];
return Customer::retrieve($request);
This would fail with the API Key error. so I modified it to this:
return Customer::retrieve($request, ['api_key' => config('services.stripe.secret')]);
I have verified that the configuration value is being read -- and I even hard-coded the value into the file itself, e.g.:
return Customer::retrieve($request, ['api_key' => 'sk_blahblah']);
Then I was like okay, this is the old way, so I modified to use the client / service model instead
$stripe = new StripeClient(config('services.stripe.secret'));
// same varibles as above exist for request
$stripe->customers->retrieve($request);
This resulted in the API Key failure still...
Also tried
$stripe->customers->retrieve($request, ['api_key' => '...']);
Same issue.
I've also tried adding the api_key to the $request array.. but that results in a different error about it being in the wrong spot
But yes, we are using stripe calls across our application. Since upgrading, only some fail like this. Most work..
It seems to be always instance where we have an additional param array like an expand or an update with parameters. But not always.
analog zephyr
So to be clear, will the same line of code always succeed or work, or does the exact same code seem to work or fail intermittently? Also like will it always consistently work or not for the same run of the same code?
woven jolt
In the same pathway it ALWAYS fails, even if the api key is hard coded into the file. But then if I use it from a different path, it may work. The call to Customer::retrieve is actually inside a function -- but that function is used in at least 2 places.
So I sidestepped that function and used the stripe client directly in the file
still got the API key error
analog zephyr
That "even when hard coded" part is a really interesting wrinkle here. I am trying to think of what might thrown that off.
woven jolt
I have messaged for this issue before, someone suggested maybe the 3rd parameter array is being ignored; but if I add it to the request array, I get a different errror. Hold on I can provoke it and get you the text
analog zephyr
And the per request config will succeed in the fail in the same files as the stripe client failures basically?
woven jolt
yeah, we have one file that does the same request with the function ends up at the same Customer::retrieve location and succeeds
analog zephyr
As a quick note it looks like that error is from Stripe's servers, not the PHP library. It seemed like that before but that does confirm that at least some of the stripe-php code is running here
woven jolt
I can try again, I just have to wait for some requests to hit this code.
Hold on 👍
OK, so I have modified my file with the api key directly included in the call, not using the config() method:
$subscriptionCustomer = $this->stripe->customers->retrieve($subscription->getCustomerId(), ['expand' => ['default_source']], ['api_key' => 'sk...']);
Going to wait for some requests
ok hold on. Now I'm getting a different error
that's progress!!
analog zephyr
Oh nice what error is that?
woven jolt
I see a response, but attempting to access the response->id is failing. debugging!
ok. I got two passes and then a failure with no changes
now it's just straight failing again
This is what I don't understand. I received 4 responses, but then a failure, then a response, then another failure. The code was the same with the key hard coded int the request
winter kiln
👋 I'm hopping in since @analog zephyr has to head out soon - give me a few minutes to catch up
winter kiln
When you say you're using Laravel you're not using Laravel Cashier right, you're using our stripe-php library directly? And which version specifically of our library are you using?
winter kiln
Can you show me your most recent code and the exact errors you're getting?
woven jolt
This is the most recent code: #1032386745230172180 message
winter kiln
oranges13-php
woven jolt
You did not provide an API key. You need to provide your API key in the Authorization header, using Bearer auth (e.g. 'Authorization: Bearer YOUR_SECRET_KEY'). See https://stripe.com/docs/api#authentication for details, or we can help at https://support.stripe.com/.
winter kiln
and this wasn't an issue you had before upgrading right?
woven jolt
It technically wasn't an issue AFTER upgrading. We made some other changes, specifically changing to Guzzle from Curl for other stuff, but Stripe doesn't use Guzzle
winter kiln
Ah, so it's specifically your move to guzzle that started showing these issues - and with your move to guzzle did you need to change any of your code?
woven jolt
For stripe, no.
Curl was causing some issues with internal communications, so we switched to Guzzle for that, but it did not affect Stripe. Or so we thought.
winter kiln
Is it easy for you to see what happens when you revert back to the older version but stay with guzzle? I'm trying to narrow down what specifically is the issue here