Moneris eSELECTplus Hosted Payment Page?

[cvhainb]

I am having a client use this module and sometimes the order is duplicated. I am checking with Moneris about this.

[el56]

I would really appreciate a bit of help on this. I decided to try and go ahead and install it on 1.5.4 since it's not a working site yet. When I go to install the sql patch I am getting "WARNING: An Error occurred, please refresh the page and try again.".

This is the current Sql patch:

DROP TABLE IF EXISTS `moneris_orderids`;
CREATE TABLE IF NOT EXISTS `moneris_orderids` (
`moneris_orderid` varchar(99) NOT NULL,
`orders_id` int(11) NOT NULL,
`trans_name` varchar(20) NOT NULL,
`bank_approval_code` varchar(8) NOT NULL,
`bank_transaction_id` int(18) NOT NULL,
`response_code` varchar(3) NOT NULL,
`iso_code` int(2) NOT NULL,
`message` varchar(100) NOT NULL,
`cardholder` varchar(40) NOT NULL,
`response_variables` blob NOT NULL,
`bank_transaction_id` int(10) NOT NULL,
`f4l4` varchar(11) NOT NULL,
PRIMARY KEY (`orders_id`,`moneris_orderid`),
KEY `idx_moneris_orderids_orders_id` (`orders_id`)
);

Is there something that doesn't work with 1.5.4 here?

Thanks in advance for any help!

The above command, found in the file Moneris.sql includes two requests to create the field 'bank_transaction_id'. That duplicate field creation will make this command fail under Tools->Install SQL patches without useful output. Running it manually under the mysql command line reveals the error in the redundant field creation.
I took out the shorter of the two (one is defined as 18-digit, the other as 10-digit) and am hoping it works.

[margecc]

I ended up paying someone to make some changes to this module so that it would work correctly with 1.5.4 There were several problems with it.

[lat9]

Just a note for anyone looking to upgrade their Moneris-HPP installation to use a more recent version of MySQL. The file Moneris.sql, besides the double-declaration mentioned above:

DROP TABLE IF EXISTS `moneris_orderids`;
CREATE TABLE IF NOT EXISTS `moneris_orderids` (
  `moneris_orderid` varchar(99) NOT NULL,
  `orders_id` int(11) NOT NULL,
  `trans_name` varchar(20) NOT NULL,
  `bank_approval_code` varchar(8) NOT NUL  L,
  `bank_transaction_id` int(18) NOT NULL,
  `response_code` varchar(3) NOT NULL,
  `iso_code` int(2) NOT NULL,
  `message` varchar(100) NOT NULL,
  `cardholder` varchar(40) NOT NULL,
  `response_variables` blob NOT NULL,
  `bank_transaction_id` int(10) NOT NULL,
  `f4l4` varchar(11) NOT NULL,
  PRIMARY KEY (`orders_id`,`moneris_orderid`),
  KEY `idx_moneris_orderids_orders_id` (`orders_id`)
);

also defines the bank_transaction_id as an integer value. Unfortunately, MySQL integer values can range from +/- 2147483647, but those values come back as 18-character values.

When you try to stuff those values into that integer-defined field for those more recent versions of MySQL, you might receive error logs similar to

PHP Fatal error:  1264:Out of range value for column 'bank_transaction_id' at row 1

You'll also notice (viewing the moneris_orderids table) that all the bank_transaction_id values are 2147483647!

The correction is to define that field as either char(18) or, for some expansion, varchar(20). You can safely make the field format change in phpMyAdmin, since that value is recorded but never used.