transHashSha2 not present in API response

[mroberts]

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

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?

[mroberts]

@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?

[RichardH]

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

[mroberts]

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

[Renaissance]

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

[falconkirtaran]

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?

[Renaissance]

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

[falconkirtaran]

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.

[Renaissance]

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

[inLeague]

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.