HSBC Secure Epayments to Global Iris (Realex)

[feemish]

That sounds like a good improvement.

How long is the cut-off for authorisations callback on v10.0.4?

[gcamley]

Depends on the life of the session file. The session file will be removed whenever any script is called after the cart expiry period. By default the expiry is 3 hours so usually authorisations may be accepted up to 3 hours after an order is placed. The session will also expire if the same PC/Browser is used to place another order within the expiry period.

The expiry period can be changed in 'Web | Configure Expiry Periods'.

[feemish]

thanks for the info.

Still no repeat of the callback error.

However I am receiving emails from customers saying that when their order fails they receive the message;

'Error 508 Invalid data in MERCHANT_ID field. Contact the seller'

This is a rather worrying message for the customer as it seems like my site does not have the correct merchant ID. Obviously it does as 95% of errors complete without problem. I only know about this error because customers contact me about it. I have the debugging output for these orders. So far I have received no reply regarding these errors from Realex.

[feemish]

Realex have got back to me regarding the
'Invalid Merchant ID error'

They say firstly, this is a message they have never know be shown to a customer, as it should only usually only be shown to shop owners logging on to the Realex Control Panel.

Secondly, they say none of the orders where this error message was returned are on their system at all ! So they cannot look them up... They say they are not in ; 'failed' 'batched' or 'pending' there is no sign of them at all. That is incredibly weird becuse the debugging script output clearly shows their page being called with these orders.

[feemish]

If anyone is interested I can supply the debugging output for these orders.

[gcamley]

If anyone is interested I can supply the debugging output for these orders.

Please send the details to SellerDeck support quoting your ticket reference associated with this problem and they will be forwarded to me.

[feemish]

thanks.

The woman from realex said she has now enabled debug 'logging' of my account as well..

[feemish]

Another Customer contacted me after being displayed the same confidence sapping message when their order failed...

Error 508
Invalid data in MERCHANT_ID field.

According to Realex, the actual error was that the customer entered an incorrect passcode at the 3D secure stage.. They dont know at the moment why my customers are being shown this message I know if I was shopping online and was shown this message it would severely damage my confidence in the merchant ! So I'm not happy about it.

Any other HSBC - Realex / Actinic users out there should be aware that their customers might be being shown this disturbing message as well if their orders fail.

[feemish]

Hi Gordon,
After religiously double checking every single order for the last month it has finally happened again!
I have the debgugging log for an order that completed on Realex, but I didnt receive the callback, so the order stayed in pending. I can send you the log to check.

It seems you may have been on the right track, because the payment appears in my Realex Control panel out of order. The time for the order on Actinic is 11.37 but the payment time on Realex is 18.12. The order was in payment pending in Actinic, but payment was complete in realex.

[gcamley]

Pre SD2013 SellerDeck cannot handle call backs that late.

RealEx (and all other PSPs we use apart from NoChex and PayPal) should be using synchronous call backs i.e. the authorisation call back should happen before the receipt is requested.

It would seem that this is no longer the case with RealEx unless RealEx tried unsuccessfully to reach the server and queued the callback to be tried again at a later time.

The change in SellerDeck 2013 to handle this was quite substantial so cannot be ported back to earlier versions.

What would be useful to know is whether RealEx did try to send the call back before the receipt or if this delayed call back was the first attempt. If not the first attempt then we need to know why the first attempt failed The answer to these questions can only be found from RealEx.

We have seen problems with DNS configuration causing call backs for other PSPs to intermittently fail. Sorry I don't know the details of the DNS mis configuration or the solution only that the call back reported a DNS time out and that increasing the DNS time out on the server making the request (the PSP's server) to an abnormally large value overcame the problem. Such a change is not a solution, it only serves to demonstrate that the DNS is faulty.

If you could send the logs to SellerDeck support (quoting the same ticket number) I will take a look to see if it tells us anything more.

[feemish]

Hi Gordon,

I have received this reply from Realex regarding this issue;

I have reviewed the logs of this transaction.

The timestamp is generated by the Actinic at the time the customer hits your checkout page (I’ve just confirmed this myself). I’m not sure if it would be possible to confirm this with the customer but it’s possible they went to your checkout page at 11:37 but then came back later and finished the checkout process. Timestamps within 24 hours will be accepted.

For example I can see that we redirected the customer at 18:12 to Llyods’ 3DSecure server to enter in their card’s password. So it appears this is when they completed the transaction.

Furthermore at 18:12 -

24.01.2013 18:12:55 arka $response_uri = http://www.myshopname.co.uk/cgi-bin/os000001.pl
24.01.2013 18:12:55 arka ..end POST request, UserAgent returned the status: 200 OK

This indicates that we successful posted the transaction response to your Response URL. So I’m not sure why it didn’t update properly in the Actinic backend, it’s possibly because the lapse of time, would it be possible to confirm this with Actinic themselves?

Best,

Seán

Gordon, would it be possible for you to communicate directly with Sean from Realex regarding this. It seems a bit silly for me to be passing messages between you.

[Mike Hughes]

Hi Mark,

I've been following this thread but not able to add much.

I’m not sure if it would be possible to confirm this with the customer but it’s possible they went to your checkout page at 11:37 but then came back later and finished the checkout process.

This suggestion from Realex sounds like it's worth following up. The customer could well shine some light on exactly what happened.

Mike

[feemish]

Hi Mike, thanks for the interest !
Yes I have emailed the customer to ask if anything odd happened, and to ask if he actually paid 8 hours later ! No reply yet.
Although I find that hard to believe... that customers click 'checkout' fill in all their details and then wait 8 hours to pay... and from the amount of times this is happening.. it woould mean that that is a common practice ! which I doubt.. and even if it was a common practice, it should still work shouldnt it?

[Mike Hughes]

It does seem odd and isn't anything I've noticed although I have seen a few orders where payment comes in 20-30 minutes later.

It could easily happen though. Customer places the order, goes to get his wallet with the credit card and then get's distracted by something else before being dragged out by his wife.

I'm not sure I see why Gordon is bringing discussion of synchronous call backs into this. Is there any evidence that the customer was returned to the receipt page before the callback was made? I'd assume if the payment was completed 8 hours later that the customer would be sent back to the receipt page at that time, not any earlier.

Mike

ps. And yes. It should still work, although obviously Actinic needs the session files to still be around so it knows what's happening. What do you currently have the expiry time set to?

[feemish]

If it happened once I could accept thats the reason but its happening too often for that to be the cause in my opinion..

Re expiry: Do you mean how Expiry period for Shopping carts?
I have 'delete shopping carts after : 3 hours' which is the default. How long should this be set for then do you think?