Migrating from old SIM to Accept Hosted iFrame

[david_c]

We have an existing old SIM solution working, want to migrate to our new API Accept Hosted iFrame solution for just processing cc transactions.

I'd like to have a safe migration path and hopefully use our old SIM and our new API solution in parallel. Is this possible?

History:

- We have an OLD SIM solution that uses a "Transaction ID". There is no Signature Key!

- First, I am not sure how this is possible seeing that everything I have read says the SIM method uses a "Signature key". Maybe I am confused, but the only thing I can figure is that this version of SIM we use pre-dates Signature keys? Can you please explain why our existing SIM method uses a transaction key instead of a signature key for processing CC transactions?

- Our new solution is using Accept Hosted iFrame and seems to work pretty well in my separate sandbox account(s). 

- FWIW, our existing SIM uses Transaction version 3.0, and our new solution's sandbox reports that it is using 3.1. I assume this a something that needs to be addressed to be used with the new API?

Questions:

1) To go live with our new API Accept Hosted iFrame solution, do we need to create a new transaction key in our existing production environment for it to work? Or can we use the existing one that is used with the old SIM?

2) Do we need to upgrade the transaction version in our live account from 3.0 to 3.1? Will that break the existing old SIM method?

3) Will it be possible to run our old SIM solution and our new Accept Hosted iFrame API solution in the same Authorize.Net account with the same transaction key in parallel? Or is this impossible?

4) We don't want to break our existing solution, and would like to gradually move our system to using the new API. What steps and strategy would you recommend to accomplishing that safely?

Much thanks for your insight!

[ElaineM]

Hi david_c, The signature key can be used with SIM as well. Here is a copy of our Support Center, found at https://support.authorize.net/, article which advises how it is used in this case: The Signature Key is a feature that allows you to enhance the security of your Server Integration Method (SIM) and Direct Post Method (DPM) integrations, by using the HMAC-SHA512 authenticated hash. HMAC-SHA512 should be used in place of the legacy HMAC-MD5 authenticated hash. It also allows you to enhance the security of your transaction responses, by using a different HMAC-SHA512 hash, to replace the legacy MD5 Hash. NOTE: You must have configured a Signature Key in the Authorize.Net Merchant Interface before you can receive Webhooks notifications. This signature key is used to create a message hash to be sent with each notification that the merchant can then use to verify the notification is genuine. To generate your Signature Key: Log into the Merchant Interface at https://account.authorize.net. Click Account from the main toolbar. Click Settings in the main left-side menu. Click API Credentials & Keys. Enter your Secret Answer. Select New Signature Key. To disable the old Signature Key, click the check box labeled Disable Old Signature Key Immediately. If the Disable Old Signature Key check box is not selected, the old Signature Key will automatically expire in 24 hours. Click Submit to continue. Your new Signature Key is displayed. NOTE: The Merchant Interface will present the Signature Key in a 128-character hexadecimal format. However, developers will need to convert the Signature Key into binary format to use it. Please consult the documentation for your scripting language or development framework, for details on how to convert long hexadecimal strings to binary. You do not need to create a new Transaction Key in your account. You will use the same Transaction Key you are using now, unless it becomes compromised and must be reset accordingly. . Regardless of what transaction version you are currently sending, you are using version 3.1. We no longer support version 3.0 and convert all requests to 3.1. It would be recommended for you to use 3.1 as well if you are including it still as 3.0. You can use your existing integration method while implementing and testing your Accept Hosted integration. In order to do so successfully please generate your Signature Key, as described above, and begin using this as your MD-5 Hash value in your existing SIM integration as described in the article I copied here. If you have any payment form field settings configured in your production account, please remove them as they will not work with Accept Hosted and not all fields are supported on the Accept Hosted payment form. You can still include all of the fields, however you will need to include them in the call to generate the Accept token, rather than ask the end-user to fill in the fields on the Accept Hosted payment form. I hope this information is helpful. Thank you, Elaine