Data truncated for column 'transaction_id' at row 1 - eprocessing

eproccesing authorize net emulator. That is the format that has always come back from them. I went back a year in another cart and see the same returns. The database has been truncating it all the while with no complaints.

Quote:

---

Originally Posted by mc12345678

Umm, another observation: ZC 1.5.1 and PHP 5.6???

---

Is there some issue with that combo?

it still makes no sense.

i have no idea what this eprocessing emulator is. and whether it is modifying the field.

if it has been truncated as you say all this time, how could you possibly issue a void or a refund? you do not have the complete id therefore authorize.net should error out when you send the truncated id.

this problem is solvable. try issuing a void with the full id v the truncated id. let's look at the responses.

finally if you login to your authorize.net dashboard you should be able to view your transactions. what is the value of the id there?

good luck.

Quote:

---

Originally Posted by IMMQ

Is there some issue with that combo?

---

Server requirements

Thing is, supposedly there would be one or more problems before getting to this checkout stage, so there may have already been some assumptions made that the store has been modified sufficiently to work with PHP 5.6...

Quote:

---

Originally Posted by IMMQ

eproccesing authorize net emulator.

---

Okay, so your AIM module isn't actually using the Authorize.net spec. It's connecting to the E-Processing gateway, which is emulating AIM, but with its own alterations, which don't totally adhere to the actual AIM specification.
Lovely.

So, ya, because of how your gateway works, you'll need to change your authorizenet_aim module to not force it to be a bigint(20) field. Something like varchar(32) as was suggested earlier would do.

(And for the sake of future posts, it would help to have known you were using e-processing instead of actual Authorize.net.)

Quote:

---

Originally Posted by DrByte

Okay, so your AIM module isn't actually using the Authorize.net spec. It's connecting to the E-Processing gateway, which is emulating AIM, but with its own alterations, which don't totally adhere to the actual AIM specification.
Lovely.

So, ya, because of how your gateway works, you'll need to change your authorizenet_aim module to not force it to be a bigint(20) field. Something like varchar(32) as was suggested earlier would do.

(And for the sake of future posts, it would help to have known you were using e-processing instead of actual Authorize.net.)

---

What is nuts is that this has worked fine for several years. Godaddy's choice to not put TLS 1.2 on their classic hosting servers means a lot of work still for me.

Sorry about that, too close to the problem and forgot that tidbit about eprocessing.

Thanks for all the help. For now storage is off until I can track down everything that touches that field as bigint. At least when I move over the big store I will know exactly what has to be modded.

Quote:

---

Originally Posted by IMMQ

For now storage is off until I can track down everything that touches that field as bigint.

---

Just that one section that carlwhat mentioned earlier.

Code:

---

  function tableCheckup() {
    global $db, $sniffer;
    $fieldOkay1 = (method_exists($sniffer, 'field_type')) ? $sniffer->field_type(TABLE_AUTHORIZENET, 'transaction_id', 'bigint(20)', true) : -1;
    if ($fieldOkay1 !== true) {
      $db->Execute("ALTER TABLE " . TABLE_AUTHORIZENET . " CHANGE transaction_id transaction_id bigint(20) default NULL");
    }
  }

---

change both "bigint(20)" to "varchar(32)"

Quote:

---

Originally Posted by DrByte

Just that one section that carlwhat mentioned earlier.

Code:

---

  function tableCheckup() {
    global $db, $sniffer;
    $fieldOkay1 = (method_exists($sniffer, 'field_type')) ? $sniffer->field_type(TABLE_AUTHORIZENET, 'transaction_id', 'bigint(20)', true) : -1;
    if ($fieldOkay1 !== true) {
      $db->Execute("ALTER TABLE " . TABLE_AUTHORIZENET . " CHANGE transaction_id transaction_id bigint(20) default NULL");
    }
  }

---

change both "bigint(20)" to "varchar(32)"

---

FYI: this change is built-in to v1.5.5d, released yesterday.