Moneris / eSelect Plus Payment Module

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

cloelke:

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?

coredesign:

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

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...

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?

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."

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

aasaria:

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 [email protected] that would be much appreciated, thank-you. :D

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! :ohmy: 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.

:D 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/download/feb05/PHP/eSELECTplus_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/download/feb05/PHP/eSELECTplus_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

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.

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.

Hi All,

Does anyone have a working copy of this mod that they could post or send me? I've been looking a for Moneris solution for a while.

Feel free to PM me.

Cheers,

Colin

Just a question,

Can't their oscommerce module work with zen-cart?

Hello,

I am wondering if out of this useful discussion an official working version of the this payment module was developed, and if so, could it be posted in the official downloads area?

Obviously several people have working versions. I'm new around here, but surly it can't be hard to get something like this posted on the zen-cart.com site?

Thank you very much to the contributors here who have shared their knowledge. With that it should be at least possible to recreate a working version of the module, if it comes to that!

--Julian

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."
WOW!

that helped clear one hurdle at least.

for those that are still getting "header already sent" messages,

modify the mpgClasses.php file at the very beginning to take away ANY blank spaces that maybe hiding hidden characters:

<?php

#################### mpgGlobals ###########################################


class mpgGlobals{

becomes:

<?php
################### mpgGlobals #############

the bottom part is the same:

}//end class


?>

becomes:

}//end class
?>

^^ NO spaces at all after "?>"

Now .... to actually get it talking to the Moneris servers. :yuck:

Anyone have a working module? I'm not getting the customer info to the Moneris servers.

x2 , need a working module

bump..anyone....

b18cya:

bump..anyone....
b18cya, the module does work as it stands.

Two things to watch for:

1 - the spacing in the provided 2.02 version of mpgClasses.php (above)

2 - that the default setting of this is production, not testing servers (check readme.txt in the zip files).

If its something else, then I'll try to help here. Just give a few details.

Oh alright, so once you do that, the module works perfectly fine with no issues?

I got this working for a client in very similar fashion to what is described above and it looks pretty reliable.