xfechx_api | Stripe Developers | Page 1

flat warrenBOT Apr 25, 2025, 6:12 PM

#

👋 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/1365390030612332545

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

xfechx_api, 5 hours ago, 75 messages

#

abstract prism Apr 25, 2025, 6:13 PM

#

This is using PHP stripe library

opaque walrus Apr 25, 2025, 6:14 PM

#

The request you shared is a PaymentIntent confirmation request.

abstract prism Apr 25, 2025, 6:16 PM

#

yes

#

I am having issues with this exact line:

#

$payment_intent_object = \Stripe\PaymentIntent::retrieve($payment_intent_id

#

I am having a server error when reaching that line

opaque walrus Apr 25, 2025, 6:17 PM

#

Can you share the screenshot of the error being returned?

abstract prism Apr 25, 2025, 6:18 PM

#

sure

#

--- filling metadata now ------ API being used is: ------ Test Mode: ------ Stripe Source: ---event id: evt_3RGhstIVVhxSAz7H2JJfUxlN ---connected_account: ---origin: https://app.marlarecords.com ------ Origin: app.marlarecords.com ------ Destination: app.marlarecords.com ------ Internal Application ------ EVENT: CHARGE.SUCCEDED ------ payment intent not empty --- payment_intent = pi_3RGhstIVVhxSAz7H2ThCwLcU{"code":"internal_server_error","message":"<p>There has been a critical error on this website.</p><p><a href="https://wordpress.org/support/article/faq-troubleshooting/">Learn more about troubleshooting WordPress.</a></p>","data":{"status":500},"additional_errors":[]}

Marla Records

Asevatu Digital

App

#

this is the log

#

#

this is the code:

#

#

you can ignore $connected_account, it is empty, and I also try without it and I use it all over the code like that for many many years.

#

it is the array for the connected account (if exists, otherwise it is empty)

opaque walrus Apr 25, 2025, 6:24 PM

#

It looks like you're talking about two different things here:

Retrieving the PaymentIntent ID from the PaymentIntent object
Failed webhook deliveries

#

What's the specific issue you need assistance with?

abstract prism Apr 25, 2025, 6:28 PM

#

yes, I think the problem is on the line where the $charge->metadata = $payment_intent_object->metadata

#

because if I do var_dump($payment_intent_object I can see it is properly retrieved

opaque walrus Apr 25, 2025, 6:30 PM

#

Not sure that's the case. I'm looking at the event associated with the log line you shared and we successfully delivered the charge.succeeded event to multiple webhook endpoints with exception to one.

abstract prism Apr 25, 2025, 6:32 PM

#

for what I can see, because I wrote this many years ago, this is trying to update the charge description based on the payment intent description

opaque walrus Apr 25, 2025, 6:32 PM

#

Head over to the event's page in the Dashboard and scroll down to the "Webhook attempts" section.

abstract prism Apr 25, 2025, 6:33 PM

#

something related to admin, for sure. But it is giving me an error

#

sure, I also can see it has successfully been sent to other places, but those are irrelevant actually

#

those don't even read the webhook, they discard it

#

that is why it has successfully delivered

#

because it doesn't belong to them

#

I remember now:
for example in this case, the charge description is:
"description": "(2) Used Custom Vinyl - €20.00\n(1) Used Custom Vinyl - €5.00\n",

#

how to copy this description so that the payment intent also has it?

#

so that it appears on the dashborard under transactions, for example

#

or is that not the problem?

opaque walrus Apr 25, 2025, 6:36 PM

#

One sec.

abstract prism Apr 25, 2025, 6:38 PM

#

Ok, I can explain better

#

My app, takes application transfers whenever there is a successful charge

#

and lately it has been failing, and I am trying to figure out where exactly is the error

#

under my logs (that appear on stripe's webhook response) I can see the server error

#

but I cannot pinpoint where exactly is coming from

#

so perhaps if I could know what is the latest successful stripe call

opaque walrus Apr 25, 2025, 6:41 PM

#

The latest call was the confirmation of the PaymentIntent.

flat warrenBOT Apr 25, 2025, 6:45 PM

#

abstract prism Apr 25, 2025, 6:50 PM

#

I think it might be this line:

$customer =\Stripe\Customer::retrieve($charge->customer, $connected_account);

#

because I can print all the way till there

#

but I cannot var_dump($customer)

loud oar Apr 25, 2025, 6:51 PM

#

👋 stepping in as eze needs to step away

#

Did you log out the relevant variables used in that request?

abstract prism Apr 25, 2025, 6:54 PM

#

yes it's that

#

because commenting that line makes it work

#

but why is that making a server error?

loud oar Apr 25, 2025, 6:54 PM

#

No clue. There should be an error on your server if that Stripe request is failing

abstract prism Apr 25, 2025, 6:55 PM

#

if I wrap that on try catch, it should display yes?

loud oar Apr 25, 2025, 6:55 PM

#

Yeah it should

flat warrenBOT Apr 25, 2025, 6:57 PM

#

abstract prism Apr 25, 2025, 6:57 PM

#

it's very weird, it doesn't

#

with a wrap try catch, just gives me an internal server error

#

if I comment the line, webhook is delivered succesfully

#

$customer =\Stripe\Customer::retrieve($charge->customer, $connected_account);

loud oar Apr 25, 2025, 6:58 PM

#

Have you logged out $charge -> customer and $connected_account prior to that line?

#

To make sure those variables are properly initialized

#

Also what is the actual error on your server?

abstract prism Apr 25, 2025, 6:59 PM

#

yes, connected account is empty, and always works, that I am 100% sure is not the problem.

$charge - > customer is null, according to the stripe log

loud oar Apr 25, 2025, 6:59 PM

#

You keep saying it gives you "internal server error" but that is what you are seeing client-side, right?

#

Well $charge -> customer can't be null here to retrieve a Customer....

#

Can you hard code in a Customer ID

#

And test that way

abstract prism Apr 25, 2025, 7:02 PM

#

$customer = 'customerdemo123';

#

same error

loud oar Apr 25, 2025, 7:03 PM

#

Needs to be a cus_xxxx

abstract prism Apr 25, 2025, 7:04 PM

#

but wouldn't that message appear?

#

like an api error?

loud oar Apr 25, 2025, 7:05 PM

#

I mean it should

abstract prism Apr 25, 2025, 7:05 PM

#

and go through?

loud oar Apr 25, 2025, 7:05 PM

#

But I have no idea what your server is doing

#

I'm flying blind here

#

So suggesting making a real request that should work

#

And going from there

abstract prism Apr 25, 2025, 7:06 PM

#

if a customer is null

#

and you pass it thorugh that function

#

it should fire an api exception

loud oar Apr 25, 2025, 7:06 PM

#

Yes

abstract prism Apr 25, 2025, 7:06 PM

#

and the try catch should catch it

loud oar Apr 25, 2025, 7:06 PM

#

It should.

abstract prism Apr 25, 2025, 7:06 PM

#

and display the error, and webhook OK.

#

but server error

#

it is strange

#

can the server have a certain config?

loud oar Apr 25, 2025, 7:06 PM

#

Can you share your full Webhook handler code?

abstract prism Apr 25, 2025, 7:07 PM

#

that I am not aware of?

loud oar Apr 25, 2025, 7:07 PM

#

I have no idea how your server is set up, sorry.

abstract prism Apr 25, 2025, 7:08 PM

#

I know you don't but also I don't. I changed lately to a managed server, but I am unaware if things like this can be configured.

#

like to not enable try catch

#

or something.

#

                            try{
                            $customer = \Stripe\Customer::retrieve($charge_customer, $connected_account);
                            } catch (\Stripe\Exception\ApiErrorException $e) {
                                // Handle Stripe API errors
                                error_messages("Stripe API Error: " . $e->getMessage());
                            } catch(\Stripe\Error\InvalidRequest $e){
                                error_messages($e);
                            } catch (\Stripe\Error\Card $e){
                                error_messages($e);
                            } catch (Exception $e){
                                error_messages($e);
                            } ```

#

That try catch just like that has work through the years. (i.e error messages is a function that works)

#

*error_messages($e)

#

i don't want to use a real customer because then it will just make the webhook work, i want the webhook to work but to throw me an api exception error so that i can see the stripe error.

#

what about this:

$customer = \Stripe\Customer::retrieve($charge->customer, $connected_account);
} catch(Exception $e){
  $customer = null;
}```

would that work?

loud oar Apr 25, 2025, 7:18 PM

#

Sorry I really don't know what to suggest here. Overall there is something unique going on with your server. It feels to me like the Stripe request isn't the issue at all. I would recommend finding out if the request is even being made here at all -- do you see a failing request in your logs?

abstract prism Apr 25, 2025, 7:20 PM

#

in my logs in stripe dashboard?

loud oar Apr 25, 2025, 7:20 PM

#

Yep

abstract prism Apr 25, 2025, 7:21 PM

#

OK, so that makes it work.

#

This:

#

try{
$customer = \Stripe\Customer::retrieve($charge->customer, $connected_account);
} catch(Exception $e){
$customer = null;
}

#

that is all i needed

loud oar Apr 25, 2025, 7:21 PM

#

Are you sure your error_messages($e); is doing what you expect?

#

Maybe that error_messages() function is your issue?

abstract prism Apr 25, 2025, 7:21 PM

#

yes...

#

function error_messages($e){
  $body = $e->getJsonBody();
  $err  = $body['error'];

  echo "<h4>We are sorry</h4>";

  echo "<p><strong>There was a problem with your transaction";
  echo "<br>" . $err['message'] . "</strong></p>";

}```

#

not sure why suddenly this is happening tho

loud oar Apr 25, 2025, 7:23 PM

#

Perhaps something got cached in that case.

abstract prism Apr 25, 2025, 7:23 PM

#

$body = $e->getJsonBody();

#

this is the problem i am almost sure now, but it has been working for years, so I am confused

#

can the server dissallow getJsonBody() ?

#

like a secure flag?

#

i will ask server developers (it is a manged server now)

#

i used to run my own servers before, but too much work

loud oar Apr 25, 2025, 7:26 PM

#

Yeah that could be possible but would indeed be a question for your server managers.

abstract prism Apr 25, 2025, 7:26 PM

#

thanks for your help

#

a lot

#

cheers

loud oar Apr 25, 2025, 7:27 PM

#

Sure thing

abstract prism Apr 25, 2025, 7:31 PM

#

last question

#

if($event->type == 'charge.succeeded' && $event->data->object->amount_captured > 0) do you see any possible problem with this?

#

or am I safe to use it

#

because I only had this in this app, and I just did git pull to it and this line of code i did not have it elsewhere or on repository, so want to know if this COULD be a cause of a lot of problems

#

and better just leave it as charge.succeeded and omit the check for amount_captured

#

PHP Fatal error: Uncaught Error: Call to undefined method Stripe\\Exception\\UnexpectedValueException::getJsonBody() in /home/894259.cloudwaysapps.com/rtwnabpnwq/public_html/wp-content/themes/sigourney/includes/stripe/stripe-functions.php:1820

#

sorry, this is actual error on the server

loud oar Apr 25, 2025, 7:34 PM

#

lol okay yeah well that solves it then for why the exception wasn't getting raised.

abstract prism Apr 25, 2025, 7:35 PM

#

sorry I am not that great developer

loud oar Apr 25, 2025, 7:35 PM

#

No worries! Glad it got figured out.

abstract prism Apr 25, 2025, 7:35 PM

#

🙂

#

but what is it?

loud oar Apr 25, 2025, 7:35 PM

#

In terms of your first question, that should be fine.

#

What is the error?

abstract prism Apr 25, 2025, 7:35 PM

#

ok, i will leave it there

#

so will it ALWAYS be there no matter the event when charge.successfull? $event->data->object->amount_captured > 0

loud oar Apr 25, 2025, 7:36 PM

#

The error is that you are trying to call getJsonBody(); on an object that doesn't support that.

abstract prism Apr 25, 2025, 7:36 PM

#

uuuu

loud oar Apr 25, 2025, 7:36 PM

#

Yes a Charge will always have amount_captured: https://docs.stripe.com/api/charges/object#charge_object-amount_captured

abstract prism Apr 25, 2025, 7:36 PM

#

so I should really fix that because all my try catches in webhook have that

#

call to the same function

loud oar Apr 25, 2025, 7:37 PM

#

Yep that's what I was indicating before about there being an issue with your error_messages() function

abstract prism Apr 25, 2025, 7:37 PM

#

how should I modify it then?

#

here is error_messages($e):

  $body = $e->getJsonBody();
  $err  = $body['error'];

  echo "<h4>We are sorry</h4>";

  echo "<p><strong>There was a problem with your transaction";
  echo "<br>" . $err['message'] . "</strong></p>";

}```

loud oar Apr 25, 2025, 7:38 PM

#

Take a look at https://docs.stripe.com/error-handling

#

That has some suggestions

#

But overall you want to just record the error directly without calling any method on it

#

To figure this out you could log out the entire $e here and see which properties you care about

#

And then log them

abstract prism Apr 25, 2025, 7:39 PM

#

like this:
$e->getError()->message

#

only

#

not getJsonBody

loud oar Apr 25, 2025, 7:40 PM

#

That is how you can specifically handle a CardException

abstract prism Apr 25, 2025, 7:41 PM

#

simpler:

#

  echo "<h4>We are sorry</h4>";
  echo "<p><strong>There was a problem with your transaction";
  echo "<br>" . $e->getError()->message . "</strong></p>";
}```

#

will this cover me for now?

loud oar Apr 25, 2025, 7:42 PM

#

For CardErrors yes. But if you had an actual server-side error because of a bug in your code then I don't believe so.

#

You need to just handle the generic Exception in that case.

#

I'm not a PHP dev so I don't know exactly what this looks like.

#

You can trigger a general exception and just log the entire $e object to see what it will look like.

abstract prism Apr 25, 2025, 7:45 PM

#

so my try catches are mostly like this:

#

catch (\Stripe\Exception\ApiErrorException $e) {
                    // Handle Stripe API errors
                    error_messages("Stripe API Error: " . $e->getMessage());
                } catch(\Stripe\Error\InvalidRequest $e){
                    error_messages($e);
                } catch (\Stripe\Error\Card $e){
                    error_messages($e);
                } catch (Exception $e){
                    error_messages($e);
                } ```

#

I suppose a safer approach would be to then make error_messages($e) like:

  echo "<h4>We are sorry</h4>";
  echo "<p><strong>There was a problem with your transaction";
  echo "<br>" . $e . "</strong></p>";
}```

loud oar Apr 25, 2025, 7:46 PM

#

I mean yeah but you don't want to show the whole error object client-side as it will contain a lot of jargon and things that don't make any sense to a customer.

abstract prism Apr 25, 2025, 7:47 PM

#

hmm yes

loud oar Apr 25, 2025, 7:47 PM

#

Most times when folks catch a general Exception they just return their own error message

#

And you log the entire error object for yourself to analyze later

#

So you just echo back something like "Sorry, something went wrong."

flat warrenBOT Apr 25, 2025, 7:49 PM

#

abstract prism Apr 25, 2025, 7:49 PM

#

how can I check where $e comes from ? so that I can disseminate and choose not to use getJsonBody

#

like in this case

loud oar Apr 25, 2025, 7:50 PM

#

You can't check that

#

Your last catch is just a catch-all

#

So it shouldn't try to do anything to the exception

abstract prism Apr 25, 2025, 7:51 PM

#

so your recommended approach, would be to use a generic catch (Exception $e){ error_messages($e); }

#

and log the error to see on my end

#xfechx_api