#pkdiscgolf-refund-error

1 messages · Page 1 of 1 (latest)

cold flame
#

Hello! Our API synchronously return the API response so if you create a Refund you get a Refund object back already

cursive estuary
#

$stripe = new \Stripe\StripeClient(
'KEY'
);

error_reporting(0);

try {

$stripe->refunds->create([
    'charge' => $charge_id,
]);


echo $player_name . " ";
echo "refunded successfully";

}catch(Exception $e) {
echo "ERROR";
}

#

How do i catch that object and store it in a variable

cold flame
#

$refund = $stripe->refunds->create([...]);

#

now you have the whole refund!

cursive estuary
#

so after changing that line

echo $refund.status()

should print my response?

cold flame
#

it's PHP you're writing so no

#

echo $refund->status; instead

cursive estuary
#

ok, good point, thanks for catching that

#

If the refund fails, what should i expect the response to look like

cold flame
#

Either you get an error/exception if there's an error in the API call like a bad parameter. Otherwise refunds fail asynchronously

cursive estuary
#

If the exception throws and i get an error

is there an $e.getCode or something like that for me to see the error code

cold flame
#

this covers basic error handling in details in all languages

cursive estuary
#

It doesnt mention anything about refunds

cold flame
#

but it mentions in details how to handle any error our API returns

#

it works the same for creating a Refund, a Topup, a Payout or anything

#

1/ catch errors via try/catch
2/ display the error if any

cursive estuary
#

I do not know how i will test for a failed refund to trigger this code. Do you think it will work?

try {

$refund = $stripe->refunds->create([
    'charge' => $charge_id,
]);

catch(Exception $e) {
echo "ERROR<br>";
$refund_status = $refund->status . " Failure Reason: " . $refund->failure_reason;
}

cold flame
#

no that won't work at all unfortunately

#

there's some foundational misunderstanding of PHP

#

like $refund does not exist in the catch here

#

the catch means "we could never create your refund at all"

#

it's different from "we refunded your card but the bank said the card is closed". That one happens asynchronously days later

cursive estuary
#

ah. yea that is a good point about the refund not existing in that catch block, i should have noticed that

The docs say there is a refund object "The Refund object’s status transitions to failed and includes these attributes:"

So, if a refund fails - it will actually still be in the try block. So i should be able to get the failure_reason like this?

try {

$refund = $stripe->refunds->create([
    'charge' => $charge_id,
]);

$refund_status = $refund->status;

if($refund_status=='failed'){
    $refund_status = $refund_status  . " Failure Reason: " .  $refund->failure_reason;
}

}catch(Exception $e) {
echo "ERROR<br>";
}

cold flame
#

not at all either

#

1/ Create a Refund today, Refund succeeds, all good
2/ Later, on Friday, get a charge.refund.failed event on your wehook handler. It's days later

cursive estuary
#

ah. So until i inplement a webhook - I will not be able to tell if the refund worked or not?

#

(without logging into my stripe web console)

cold flame
#

correct

cursive estuary
#

Ok, that makes sense because it is asynchronous, but I got confused because the docs say that the refund object is changed so i thought that meant i had access to the change

#

So i have another issue, of the same sort.

<?php

//kppro live
\Stripe\Stripe::setApiKey('KEY');

//create a customer in stripe
$customer = \Stripe\Customer::create(array(
"email" => $email_address,
"source" => $stripe_token
)
);

$api_error='no error'; //just in case

//for idempotency
error_reporting(0);
$idempotency = preg_replace('/[^a-z\d]/im', '', $_POST['idempotency']);

try {
$charge = \Stripe\Charge::create(
["amount" => $entry_cost,
"currency" => "usd",
"description" => $description,
"customer" => $customer->id ], [
"idempotency_key" => $idempotency]);
}catch(Exception $e) {
$api_error = $e->getMessage();
// $api_error_code = $e->code();
$api_error_code = 'error';

//replace quotes in error message to prevent error inserting into database
$string_safe_api_error = preg_replace("/<!--.*?-->/", "", $api_error);

echo "Error: " . $string_safe_api_error . "<br>";
echo "Error: " . $api_error_code . "<br>";

}

//redirect to success
header('Location: success.php?tid='.$charge->id.'&description='.$description);

?>

This line:
// $api_error_code = $e->code();

Isnt going to work. Is there a a way i can get the error code, so that i can handle it with a nice message to send to my user, instead of the one that shows up in $e->getMessage()

cold flame
#

really same answer as earlier

#

the doc I gave you for error handling covers all of this in details in every languages with clear examples

#

Also you're using a legacy API, the Charge API, that has been deprecated for 3+ years, instead of using PaymentIntents

cursive estuary
#

This seems (to me) like a different issue. I am able to get $e->getMessage() for an error message that i could display to my user

BUT it would be nice if i could just catch the error #, and handle it the way i want

Are you saying, that i am also trying to catch something asynchronous? While in the meantime, $e->getMessage() is NOT asyncrhonous?

cold flame
#

I don't understand the question unfortunately

#

Charge creation is synchronous, so I'm not sure what's wrong but you just shared your entire PHP code

cursive estuary
#

I want to catch an error code, instead of $e->getMessage()

is there something like $e->getErrorCode ? so that i can get a specific # error and then handle it with my own message

cold flame
#

yes, that is how you get the message associated with a specific error that happens synchronously in our API

cursive estuary
#

The message is "ugly". I was hoping to get an error code instead. Is that possible?

cold flame
#

I'm worried you didn't really read the doc 😅

#

there are many types of errors and handling them is subtle

cursive estuary
#

The doc doesnt even indicate that $e->getMessage exists

#

How would one know that the error object has a method getMessage() that is available

cold flame
#

yes because you are not supposed to use this

#

the doc show clearly what to use instead which is why I keep linking you to it

#
  try {
    $stripe->paymentIntents->create($args);
    error_log("No error.");
  } catch(\Stripe\Exception\CardException $e) {
    error_log("A payment error occurred: {$e->getError()->message}");
  } catch (\Stripe\Exception\InvalidRequestException $e) {
    error_log("An invalid request occuurred.");
  } catch (Exception $e) {
    error_log("Another problem occurred, maybe unrelated to Stripe.");
  }```
#

see the getError() see how it does ->message and everything else?

#
  // Use Stripe's library to make requests...
} catch(\Stripe\Exception\CardException $e) {
  // Since it's a decline, \Stripe\Exception\CardException will be caught
  echo 'Status is:' . $e->getHttpStatus() . '\n';
  echo 'Type is:' . $e->getError()->type . '\n';
  echo 'Code is:' . $e->getError()->code . '\n';
  // param is '' in this case
  echo 'Param is:' . $e->getError()->param . '\n';
  echo 'Message is:' . $e->getError()->message . '\n';
} catch ...```
cursive estuary
#

Ok. I didnt know i wasnt supposed to do that.

How long will it be until my code stops working due to deprecated legacy charge api?

cold flame
#

it won't stop working, it's just a bad idea for you to start with something deeply deprecated. Just start with our official integration path and docs, especially as you are bit lost

cursive estuary
#

I am actually not started. I wrote this app 2 years ago, and am trying to fix a few quirks that i have been dealing with since launch

cold flame
#

gotcha

cursive estuary
#

If i wanted to "upgrade" to paymentintents, is there a guide to retrofit my charge api code? I definetely would like to avoid starting from scratch as a i have built in aton of features these last 2 years

stuck geyser
#

depends on what you mean by "retrofit" - we have a lot of migrations guides for charges -> payment intents (see https://stripe.com/docs/payments/payment-intents/migration as a starting point), but it's fundamentally a very different flow and won't be as simple as just copy pasting blocks of code to replace what you have

cursive estuary
#

got it. Well i do not want to rock the boat too hard on this because i am doing 50-250 transactions a day and it sounds like my code is going to continue working

The Error exception classes - will they work the same/be the same classes for payment intent (in example) and charge api (what i am using)

#

?

stuck geyser
#

Yes, they should be the same

cursive estuary
#

Ok. Thanks for your help. I am going to try and implement this multi-branch try catch block tomorrow