topic JSON issues in Integration and Testing

JSON issues

winternet — Tue, 18 Nov 2014 11:15:25 GMT

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

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

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

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.

Re: JSON issues

RaynorC1emen7 — Tue, 18 Nov 2014 12:14:53 GMT

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"
                    }
                ]
            }

Is anyone using JSON in production with authorize.net?

onemaster — Wed, 19 Nov 2014 16:48:35 GMT

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.

Re: Is anyone using JSON in production with authorize.net?

RichardH — Wed, 19 Nov 2014 17:07:12 GMT

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

Re: Is anyone using JSON in production with authorize.net?

winternet — Sun, 23 Nov 2014 09:39:45 GMT

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

Re: JSON issues

leehinde — Tue, 28 Jun 2016 19:02:34 GMT

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

Re: JSON issues

jasonjudge — Thu, 27 Apr 2017 09:55:10 GMT

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.

Re: JSON issues

uplf4eh9 — Wed, 10 Oct 2018 21:36:09 GMT

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.

Re: JSON issues

jasonjudge — Thu, 11 Oct 2018 08:22:31 GMT

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.

Re: JSON issues

billynoah — Tue, 25 Aug 2020 20:39:26 GMT

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!

Re: JSON issues

billynoah — Tue, 25 Aug 2020 20:57:50 GMT

This might help some of you who are trying to parse out the bom in php:

https://stackoverflow.com/questions/10290849/how-to-remove-multiple-utf-8-bom-sequences

Re: JSON issues

jasonjudge — Tue, 25 Aug 2020 22:18:42 GMT

If using PHP, the code snippet here may be useful:

https://github.com/academe/omnipay-authorizenetapi/blob/3f78bf58aff757850f4888bfff503704b5d69875/src/Message/AbstractRequest.php#L68

Re: JSON issues

nadav — Fri, 04 Aug 2023 11:21:12 GMT

If you can't parse the Authorize.net response and work with node.js use this, to remove the BOM from the response:

res.body = res.text.replace(/^\uFEFF/gm, "").replace(/^\u00BB\u00BF/gm, "");