Authorize.Net API questions and help with your payment integration.
Authorize.Net API questions and help with your payment integration.
01-16-2019 10:17 AM
Lightwave365, in answer to your question, "Do you have the hash being sent in the transaction?" Authorize.Net is sending both x_MD5_Hash and x_SHA2_Hash as non-null values EXCEPT when a recurring billing is declined and then only x_MD5_Hash is non-null and x_SHA2_Hash is null, which appears to be a defect in Authorize.Net's system.
Renaissance, in regard to "The updating fingerprints is done simply by generating the signature key," the update requires that the transaction key no longer be used, that a binary version of the signature key be used instead, and to use the alternate hash (SHA512 instead of MD5).
01-16-2019 11:34 AM
Have you tested this with a sandbox account? Where the transaction id is returned as 0? I have essentially the same code, but my hash values do not match what authorize.net is returning.
01-16-2019 02:46 PM
01-16-2019 03:55 PM - edited 01-16-2019 03:56 PM
Here we go. First, a little housecleaning:
It is advisable to review your documentation on a more regular basis than once
every few years in my books. And when your docs say “we use recommend and use abc security method. xyz method is also supported but we don’t recommend it”, that’s a good heads up that down the road xyz method is going to be axed. The way technology works is it is always changing. What is secure today won’t be as secure 1 year from now, and eventually it won’t be secure at all. When new methods are introduced it’s not for no purpose at all. It’s not fun and not life’s main attraction, but it kind of comes with the territory.
2. I now realize why so many people with those methods are posting. This is required to submit your transactions, and seems to function the same way the token functions for Accept Hosted. The token is far easier than this. People are posting that they cannot upgrade to the API based integrations now, but this may be a good reminder to do that when you can. You may otherwise continually find yourself having to do things the hard way or not being able to do things at all that those using the current integration methods do easily.
Now that that’s out of the way, let me see if I can help my good friends here.
@karenb the signature key is totally different than the transaction key, in case you’re not clear on that. You have 3 API credentials, the login id, transaction key, and signature key. Everything you’ve ever done likely requires the first 2, but to this point you may have never had to use the SK. So in the code below you will generate a signature key to use.
For recurring billing, I looked at the webpage on that and it says to use webhooks. Am I correct that all recurring billing transactions are manually submitted?
@Vikas_chauhan see the code below. Looks like the transaction key plays no role in your product either.
Here is the code for SIM/DPM. I haven’t tested it at all, but I believe it should work or get you almost completely there.
date_default_timezone_set('UTC'); //^may not be necessary depending on your configuration $login = "copy and paste your login here"; $signatureKey = "copy and paste your signature key here"; $signatureKey = hex2bin($signatureKey); $amount = $amount; //this assumes you have previously assigned the transaction //amount to a variable called $amount in your script $sequence = "make up a number and paste it here."; //save whatever number you use for validation on your end. //example in your docs uses 3 digit numbers $timeStamp = strtotime("now"); $currency = "USD"; //looks like that you only use this //if you specify currency type in your form request //you can use another value if you do things in a different currency //use one of the two strings below. $string = "^$login^$sequence^$timeStamp^$amount^"; //the above seems to be what you use if you don't submit //x_currency_code in your request $string2 = "^$login^$sequence^$timeStamp^$amount^$currency"; //looks like you use this if you specify currency $digest = strtoupper(HASH_HMAC('sha512',$string,$signatureKey)); //Looks like this value is submitted in your request under "x_fp_hash" //Look in the SIM/DPM developer guide on for what "x_" to to use for $sequence, etc. //page 29. Test this without the strtoupper fuction as well //All of the above are what is submitted in your request. You can //use the first code I posted to validate the response in SIM/DPM //you would retrieve the value lightwave posted x_sha2_hash instead //of what I posted and you change your $string input to match this //(the string and value from my orignal post are for php API based integrations)
01-16-2019 04:21 PM
^edit to the above. Looks like your verification procress requires a hash of 5 or more values from the request.
So what I posted will create your signature to send with the transaction, and then you will verify based on the values and instructions on page 73 of the guide I linked. I won't lose any sleep over not having to perform these acrobatics with my integration. There may be no choir to preach to on this thread, but accept hosted and the recent API based solutions are so much easier than this.
01-16-2019 08:46 PM
01-16-2019 11:17 PM
Renaissance, as far as I can tell, there has yet been no end of life announcement from Authorize.Net regarding Silent Post, Automatic Recurring Billing or SIM. The use of webhooks as an alternative is merely "suggested" by Authorize.Net, not required at this time. Silent Post still works today as it has in the past, and should continue to function after the hash upgrade as well, until some future as yet unannounced date when its end of life arrives.
Regarding "Am I correct that all recurring billing transactions are manually submitted?", yes and no. Subscriptions can be entered manually, but the recurring billings that flow from the subscription occur automatically.
Regarding "when I looked this up the process for how to do this has been in place and recommended since at least September of 2017 in the below document," that's not accurate. Authorize.Net's recently published Transaction Hash Upgrade Guide does not agree with that SIM guide. For example, the September 2017 SIM Guide says "A hash will always incorporate at least 31 caret (^) characters, even if only 5 fields are provided" while the Transaction Hash Upgrade Guide says that a hash can incorporate as few as 4 caret (^) characters.
01-17-2019 12:01 AM
01-17-2019 02:07 AM
@pudhgdfhgdfThank you for the relay snippet, it's almost there, but not working as is. The $hashData variable must be enclosed in carets as well, not just imploded.
The following code works for me on sandbox (PHP 7):
$signatureKey = 'YOUR-SIGNATURE-KEY-128-CHARS'; $fields = [ $_POST['x_trans_id'] ?? '', $_POST['x_test_request'] ?? '', $_POST['x_response_code'] ?? '', $_POST['x_auth_code'] ?? '', $_POST['x_cvv2_resp_code'] ?? '', $_POST['x_cavv_response'] ?? '', $_POST['x_avs_code'] ?? '', $_POST['x_method'] ?? '', $_POST['x_account_number'] ?? '', $_POST['x_amount'] ?? '', $_POST['x_company'] ?? '', $_POST['x_first_name'] ?? '', $_POST['x_last_name'] ?? '', $_POST['x_address'] ?? '', $_POST['x_city'] ?? '', $_POST['x_state'] ?? '', $_POST['x_zip'] ?? '', $_POST['x_country'] ?? '', $_POST['x_phone'] ?? '', $_POST['x_fax'] ?? '', $_POST['x_email'] ?? '', $_POST['x_ship_to_company'] ?? '', $_POST['x_ship_to_first_name'] ?? '', $_POST['x_ship_to_last_name'] ?? '', $_POST['x_ship_to_address'] ?? '', $_POST['x_ship_to_city'] ?? '', $_POST['x_ship_to_state'] ?? '', $_POST['x_ship_to_zip'] ?? '', $_POST['x_ship_to_country'] ?? '', $_POST['x_invoice_num'] ?? '', ]; $hash = strtoupper( hash_hmac( 'sha512', '^' . implode('^', $fields) . '^', hex2bin($signatureKey) ) ); var_dump(hash_equals($hash, $_POST['x_SHA2_Hash'] ?? ''));
01-17-2019 02:44 AM - edited 01-17-2019 02:48 AM
Renaissance, you say "The difference is that you use one thing for your fingerprint to validate the transaction on submission and another to validate the receipt," but I'm not sure to what you're referring, as my most recent post was not discussing fingerprints, only the verification after information is received from Authorize.Net.
You say you "searched in the support center and there is no mention of silent post having sha512, so to continue to use that product you would have yet another hash to keep up with," but for me, the evidence does not fully support that conclusion. For example, the Transaction Hash Upgrade Guide clearly applies to MD5 transaction hashes, and it is a fact that Authorize.Net is sending a MD5 transaction hash to the Silent Post program, and there is nothing in the Transaction Hash Upgrade Guide saying that the upgrade does not apply to all MD5 transaction hashes including that provided to the Silent Post program. But it's possible, because Authorize.Net is not strong on its documentation, to put it mildly.
You say "I don’t know if you mean the silent post response or the manual API call response," but there is no "manual API call" involved and thus no "manual API call response". That someone might manually enter subscriptions into the Merchant interface does not activate the Silent Post program. The Silent Post program is only activated after a payment transaction has been processed. And that too needs verification like every other payment transaction.
You say "when I look at the reference there is no mention of a hash in the response," but perhaps you are not looking at the correct response reference, which is the response to the (automatic) payment transaction, not responses to creating and managing subscriptions. It's a payment transaction response, almost identical to the payment transaction response sent after a customer manually makes a payment. But the hash is calculated differently for Silent Post than for a customer's manual payment. For a customer's manual payment, the string used to calculate the MD5 hash includes the API Login ID, but for a Silent Post, it does not.
In regard to "My guess is that if you’re using one of the older methods to do ARB and not using webhooks," yes, I've been talking about the Silent Post method for handling the transaction responses for recurring billing, not webhooks.
In regard to "if all of those values aren’t submitted in the request," that raises the other issue... the Transaction Hash Upgrade Guide and SIM Guide are inconsistent with one another. The former claims a string of just 4 or 5 carets is correct while the latter insists there must be a minimum of 32 carets in the string.