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

[IMMQ]

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.

[IMMQ]

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

Is there some issue with that combo?

[carlwhat]

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.

[mc12345678]

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

[DrByte]

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

[IMMQ]

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.

[DrByte]

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.

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

[DrByte]

Just that one section that carlwhat mentioned earlier.

  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.