cancel
Showing results for 
Search instead for 
Did you mean: 

DPM - Additional information in the POST to transact.dll, processed by relay_URL

Hello Community,

 

I wanted do store some additional information in the POST to transact.dll, so that when I get the call to my PHP file from authorize.net, I could write that data to my database (MySQL).

 

For Example, I write the address in 3 fields (and that's how it is being entered in the form as well)

house_number

street

apt_or_unit

 

So before I submit the form, I populate the x_address field by just concatenating those 3 fields, but the above fields

are posted as well.

 

To my surprise these fields also appeared in my POST data for my relay URL PHP file. So I started to use them

to store that data.

 

So in my testing of course I type '123' a lot for the house number, and I have discovered, that when you use

the value 123, in any of those additional fields (none x_ fields), they get converted to a asterisk "*"

The strange thing is, it only does that with 123. It doesn't do it with 122 or 124 or a123 and many more values that

I have tried.

 

I know I can circumvent this weird thing by making an Ajax call to my server to save the extra data before I do the submit,

but this is a more convenient way, if it wasn't just for that weird 123 behavior.

 

The credit card itself is processed correctly, so everything in that area is working great!

 

FYI:

x_delim_data = TRUE

x_delim_char = ,

 

So, now I am really curious!.

Why would a value of 123 become an *? 

And are there other value's that get converted?

 

I am baffled.

Johannes

 

 

 

 

 

 

 

 

 

 

 

Trixor
Member
5 REPLIES 5

So before I submit the form, I populate the x_address field by just concatenating those 3 fields, but the above fields

are posted as well.

Fields that are not authorize.net are merchant defined fields. It will pass thru to the relay response.

 

Why would a value of 123 become an *?

I tested it on AIM and it is doing the same, need one of the MOD to response to this.

 

RaynorC1emen7
Expert

Thank you for responding, RaynorC1emen7!

 

Makes me feel better knowing I am not alone in this.

 

Since I was digging in the manual (again) I found the blurb that explains merchant defined fields, I had not read this part before, but that was what I was assuming when I noticed these fields were passed on. Maybe an document adjustment is needed to state that you can't use the value 123 for these fields. ;)

 

Hopefully a MOD can clarify this soon.

 

Merchant-defined fields
Merchants can also define special fields to further customize the information included with
a transaction. Merchant-defined fields are any fields that are not recognized by the
payment gateway as standard application programming interface (API) fields.
For example, the merchant might want to provide a field in which customers provide
specific shipping instructions and product color information. All you need to do is submit a
custom field name and any accompanying text with the transaction request string—for
example, shipping_instructions and product_color.

I am going to make an educated guess here that for your test card you are always entering in a made up card code value of 123.

 

There is actually nothing special about the number 123 in our system, but our system performs some basic validation to try and prevent developers from mistakenly sending secure data in the clear through merchant defined fields. Since these fields are included in email and a relay response, it is obviously not a place that you want to pass any sensitive information.

 

I can't provide a complete list of the filters we perform on merchant defined fields, but the one you are running into is fairly clear. It appears to our system that you are mirroring the x_card_code field into a merchant defined field and therefore it is being redacted. I performed a quick test myself just to verify the behavior. I changed my own test code to send a card code of 124, and 123 stopped being redacted from the merchant defined field. My own test code was also sending 123, it's just such an obvious choice to use for a 3 digit number with no rules on the format.

Thank you for your response Trevor, that was indeed the case! 

 

 

 

 


@Trevor wrote:

There is actually nothing special about the number 123 in our system, but our system performs some basic validation to try and prevent developers from mistakenly sending secure data in the clear through merchant defined fields. Since these fields are included in email and a relay response, it is obviously not a place that you want to pass any sensitive information.


Hi. I was just bitten by this. I tried entering a credit card number of "4" in development and found that one of our merchant-supplied fields was being changed to "*". The merchant-defined field just contained a SHA1 alphanumeric hash so I'm not sure what it thought it was matching.

 

Please consider changing this behavior. I understand the goal and it's admirable, but it seems like this is fragile, leading to random and difficult to reproduce errors.

 

Retrict it to the test environment, or flag the account, or at least provide additional info in the response that indicates the request was modified and why.