SD payments not returning;

[Air-Tech]

I've got an on-going intermittent issue with SD payment appearing to hang when the "Continue" (confirm / pay) button is clicked in SD payments, resulting in phone calls & emails querying if orders have been received, with the occasional cancellation. The "Continue" button leaves the customer on a blank page, which they eventually presume has hung & close out / navigate away from, no customer confirmation is issued & no copy confirmation is received. We have tried a gallon of test orders & have seen what we think is the issue intermittently, it seems that the page hasn't hung as such, but is just taking an exceptionally long time to load. As a wild guess it's maybe occurring in 5>10% of orders where SD payments are used.

I don't think it's a user error issue as it' happening to regular customers who are familiar with the process & it's happening across multiple browsers with multiple card types.

I've had a look through the forum & see a couple of similar threads, but these finalise in advising to go the support route - we have done this, but it's been passed onto second line support for some time without any resolution to date. Our DB is regularly compacted, network tests are good, hosting is with an SD familiar provider, the only common issue I see from the script error log is "Internal Errors = Receipt requested for different order".

Is anyone familiar with the order of events after "continue" has been clicked, so that I might be able to figure what's causing this issue?

Thanks

[Mike Hughes]

The first thing Sellerdeck does in the scripts before displaying the receipt page is to check the order number in the payment info matches that in the session file

#
    # Make sure the order number is the same as in the session file
    #
    if ($sOrderNumber ne $::g_PaymentInfo{'ORDERNUMBER'})
        {
        ACTINIC::ReportError("Receipt requested for different order", ACTINIC::GetPath());
        return;
        }

which seems to be where it is failing.

Why it's doing this I don't know. The best suggestion I can give is to write (or get someone to write - Sellerdeck?) a modified orderscript so that the error message includes the two bits of data it's comparing. Hopefully that should allow you to pinpoint the problem.

[NormanRouxel]

Edit OrderScript.pl (back it up first) and change:

ACTINIC::ReportError("Receipt requested for different order", ACTINIC::GetPath());

To:

ACTINIC::ReportError("Receipt requested for different order:" . $sOrderNumber . '/' . $::g_PaymentInfo{'ORDERNUMBER'}, ACTINIC::GetPath());

[Mike Hughes]

It's so helpful having Norman on this forum.

[Air-Tech]

Thanks guys - code added & I'll check the next order that fits the pattern.

I didn't make this very clear, but these orders are successful / paid - would a miss-match in the order numbers like this provide a complete / successful order?

[Mike Hughes]

I didn't make this very clear, but these orders are successful / paid - would a miss-match in the order numbers like this provide a complete / successful order?

Yes. This is at the point where the customer is returning to your website after paying. The scripts are checking the payment information is valid before displaying the receipt page and any download links etc and it's at this point that the process is failing and the error you're seeing is being generated.

[Mike Hughes]

By the way. Your error file is pretty big (around 40 MB). It's probably worth deleting it and letting sellerdeck create a new one.

[Air-Tech]

By the way. Your error file is pretty big (around 40 MB). It's probably worth deleting it and letting sellerdeck create a new one.

I see what you mean - I had a fair bit more hair when that started..... time to give it a trim!

[oginet]

My thanks also to Norman, this fixed problem as described above, just reported today by customer using Sellerdeck 2016

[Mike Hughes]

The script change from Norman isn't designed to fix the problem. What it does is provide some more information in the error log when it happens to help diagnose what the problem might be.

It's good that you've made the change though. It seems to be something that only happens very occasionally so the more info we can get on what's causing it the more likely it is that it can be identified and fixed.