topic Re: transHashSha2 not present in API response in Integration and Testing

transHashSha2 not present in API response

mroberts — Fri, 22 Feb 2019 16:49:21 GMT

I have configured the signature key in my Sandbox account. On the "API Credentials & Keys" account setting page, I see "Signature Key Last Obtained:" with the timestamp of when I configured it, so it seems like it really is set.

I am using the API Live Console to try the API transaction here:

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

The response contains "<transHashSha2 />" - no value.

I know the API credentials used in the test are the correct credentials b/c I see the transaction appear in the "Unsettled Transactions" list of the same sandbox account where I configured the signature key.

Is there some additional setting I need to configure to get the new hash value to be returned?

Re: transHashSha2 not present in API response

mroberts — Mon, 25 Feb 2019 17:52:57 GMT

Additional Info...

I see a similar result when using JSON with the test, except transHashSha2 is an empty string.

Request:

{
    "createTransactionRequest": {
        "merchantAuthentication": {
            "name": "redacted",
            "transactionKey": "redacted"
        },
        "refId": "123456",
        "transactionRequest": {
            "transactionType": "authCaptureTransaction",
            "amount": "19.66",
              "profile": {
    		  	"customerProfileId": "1506827642",
    		  	"paymentProfile": { "paymentProfileId": "1506185517" }
  			}
        }
    }
}

Response:

{
    "transactionResponse": {
        "responseCode": "1",
        "authCode": "DEXXRV",
        "avsResultCode": "Y",
        "cvvResultCode": "P",
        "cavvResultCode": "2",
        "transId": "60117143359",
        "refTransID": "",
        "transHash": "366C3EAC47213A70487C7184EC69957A",
        "testRequest": "0",
        "accountNumber": "XXXX4349",
        "accountType": "Visa",
        "messages": [
            {
                "code": "1",
                "description": "This transaction has been approved."
            }
        ],
        "transHashSha2": "",
        "profile": {
            "customerProfileId": "1506827642",
            "customerPaymentProfileId": "1506185517"
        },
        "SupplementalDataQualificationIndicator": 0
    },
    "refId": "123456",
    "messages": {
        "resultCode": "Ok",
        "message": [
            {
                "code": "I00001",
                "text": "Successful."
            }
        ]
    }
}

Again, this is using API Live Console at the following URL:

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

Re: transHashSha2 not present in API response

kikmak42 — Tue, 26 Feb 2019 10:06:10 GMT

Hi @mroberts

For getting transHashSHA2in the response you need to generate a signatureKey first in you Merchant Interface. Then you will start receiving the transHashSHA2.

You can refer to this hash upgrade guide for more details: https://developer.authorize.net/support/hash_upgrade/

Hope this Helps!

Kaushik

Re: transHashSha2 not present in API response

mroberts — Tue, 26 Feb 2019 11:36:43 GMT

@kikmak42I have followed that document and obtained a signature key already. If I go to Account -> Settings -> API Credentials & Keys, I see: "Signature Key Last Obtained: 02/22/2019 10:43:00"

Additionally, when I obtained the key, it did provide me with the 128-char hex string key.

Unfortunately, after following the steps outlined in that document, I am still not getting transhHashSha2 in my responses.

Thanks!

Re: transHashSha2 not present in API response

mroberts — Tue, 26 Feb 2019 16:10:57 GMT

Another update...

As stated previously, I am using the API here to charge a customer profile (previously stored card):

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

With some more testing, I found that using the API to charge an "ad-hoc" card (not using CIM profiles), I DO get the transHashSha2 value in that response:

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

Is it expected that charging cards stored in customer profiles NOT return the new transHashSha2 value?

Re: transHashSha2 not present in API response

RichardH — Tue, 26 Feb 2019 17:30:03 GMT

Hello @mroberts

I've escalated this to a support specialist working on the MD5 project.

Richard

Re: transHashSha2 not present in API response

kabutotx — Wed, 27 Feb 2019 02:38:21 GMT

Worked fine for me. Are you sure you used sandbox.authorize.net Admin and not live or using the live login id/transaction key?

Re: transHashSha2 not present in API response

RichardH — Wed, 27 Feb 2019 03:41:20 GMT

@mroberts We've duplicated the issue you reported where transactions using customer profiles are not returning teh SHA2 response.

I recommend subscribing to this topic so that you'll be alerted via email for updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

Re: transHashSha2 not present in API response

kabutotx — Wed, 27 Feb 2019 03:46:50 GMT

Ah! It is the Customer Profile version. I accidently clicked on some different menu item and went back and tried a regular charge.

Thanks @RichardH

Subscribed.

Re: transHashSha2 not present in API response

mroberts — Wed, 27 Feb 2019 12:12:43 GMT

Thanks @RichardH! What are the odds this gets fixed in sandbox by March 7 or production by March 14? Trying to figure out what our options will be when the MD5 is no longer returned.

Re: transHashSha2 not present in API response

mroberts — Mon, 11 Mar 2019 13:54:19 GMT

@RichardHCurrently, in the sandbox, there is niether MD5 or SHA2 in the response, meaning there is no way to validate the transactions. Will this be the case in production on March 28?

Re: transHashSha2 not present in API response

RichardH — Mon, 11 Mar 2019 15:33:03 GMT

Hello @mroberts @kabutotx

Our product team confirmed that transactions using the Authorize.Net API and customer profiles will NOT return a hash. The hash is used to validate transaction responses that originate from a separate session to ensure it has not been tampered with. This is not necessary using the Authorize.Net API.

Richard

Re: transHashSha2 not present in API response

mroberts — Mon, 11 Mar 2019 16:23:17 GMT

@RichardH This issue isn't limited to just the API. We also see it using CIM.

CreateCustomerProfileTransaction has a directResponse field in the response.

(https://www.authorize.net/content/dam/authorize/documents/CIM_SOAP_guide.pdf, page 82). Per that document, the details of the directResponse field are found in the Advanced Integration Guide (https://www.authorize.net/content/dam/authorize/documents/AIM_guide.pdf, page 57). That guide lays out authenticating a response via the SHA2 hash, but it is not present in the directResponse field of the CreateCustomerProfileTransaction response using CIM SOAP integration.

Additionally, even using the API, there is no requirement that the createTransactionRequest method in the API (or CreateCustomerProfileTransaction in CIM SOAP) be part of any other session. I am able to make independent calls to those endpoints without any prior calls in the same session.

Re: transHashSha2 not present in API response

Renaissance — Tue, 12 Mar 2019 17:57:08 GMT

@mroberts

Not to butt in or step on anyone's toes, but I'm killing time and thought I would chime in. The hash verfication for AIM is supported by not really necessary. I am not familiar with the CIM product you are using, but if the response is similar to the AIM response (as it appears to be) then you don't have anything to worry about. Those transactions are conducted over TLS so you already have an encrypted validation.

Re: transHashSha2 not present in API response

falconkirtaran — Tue, 28 May 2019 20:40:03 GMT

I'm trying to use the accept hosted product with an embedded iframe, and because this method sends its response via the iframe communicator I need to use the transHashSha2 value to protect against spoofing (e.g. by injection from a malicious customer's browser). We're using JSON for this.

I notice the JSON response sent through the iframe communicator doesn't have transHashSha2 at all. I only get a response like this:

{
   "transId" : "40032162930",
   "orderInvoiceNumber" : "244",
   "authorization" : "K8SWCX",
   "totalAmount" : "0.1",
   "billTo" : {
      "zip" : "11111",
      "address" : "123 Elm St",
      "state" : "Washington",
      "country" : "United States",
      "phoneNumber" : "2069999999",
      "company" : "Meow Co.",
      "firstName" : "Falcon",
      "lastName" : "K",
      "city" : "Wentachee"
   },
   "shipTo" : {
      "zip" : "11111",
      "address" : "123 Elm St",
      "state" : "Washington",
      "country" : "United States",
      "company" : "Meow Co.",
      "firstName" : "Falcon",
      "lastName" : "K",
      "city" : "Wentachee"
   },
   "dateTime" : "5/28/2019 3:10:33 AM",
   "orderDescription" : "Your Store",
   "accountNumber" : "XXXX1111",
   "responseCode" : "1",
   "accountType" : "Visa"
}

I need to verify this. transHashSha2, as documented, is my preferred way; otherwise I have to use the API to query the transaction and that comes with a whole pile of potential errors and the possibility for transactions to be captured but not confirmed.

Is there some setting wrong? I generated a signature key. Anything else I need to set? Or is this just a bug, and if so when will it be fixed?

Re: transHashSha2 not present in API response

Renaissance — Wed, 29 May 2019 06:26:24 GMT

@falconkirtaran

Accept Hosted has no sha512 (or MD5) hash in the response. The element you are looking for will not be there. If you are looking to do a hash verification before taking action on a response, you need to set up webhooks to processing your response.

Re: transHashSha2 not present in API response

falconkirtaran — Wed, 29 May 2019 06:40:02 GMT

The documentation is very misleading then.

This page, for example, states that accept hosted requires the use of a signature key: https://support.authorize.net/s/article/Authorize-Net-Integration-Methods-Explained

Also, the integration documentation at https://developer.authorize.net/api/reference/features/accept_hosted.html#Transaction_Response says I should expect a createTransactionResponse in the returned data, but whether this key is present or not is not documented.

Aside from this, using either the transaction hash or webhooks to verify transaction success both have a serious problem, in that it is difficult to authenticate that a completed transaction for the same amount is not replayed by a malicious user to mark multiple orders as paid. The use of the transaction ID in the transaction hash is not a useful nonce for this since a nonce for authentication has to be generated by the person relying on the authentication -- in this case, by the platform using authorize.net APIs.

Is there something that prevents this from being a problem? Because if it's a problem, I can't recommend that authorize.net is safe to use with opencart even though I'm writing a plugin for it. I think the only way I can check the order is actually associated with the payment is to use the API and query the transaction myself after it's complete; neither the transaction hash nor the webhooks are useful.

Re: transHashSha2 not present in API response

Renaissance — Wed, 29 May 2019 10:42:11 GMT

@falconkirtaran

There are a few differences. When you run a chargeCreditCard script YOU are directly creating a transaction. When you make an API call to get a hosted payment page, your API call is purely to call a payment page for the customer to fill out. So if an accept hosted API call were to get a hash returned, it would be a hash to verify that the form was successfully called, which is double work since you have to generate a signature to call the form in the first place.

With your iframe it is sent from authnet to you, every time. Accept Hosted needs a signature key to use webhooks. Webhooks are a common component of that integration. On a scale of 1 to 10 webhooks gets at least a 12 in terms of being useful from me. The hash for webhooks is constructed with your signature key and the payload. So what you do is set up your app to do dB updates and run whatever else when the webhook is received, but first you verify the hash. If you and authnet are the only two parties with your signature key then a malicious user has 0 chance of bypassing your verification. The sun will burn out before he/she has gotten remotely even close. I think the math would be 36 raised the the 128th power total possible hash values.

P.S. my caps are not yelling at you I’m on a phone with no bold function.

Re: transHashSha2 not present in API response

inLeague — Wed, 04 Sep 2019 15:27:21 GMT

We just ran into this with a new integration and I understand why this verification is not critical when using payment profiles instead of card numbers.

Still, the documentation should be updated to reflect that this field will not be returned when calling createTransactionRequest with a paymentProfileId.