Moneris / eSelect Plus Payment Module

[sdwood]

I'm reviving this thread about Moneris / eSelect from the archives, as there appeared to be no resolution at the time it was locked.

as of Feb 12 they will not longer support the method used.

Cloelke implies that there are changes necessary to the eselect_api module. Can anyone confirm this? If so what is the nature of the changes?

I am working with Moneris Integration Support to sort out the eslect_api contribution. Hoping to hear back from them early next week and will post their response as soon as its available.

Coredesign, have they responded to your request?

Are there people out there who are presently running ZenCart with processing with through Moneris? Reading this thread one gets the impression that payments would have ceased functioning as of Feb 12. If that's indeed true I find it hard to believe there's been no further mention of it here. Does the silence mean all is well, or that nobody actually uses the eselect_api module in production?

Lastly, does anyone have any comments about the Moneris / ZenCart relationship? I'm curious to know how supportive people feel they are when it comes to integration issues.

Regards,
Steven

--
Steven Wood
Ikoro Digital Inc

[moxy]

I'm about to set up a simple shopping cart and would like to use zencart. But my client is committed to processing via Moneris.. Has there been any resolution to this - or more simply, is it possible and/or relatively easy to use zencart with Moneris?


Thanks in advance...

[fantasygoat]

I'm also finally at the point where I am ready to set up the credit card processing for my zencart store, and am looking for a Moneris payment module. Any updates on this? Would the osCommerce one work?

[coredesign]

This was the "fix" provided by Moneris Integration Specialist, Christian Abdel-Malek:

"Please ensure that you do not have any leading space in your mpgClasses.php file as that has been known to cause several errors in sending transactions not only in zencart but also in previous oscommerce transactions that I have dealt with in the past."

[aasaria]

Did people get this solved? I have a working e-select Moneris module working. Let me know if you need it.

[duckydoodles.com]

Did people get this solved? I have a working e-select Moneris module working. Let me know if you need it.

Hello aasaria! I would love it if you could send me the working e-select Moneris module. What version of Zen Cart are you using? If you could please send it to stencells AT hotmail DOT com that would be much appreciated, thank-you.

[jstushnoff]

I had got my eSelect Payment Module working too, but I can't remember what I did (it was a while ago). It did have something to do with downloading the latest MPG classes from Moneris though.
BIG PROBLEM THOUGH! I just found out yesterday. After using it for a few months, we've just discovered that orders over $1000 process normally on Zen Carts end (no errors), but the transaction is not recorded with Moneris! Anybody know what might be the problem? We've lost a few thousand dollars worth of merchandise that was shipped before we noticed the problem!
I will post the fixes if/when I get them all figured out, but if anyone has figured this out yet, or has any ideas, please let me know ASAP.

[jstushnoff]

OK, it seems like I've got the problem fixed.
I believe I originally started with the eSelect Plus/Moneris Payment Module for Zen v1.2.4, written by NetworkDad.
Instead of using the supplied mpgClasses.php file, I downloaded the latest "PHP API" from
https://www3.moneris.com/connect/en/process/apis/PHP/
Make sure you open the file and change " MONERIS_HOST" to be 'www3.moneris.com' when you want to take the store into the 'Production' environment (instead of just testing)
For more information go to CHAPTER 11 on this PDF:
https://www3.moneris.com/connect/en/...lus_PHP_IG.pdf

I then made modifications to eselect_api.php according to stealthman from this post http://www.zen-cart.com/forum/showthread.php?t=15013
Make sure you get the "if ($response_code == "null")" condition included in the script (3/4 of the way down the last bunch of Code) or you, nor the customer, will have no indication if the cc processing fails! (I missed putting that in, as I think the rest of the code was already included in the module I downloaded)
Here's the biggie for orders over $1000. On line 241, the code should be changed from

	  amount => number_format($order->info['total'], 2),

to

	  amount => number_format($order->info['total'], 2, '.', ''),

note the added , '.', ''),
This makes sure there is NO thousands separator instead of the default ' separator.
Moneris (CANADA) requires a number with only a decimal place separator of . and no other separators!
For more information go to APPENDIX A on this PDF:
https://www3.moneris.com/connect/en/...lus_PHP_IG.pdf

BTW, I really don't know PHP, so if anyone can check and correct anything please leave a post here.
Also, does anyone know how to submit this module with updates for possible inclusion on the community, or does anyone know where you can get the original anymore?
If anyone else has made any other improvements please leave a post for those of us still using this module. Thanks

[aasaria]

Nice find on the thousands separator! I would have missed that.

Please note that in stealman's he calculates the next order ID by incrementing the last order ID. In the code as far as I can see, this isn't used anywhere except stored in a DB. This is probably because he doesn't show another part of code which allows invoices to display transaction information.

Please note that incrementing the last order ID is, technically, not a correct way to find the current order ID. You see, the way Zen works, it only gives an Order ID to an order AFTER it has been processed (with payment). Before that, the customer could cancel their order. So the problem is that when you do a transaction, you have no simple way to associate it with an order until after the transaction has taken place (there are other functions in the payment modules that help do that).

The problem could occur that two customers are paying at the same time and simply incrementing the last order ID will give both of the transactions the same "next order id" value. This would become a very noticable problem if you have many orders per hour.

You can ignore this advice if you don't care about showing tx info in your invoices. The code will work fine.

[aasaria]

Also, with regards to getting a "NULL" response from Moneris.

This happens in two cases:
1. The moneris server was unreachable (the server is down, your internet connection is down, etc.)
2. The Moneris server took too long to reply

In the second case, it gets tricky becauase it is *possible* that the Moneris server got your transaction, processed it properly, and charged the card but just didn't have enough time to reply and say "yo, it's all good". In this case, with the code as is, your store will give a customer an error and make them enter their credit card info again.

Now the problem here is that the code as is generates a new order id ($oid) every time so the second time the customer will enter their credit card info, it will process as a second trasaction and double bill the customer. Making the oid persist will cause you other problems (e.g. the customer can change stuff in their cart after the first NULL response and the orders are no longer the same).

Solution? Well for both cases 1 & 2 our store has decided it is best to tell the customer, hey, your transaction went fine. Process the order and use a secondary, human way to process the card. In this case, our human operator will use the SAME moneris order id so that if the original order *did* go through, the moneris server will say "transaction already done" and avoid the double bill.

basically my advice is that if you get a null, don't just tell the customer to enter data again. because if the server *is* down (case 1) this just means frustration for the customer. and if the tx did timeout, it is possible it still went through.