Error handling and validation

[AidasK]

I have read all the wiki, but error handling and validation is not covered.
Currently I am using this snippet. I don't like it, because it contains two different catch blocks and a check after all of it. The biggest problem is that I can't tell to the user what is wrong with a form if $response->isSuccessful() is not successful, because $response->getErrors() is always empty.

$method = new \Checkout\Models\Payments\TokenSource($request->get('token'));
$payment = new \Checkout\Models\Payments\Payment($method, $order->product_currency);
$payment->amount = bcmul($order->product_price, 100);
$payment->reference = $order->id;
try {
     /** @var Payment $response */
     $response = $checkoutApi->payments()->request($payment);
} catch (CheckoutHttpException $e) {
            throw ValidationException::withMessages(['payment_method' => $e->getErrors() ?: [$e->getMessage()]]);
} catch (CheckoutModelException $e) {
            throw ValidationException::withMessages(['payment_method' => [$e->getMessage()]]);
}
if (!$response->isSuccessful()) {
            throw ValidationException::withMessages(['payment_method' => $response->getErrors() ?: ['Invalid card data']]);
}
$order->status = Order::STATUS_APPROVED;

[aquila-freitas-cko]

Hi @AidasK ,
In fact, there are some features there are not yet fully documented. I understand your doubt with $response->getErrors(); Let me explain why it is always empty in your case.

Your form is not successful if you get an exception, at that stage the $response object is useless. You will be able to do $e->getErrors() if $e is instance of CheckoutHttpException.

If you disable the http exceptions on the config file, $response->getErrors() will return you the errors without throwing an exception.

Your code would look like this:

$method = new \Checkout\Models\Payments\TokenSource($request->get('token'));
$payment = new \Checkout\Models\Payments\Payment($method, $order->product_currency);
$payment->amount = bcmul($order->product_price, 100);
$payment->reference = $order->id;

/** @var Payment $response **/
$response = $checkoutApi->payments()->request($payment);

if(!$response->isSuccessful()) {
    throw ValidationException::withMessages(['payment_method' => [$response->getErrors()]]);
    /**Obs: you won't have message here.**/
}

$order->status = Order::STATUS_APPROVED;

[AidasK]

Thanks for your brief response. It does look cleaner.
My code now looks like this:

        $checkoutApi = new CheckoutApi(
            config('services.checkout.secret_key'),
            config('app.debug'),
            config('services.checkout.public_key'),
            false
        );
        HttpHandler::$throw = false;
        
        $method = new \Checkout\Models\Payments\TokenSource($request->get('token'));
        $payment = new \Checkout\Models\Payments\Payment($method, $order->product_currency);
        $payment->amount = bcmul($order->product_price, 100);
        $payment->reference = \Brand::getId() . '-' . $order->id;
        /** @var Payment $response */
        $response = $checkoutApi->payments()->request($payment);
        if (!$response->isSuccessful()) {
            throw ValidationException::withMessages([
                'payment_method' => $response->getErrors() ?: ['Invalid card data (' . $response->getCode() . ')']
            ]);
        }
        $order->status = Order::STATUS_APPROVED;

It is a pity, that I can not provide config as an array to CheckoutApi class, so it does not look clean

[aquila-freitas-cko]

These are not configurations you want to update all the times, as this will affect how your code is executed with the SDK. You should either edit the default one or specify a custom as fourth parameter.

$checkoutApi = new CheckoutApi(
            config('services.checkout.secret_key'),
            config('app.debug'),
            config('services.checkout.public_key'),
            '/project/var/checkout.ini'
        );

[AidasK]

I just don't want any physical files to configure this. It is not a good practice

[aquila-freitas-cko]

I understand that if you have an automated deployment it is indeed impracticable to have hard files, but passing a long array is also impracticable if someone has to explicitly type the config. I am afraid HttpHandler::$throw = false; will be the only way to set individually this.

[AidasK]

It's not about long arrays. It should be a developers choice how to save this config. Maybe I would like to use json files instead of .ini?

…

On Fri, Apr 26, 2019 at 2:17 PM Áquila Freitas ***@***.***> wrote: I understand that if you have an automated deployment it is indeed impracticable to have files, but passing a long array is also impracticable if someone has to explicitly type the config. I am afraid HttpHandler::$throw = false; will be the only way to set individually this. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP54JAI7L25CCZH4X5MSJTPSLQENANCNFSM4HFPILCA> .

[david-fiaty-cko]

@AidasK, could you please confirm if you are expecting something like this:

$myConfig = array('your config here'); 
$checkoutApi = new CheckoutApi(
            config('services.checkout.secret_key'),
            config('app.debug'),
            config('services.checkout.public_key'),
            $myConfig
        );

If not, please provide a code snippet illustrating your expectations.

[AidasK]

Yes, that would be much better :)

[david-fiaty-cko]

@AidasK, the SDK has been updated to accept a config array in the constructor as described above. We're closing this issue for now, please reopen if needed.

[AidasK]

Thanks!