(SIM) Akami server changes value in "test_amount" field; old server does not.

[davidhbrown]

Just read the email about switching to Akami, so I thought I'd give it a try. Something weird happened, though. We rely on the original form data posted back to us (relay response with merchant-defined fields) to display a correct invoice. When returning the data from our original form, the Akami server (https://secure2.authorize.net/gateway/transact.dll) is changing a merchant-defined field named "test_amount". It is returning the string "*" instead of the string "123" in the test_amount field I use for testing. The regular server (https://secure.authorize.net/gateway/transact.dll) is correctly returning the string "123". My expectation is that the Akami server should behave exactly the same as the current server. Until it does, I'm reluctant to switch. Any thoughts about what's going on here? It's been almost 5 years since I had to touch my implementation, but I just downloaded and skimmed the current implementation guide; these capabilities don't seem to have changed. Thanks for any thoughts, Dave

[RichardH]

Hello @davidhbrown

Are you able to duplicate this in the sandbox?  Can you provide your entire request with any sensitive information redacted?

Richard

[RaynorC1emen7]

are you sure, I thought authorize.net always * out if it think it is the CCV code. i.e. 3 digit

[davidhbrown]

Sorry for the slow reply; I had to refresh my memory on how to use the sandbox.Really appreciate your responses as I haven't heard anything yet from the support request I placed just before posting here.

@RaynorC1emen7, that's an interesting but scary thought. There are lots of reasons to use three-digit numbers. I really hope Authorize.Net isn't going to start erasing/redacting all of them arbitrarily.

I reverified that the new Akami server is changing the test_amount field in its reponse while the sandbox and the current live server return it unchanged.

@RichardH, in addition to the response fields I'l paste in a little bit lower, these are the fields I'm posting to authorize.net:

x_login = xxxxxxxxxxx
x_version = 3.1
x_amount = 123.00
x_fp_hash = ebaa5998fb4cceb109f8a35bae895a11
x_fp_sequence = 20150719160956098
x_fp_timestamp = 1437336596
x_type = AUTH_CAPTURE
x_show_form = PAYMENT_FORM
x_method = CC
x_logo_URL = https://www.example.com/logo.gif
x_recurring_billing = FALSE
x_description = AASV Ecom Test Form
x_relay_response = TRUE
x_relay_url = https://www.example.com/invoice.php
x_test_request = TRUE

...and here's the response from the Akami server (PHP reports with s:## indicating a string of length ##):

x_response_code = s:1:"1";
x_response_reason_code = s:1:"1";
x_response_reason_text = s:46:"(TESTMODE) This transaction has been approved.";
x_avs_code = s:1:"P";
x_auth_code = s:6:"000000";
x_trans_id = s:1:"0";
x_method = s:2:"CC";
x_card_type = s:4:"Visa";
x_account_number = s:8:"XXXX4448";
x_first_name = s:5:"David";
x_last_name = s:5:"Brown";
x_company = s:0:"";
x_address = s:11:"123 Some Street";
x_city = s:8:"Somecity";
x_state = s:2:"YZ";
x_zip = s:5:"12345";
x_country = s:3:"USA";
x_phone = s:0:"";
x_fax = s:0:"";
x_email = s:13:"someone@example.com";
x_invoice_num = s:0:"";
x_description = s:19:"AASV Ecom Test Form";
x_type = s:12:"auth_capture";
x_cust_id = s:0:"";
x_ship_to_first_name = s:5:"David";
x_ship_to_last_name = s:5:"Brown";
x_ship_to_company = s:0:"";
x_ship_to_address = s:11:"123 Some Street";
x_ship_to_city = s:8:"Somecity";
x_ship_to_state = s:2:"YZ";
x_ship_to_zip = s:5:"12345";
x_ship_to_country = s:3:"USA";
x_amount = s:6:"123.00";
x_tax = s:4:"0.00";
x_duty = s:4:"0.00";
x_freight = s:4:"0.00";
x_tax_exempt = s:5:"FALSE";
x_po_num = s:0:"";
x_MD5_Hash = s:32:"E36291193A14206FF970E4AACCB9F2D8";
x_cvv2_resp_code = s:0:"";
x_cavv_response = s:0:"";
x_test_request = s:4:"true";
log_formrequest_ID = s:2:"35";
test_amount = s:1:"*";
description = s:18:"another akami test";
Ecom_ShipTo_Postal_Name_Prefix = s:0:"";
Ecom_ShipTo_Postal_Name_First = s:5:"David";
Ecom_ShipTo_Postal_Name_Middle = s:0:"";
Ecom_ShipTo_Postal_Name_Last = s:5:"Brown";
Ecom_ShipTo_Postal_Name_Suffix = s:0:"";
Ecom_ShipTo_Postal_Street_Line1 = s:11:"123 Some Street";
Ecom_ShipTo_Postal_Street_Line2 = s:0:"";
Ecom_ShipTo_Postal_City = s:8:"Somecity";
Ecom_ShipTo_Postal_StateProv = s:2:"YZ";
Ecom_ShipTo_Postal_PostalCode = s:5:"12345";
Ecom_ShipTo_Postal_CountryCode = s:3:"USA";
Ecom_ShipTo_Telecom_Phone_Number = s:0:"";
Ecom_ShipTo_Telecom_Home_Number = s:17:"+1 (123) 456-7890";
Ecom_ShipTo_Telecom_Fax_Number = s:0:"";
Ecom_ShipTo_Telecom_Mobile_Number = s:0:"";
Ecom_ShipTo_Online_Email = s:13:"someone@example.com";
Ecom_ReceiptTo_Online_Email = s:0:"";
AASV_Order_Form = s:4:"Test";
x_ship_to_email = s:13:"someone@example.com";

Thanks again

[RichardH]

When you specify test request = true, the gateway will simply validate credentials and return success and never attempts a transaction.  If you are testing in the sandbox, testmode is not necessary as the sandbox does not connect to the card network.

Please note that when sending merchant defined fields, these are only passed through to the response and are not stored as part of the transaction.  If you pass data as a merchant defined field that appears to be passing sensitive information like a CCV such as "123", the gateway may change it to "***" to prevent transmission of potentially sensitive information. 

Richard

[davidhbrown]

I understand that for the sandbox, testmode is not necessary. However, I do need to use test mode to find out whether I'm going to get the same responses from the new Akami-hosted server. The fact that the Akami-hosted server is behaving differently is still the primary issue to me. What else might be different?

Can anyone tell me where this apparent behavior of changing sensitive-looking merchant-defined fields documented? I don't recall reading anything about that in the integration guide. This behavior seems particularly misguided given that the whole point of using SIM is that I don't ever want to have any sensitive on my server in the first place; I'm not asking for it and I'm not sending it to Authorize.Net. I suppose if I have to translate 0123456789 to abcdefghij or something stupid like that, I could, but knowing exactly what I had to avoid sending would be very helpful.

[davidhbrown]

I did find https://support.authorize.net/authkb/index?page=content&id=A135&actp=LIST which seems related, but doesn't mention any data-mangling process.