X-Cart forums

[BurtonTech]

Hello,


I've seen this on a number of hardware platforms hosting the X-Cart 5.x software and X-Payments using a credit card authorization with a delayed capture. It appears the X-Cart provides duplicate transaction ID's (they are called a transaction ID on the X-Cart while in X-Payments, they are called order or reference ID's, depending on what page you are viewing). Unfortunately when the duplicate transaction ID is submitted during an authorization, you cannot go back and capture the funds from the X-Cart, instead you have to locate the order in X-Payments and capture it there. When you do attempt to capture the order from the X-Cart, you get the following error:

Error:Operation failed. X-Payments error (code: 849) Payment "xxx-some-number-xxx" has not open (non-captured) pre-authorized transactions

Originally I observed this bug intermittently in a self-hosted X-Payments 1.0.6 installation and when support said it was because X-Payments was so old, we upgraded to the hosted version and the problem continued. It appears this issue has existed for sometime but it appears to not have been fixed (see https://forum.x-cart.com/showthread.php?p=350542).

I suspect this is a general bug / design flaw where they use the transaction ID as a unique identifier but do nothing to make sure the transaction ID cannot be entered into the database table more than once or code to handle duplicate entries.

Has anyone else run into this problem or more importantly, have they found a solution to the problem?

Thanks!

[qualiteam]

I think that the cause of this problem cannot be found without doing some on-server debugging.
Did you report it to our support staff by creating a ticket at https://secure.x-cart.com/?

[BurtonTech]

Originally Posted by qualiteam

I think that the cause of this problem cannot be found without doing some on-server debugging.
Did you report it to our support staff by creating a ticket at https://secure.x-cart.com/?

I've had support look at it a few times and previously they technician suggested we go through the expense and hassle of switching to the hosted version of X-Payments, which we did. The problem is continuing though.

I currently have a new ticket open with support. Unfortunately they performed a single test transaction and considering this problem is intermittent, they found nothing. I'm going to try and urge them to at least look at the logs or review the code that allows for duplicate transaction ID's to be submitted to X-Payments. Hopefully with additional prodding support will investigate the source of the problem.

[qualiteam]

If the support staff (with the access to the server) can't find the cause easily, I doubt we can do it by discussing the problem in these forums
This is definitely something that should be debugged right on the server.

[BurtonTech]

Originally Posted by qualiteam

If the support staff (with the access to the server) can't find the cause easily, I doubt we can do it by discussing the problem in these forums
This is definitely something that should be debugged right on the server.

I'm still hopeful that support will pull through and attempt a solution, but I'd rather see if *anyone* out there might be experiencing similar XC5 frustrations and want to devise a workaround. I've seen this bug occurring for almost two years now, so I'm sure many other people have encountered it.

It appears the source of this problem is that duplicate xpcBackReference values for a particular transaction_id can be inserted into the xc_payment_transaction_data table. Unfortunately the xpcBackReference entries have different xpc_txnid values which prevents the X-Cart from properly communicating with X-Payments. When the X-Cart tries to locate the xpc_txnid, it can only grab a single value and it's not always the correct one:

    /**
     * Find trannsaction by X-Payments back refernece to X-Cart
     *
     * @param string $xpcBackReference X-Payment connector Backend reference
     *
     * @return \XLite\Model\Payment\Transaction
     */
    protected function searchTransactionByBackReference($xpcBackReference)
    {
        $transactionData = \XLite\Core\Database::getRepo('XLite\Model\Payment\TransactionData')
            ->findOneBy(array('value' => $xpcBackReference, 'name' => 'xpcBackReference'));

        return $transactionData
            ? $transactionData->getTransaction()
            : null;
    }

It would be great if that function could be improved to handle issues where duplicate xpcBackReference values exist with conflicting xpc_txnid values, but I suspect the bug allowing for duplicate values is being generated by the XPaymentsClient. It appears the X-Payments server does nothing to manage these ID's and prevent duplication either.

The impact of this bug could easily be tested by simply creating duplicate xpcBackReference's with different xpc_txnid's for the same transaction_id in the relevant X-Cart and X-Payment tables. Then hopefully the maintenance team could write code to overcome these scenarios while they figure out how to prevent the duplication values in the first place.

I'd like to avoid spending more time reverse engineering this code, so if there are any experts out there or documentation that could help ID the problem, that would be extremely helpful.

Thanks.

[qualiteam]

I've forwarded your message to the X-Payments dev team. Thanks!

[BurtonTech]

It appears this bug is caused by having the iframe option turned on for the X-Payments connector. The temporary workaround for this issue is to disable iframes while the X-Payment Connector development team is working on a fix.

Unfortunately my client feels their customers leaving the site to pay isn't a good shopping experience, so hopefully the fix is present soon. In the meantime, if you're experiencing this problem, the iframe workaround may be just what you need!