Refund Issue - Sandbox vs Production Environment

[danielb93]

I'm finding a discrepancy between the JSON response from the Refund endpoint in the sandbox environment compared to the production environment. This difference (additional keys in the 'Refund' object) is causing an error when the SDK attempts to instantiate the AbstractResponse class:

Eway\Rapid\Model\Response\RefundResponse

I've tracked the down the line causing the error:

/eway/eway-rapid-php/src/Rapid/Client.php:565

/** @var AbstractResponse $response */
$response = new $class($data);

In the production environment this line produces an S9995 error, as show below:

Eway\Rapid\Model\Response\RefundResponse Object
(
    [fillable:protected] => Array
        (
            [0] => AuthorisationCode
            [1] => Customer
            [2] => Errors
            [3] => Refund
            [4] => ResponseCode
            [5] => ResponseMessage
            [6] => TransactionID
            [7] => TransactionStatus
            [8] => Verification
        )

    [errors:protected] => Array
        (
        )

    [attributes:protected] => Array
        (
            [Errors] => S9995
        )

)

However this works flawlessly while in the sandbox environment.

[incarnate]

Hi danielb93,

Thanks for the detailed report and debugging. It does looks like there are some extra fields being returned by the API in production at the moment, I've asked our dev team to look into this.

I'll update this issue once we've got an update.

[danielb93]

Hey incarnate,

Appreciate the rapid response. I'm concerned how such an easy to pickup issue made it into a release, surely unit tests would have picked this up? This issue has resulted in a mountain of errors from the live environment at my company and has been a headache to track down because the eWay sandbox seems to be completely behind the production environment. In the future, is there anywhere I can monitor to see SDK/Rapid API changes so I can preemptively adjust on my end?

After further investigation I narrowed it down to the following variables missing from the Eway\Rapid\Model\RefundDetails model:

'AuthorisationID',
'STAN',
'ReceiptId',
'Receipt',
'ResponseCode',
'ResponseText',
'MerchantID',
'TerminalID',
'PosReference',
'SettlementDate',
'ReceiptGUID',
'MposDeviceId'

Adding the above to the accepted attributes array resolves the issue:

<?php

namespace Eway\Rapid\Model;

/**
 * Class Refund.
 *
 * @property int    $TransactionID      The ID of either the transaction to refund, or the authorisation to cancel.
 * @property int    $TotalAmount        The total amount to refund the card holder in this transaction in cents. e.g. 1000 = $10.00
 * @property string $InvoiceNumber      The merchant's invoice number
 * @property string $InvoiceDescription merchants invoice description
 * @property string $InvoiceReference   The merchant's invoice reference
 * @property string $CurrencyCode       The merchant's currency (e.g. AUD)
 */
class RefundDetails extends AbstractModel
{
    protected $fillable = [
        'TransactionID',
        'TotalAmount',
        'InvoiceNumber',
        'InvoiceDescription',
        'InvoiceReference',
        'CurrencyCode',
        'AuthorisationID',
        'STAN',
        'ReceiptId',
        'Receipt',
        'ResponseCode',
        'ResponseText',
        'MerchantID',
        'TerminalID',
        'PosReference',
        'SettlementDate',
        'ReceiptGUID',
        'MposDeviceId'
    ];
}

For now i've written a composer patch to inject the additional attributes in order to get my production environment working again.

[incarnate]

Sorry about the headaches! We have implemented testing around field changes, but it looks like this update got pushed out before those went live. In the future new fields will be implemented with versioning to prevent issues like this - the doco for that will be up soon, followed by SDK updates.

That said, I think the main issue here is that the PHP SDK fails fatally if an unexpected field is encountered. This should be more flexible as we move to adding new fields (in versions!). For now I've removed the Exception thrown when an unknown field is encountered, so it will be ignored by the SDK. The change is released as v1.1.2.

Thanks for your work on this and PR #4 - I'm still confirming if the new fields will remain as is.