cancel
Showing results for 
Search instead for 
Did you mean: 

JSON issues

Great to see JSON being implemented! There are some issues though.

 

1.

With the JSON response a BOM UTF-8 character is included. BOM on UTF-8 makes no sense. This should not be there as it will confuse most JSON parses. You will have lots of feedback from people who can't understand why they cannot parse the JSON - and they won't know why because it's usually not apparent that the BOM is the issue, the parser just says "sorry, can't do it" with no further meaningful error message. References: http://en.wikipedia.org/wiki/Byte_order_mark and http://stackoverflow.com/questions/14532149/bom-in-server-response-screws-up-json-parsing

 

As a temporary fix for PHP using this service right now the following code will remove the BOM character and should be run before you run it through json_decode(): $response = preg_replace('/\xEF\xBB\xBF/', '', $response);

 

2.

How do you specify multiple settings in the request? Logically it should be defined like this:

 

{
    "createTransactionRequest": {
        "merchantAuthentication": {
            "name": "xxxxxx",
            "transactionKey": "xxxxxx"
        },
        "refId": "123456",
        "transactionRequest": {
            "transactionType": "authCaptureTransaction",
            "amount": "5",
            "payment": {
                "creditCard": {
                    "cardNumber": "5424000000000015",
                    "expirationDate": "1220",
                    "cardCode": "999"
                }
            },
            "lineItems": {
                "lineItem": {
                    "itemId": "1",
                    "name": "vase",
                    "description": "Cannes logo",
                    "quantity": "18",
                    "unitPrice": "45.00"
                }
            },
            "tax": {
                "amount": "4.26",
                "name": "level2 tax name",
                "description": "level2 tax"
            },
            "duty": {
                "amount": "8.55",
                "name": "duty name",
                "description": "duty description"
            },
            "shipping": {
                "amount": "4.26",
                "name": "level2 tax name",
                "description": "level2 tax"
            },
            "poNumber": "456654",
            "customer": {
                "id": "99999456654"
            },
            "billTo": {
                "firstName": "Ellen",
                "lastName": "Johnson",
                "company": "Souveniropolis",
                "address": "14 Main Street",
                "city": "Pecan Springs",
                "state": "TX",
                "zip": "44628",
                "country": "USA"
            },
            "shipTo": {
                "firstName": "China",
                "lastName": "Bayles",
                "company": "Thyme for Tea",
                "address": "12 Main Street",
                "city": "Pecan Springs",
                "state": "TX",
                "zip": "44628",
                "country": "USA"
            },
            "customerIP": "192.168.1.1",
            "transactionSettings": [
				{
					"setting": {
						"settingName": "duplicateWindow",
						"settingValue": "240"
					}
				},
				{
					"setting": {
						"settingName": "merchantEmail",
						"settingValue": "my@email.com"
					}
				}
            ]
        }
    }
}

 

 But this will produce the following truly misleading error message:

 

{
    "messages": {
        "resultCode": "Error",
        "message": [
            {
                "code": "E00003",
                "text": "The element 'transactionRequest' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'transactionSettings' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'userFields' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'."
            }
        ]
    }
}

The error message makes the programmer focus on element transactionSettings within transactionRequest - instead of the real issue deeper down.

As soon as you remove one of the settings from the array the error disappears.

 

The same issue applies to "lineItems".

 

3.

Also, the correct way to set a single setting is wrapping it in an array like this:

"transactionSettings": [
	{
		"setting": {
			"settingName": "merchantEmail",
			"settingValue": "allan@sharehim.org"
		}
	}
]

 The way the online API reference does it without the array is not the proper way to do it since you end up with different types of structures depending on whether you have one or multiple settings - and that's not smart. Both ways seem to work for a single setting though.

winternet
Contributor
1 ACCEPTED SOLUTION

Accepted Solutions

Okay, @onemaster was almost correct. The correct way to set the settings are...

 

for multiple settings:

"transactionSettings": {
	"setting": [
		{
			"settingName": "duplicateWindow",
			"settingValue": "240"
		},
		{
			"settingName": "merchantEmail",
			"settingValue": "my@email.com"
		}
	]
}

 

for a single setting:

"transactionSettings": {
	"setting": [
		{
			"settingName": "merchantEmail",
			"settingValue": "my@email.com"
		}
	]
}

 

It has some unnecessary structure though but maybe it is required since it seems like the server actually converts it to XML before processing... And as long as it is properly documented and it works - no need to bother...

View solution in original post

12 REPLIES 12

If you look at the userFields, I worder if the setting is the array.

            "transactionSettings": {
                "setting": {
                    "settingName": "testRequest",
                    "settingValue": "false"
                }
            },
            "userFields": {
                "userField": [
                    {
                        "name": "MerchantDefinedFieldName1",
                        "value": "MerchantDefinedFieldValue1"
                    },
                    {
                        "name": "favorite_color",
                        "value": "blue"
                    }
                ]
            }

 

RaynorC1emen7
Expert

How is the JSON Beta going?  I see in this post there are issues.  Is anyone using the JSON in production?  I'm interested to know how it is going.  I'm researching this gateway for ease of implementation and already use JSON in my custom built shopping cart. 

onemaster
Member

Hello @onemaster 

 

Glad to see we have more interest in our JSON message format.  We only released this a few days ago, so it will likely take a some more time to properly bake before using in production.

 

Richard

Okay, @onemaster was almost correct. The correct way to set the settings are...

 

for multiple settings:

"transactionSettings": {
	"setting": [
		{
			"settingName": "duplicateWindow",
			"settingValue": "240"
		},
		{
			"settingName": "merchantEmail",
			"settingValue": "my@email.com"
		}
	]
}

 

for a single setting:

"transactionSettings": {
	"setting": [
		{
			"settingName": "merchantEmail",
			"settingValue": "my@email.com"
		}
	]
}

 

It has some unnecessary structure though but maybe it is required since it seems like the server actually converts it to XML before processing... And as long as it is properly documented and it works - no need to bother...

I just wanted to +1 on the BOM in front of the JSON repsonse being an issue. I just spent half a day trying to figure out why the parser was failing...

 

leehinde
Contributor
Contributor

Oh wow, me too. It's 2017 now and I had been scratching my head over why I could not parse the JSON response for most of an afternoon. Why is it there? It's not like it's a standalone file with no context - we get the JSON over a HTTP connection and *know* what encoding is used through that. The BOM needs to go IMO.

BOMs are illegal in JSON. I thought they were just garbage artifacts returned by a careless bug in the API until I found this thread.

uplf4eh9
Member

Some links to the standards and background comments here:

 

https://stackoverflow.com/questions/4990095/json-specification-and-usage-of-bom-charset-encoding

 

Come on Authorize.Net, make that leap and remove the BOM. We don't even use it - we just strip it out and throw it away. It serves no purpose, gets in the way, and is not a legal part of JSON anyway.

How many developers need to complain about the time they wasted before you remove the BOM?

 

Or at the very least mention it in the docs!