Reply
Contributor
Posts: 11
Registered: ‎08-10-2012
Accepted Solution

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.


Accepted Solutions
Solution
Accepted by topic author winternet
‎08-21-2015 01:58 AM
Contributor
Posts: 11
Registered: ‎08-10-2012

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

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


All Replies
Expert
Posts: 4,525
Registered: ‎03-08-2010

Re: JSON issues

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

 

Member
Posts: 1
Registered: ‎11-19-2014

Is anyone using JSON in production with authorize.net?

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. 

Posts: 2,584
Topics: 56
Kudos: 213
Blog Posts: 67
Registered: ‎12-05-2011

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

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


Build modern websites and mobile applications without increasing PCI burden using Authorize.Net Accept


Still using SIM, DPM or AIM? Please check our upgrade guide for details on migrating to our full Authorize.Net API.
Solution
Accepted by topic author winternet
‎08-21-2015 01:58 AM
Contributor
Posts: 11
Registered: ‎08-10-2012

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

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

Contributor
Posts: 34
Registered: ‎09-16-2009

Re: JSON issues

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

 

Contributor
Posts: 44
Registered: ‎02-04-2015

Re: JSON issues

[ Edited ]

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.

New Member
Posts: 1
Registered: ‎10-10-2018

Re: JSON issues

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.

Highlighted
Contributor
Posts: 44
Registered: ‎02-04-2015

Re: JSON issues

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.