academe / authorizenet-objects Goto Github PK

The authentication object and the credit card object (at least) need their data to be protected from var_dump() and probably serialize(), to avoid accidental exposure during debugging or logging.

The Authorize.Net response put the overall result, resultCode, into the messages entity. I've simply followed that same structure in Academe\AuthorizeNet\Response\Collections\Messages.

Instead, the list of top level messages should be unbound from the resultCode so the user does not have to handle the messages at all in order to look at the result.

It is being treated as a a scalar at the moment. It's a combination of number, state and date of birth. See here:

https://github.com/AuthorizeNet/sdk-php/blob/master/lib/net/authorize/api/contract/v1/DriversLicenseType.php

The SDK supports it, but the API Reference does not seem to mention it at all:

https://developer.authorize.net/api/reference/index.html#payment-transactions-charge-a-credit-card

There is a schema that gives us most of what we need to know about the objects:

https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd

It does not cover webhooks. If we are not auto-generating code from this schema, then we could at least use it to generate validation rules or tests.

The name "authorizenet-schema" feels like it would have been a better name than "authorizenet-objects" too.

This is a bit messy. The JSON response from Authorize.Net includes a BOM sequence at the start. This is invisible to the human eye, but causes json_decode() to throw a wobbly. It simply cannot decode the JSON with the BOM.

This is suggested in many places to remove the BOM:

preg_replace('/[\x00-\x1F\x80-\xFF]/', '', $json_string);

I would probably be a little more specific by looking at only the first (up to) three characters:

preg_replace('/^[\x00-\x1F\x80-\xFF]{1,3}/', '', $json_string);

There is also a plugin for Guzzle that removes the BOM, but that appears to be for older Guzzle versions. Not sure about the latest.

Anyway, it has not really got anything to do with these messages, because it's not a part of the data, but if we are not aware of it, it will certainly come to bite us when not dealt with at the transport level.

Allow the opaque data to be passed in as a single cardToken, with the descriptor and value separated by a colon (for now, can revise if other string formats are more suitable).

The documentation gives example XML arrays like this:

    <lineItems>
      <lineItem>
        <itemId>1</itemId>
        <name>vase</name>
        <description>Cannes logo </description>
        <quantity>18</quantity>
        <unitPrice>45.00</unitPrice>
      </lineItem>
    </lineItems>

then the JSON form looks like this in some places (with no arrays or unique properties, so could never work if there were more than one lineItem):

            "lineItems": {
                "lineItem": {
                    "itemId": "1",
                    "name": "vase",
                    "description": "Cannes logo",
                    "quantity": "18",
                    "unitPrice": "45.00"
                }
            },

and in other places it looks like this:

            "userFields": {
                "userField": [
                    {
                        "name": "MerchantDefinedFieldName1",
                        "value": "MerchantDefinedFieldValue1"
                    },
                    {
                        "name": "favorite_color",
                        "value": "blue"
                    }
                ]
            }

Now, this may be how it works, but looks wrong. It could be that a single lineItem is sent as an object, and multiple lineItems are sent as an array of objects, but it makes more sense to me if the same datatype is used in all cases (instead of a lineItem being sometimes an object and sometimes an array), i.e. an array of objects, even if only one. If always sending an array, then it it makes sense to drop the userField object in the structure. This is how I have assumed it works, for now:

            "userFields": [
                    {
                        "name": "MerchantDefinedFieldName1",
                        "value": "MerchantDefinedFieldValue1"
                    },
                    {
                        "name": "favorite_color",
                        "value": "blue"
                    }
            ]

This ticket will remain open until I know which is correct.

Authorize.Net supports "webhooks" that allow it to feed all authorisation results direct to the merchant site as a server-to-server request. It looks like this needs to be registered with the account and is not something enabled by default in the API (so testing webhooks with the sandbox may not be possible).

On return to the merchant site from the Hosted Payment Page, a GET is performed with the given return URL and NO further details. This means that if a web hook is not used to record the result, then the merchant site must explicitly fetch the transaction details, so an request is needed for that too.