Signature Key and Accept Hosted form

[rohit_acutedge]

Hi,

I have gone through the documented API for Accept Hosted form and the "getHostedPaymentPageRequest" api but I haven't found anyway to send encrypted data including billing information to the API. This is a deal breaker for our customer to be able to use/adopt Authorize.net. So, my question is if it is possible to use this feature and send the data to Authorize.net API using signature key in an encrypted form rather than pure text json?

regards,

[RichardH]

Hello @rohit_acutedge 

Could you help us better understand your client's encryption requirements? 

The getHostedPaymentPageRequest  is performed over a TLS connection.  Accept Hosted is also a PCI DSS SAQ-A compliant solution.

Richard

[rohit_acutedge]

Richard,

Thanks for replying. We are pre-populating the billing address for the fields on the Accept Hosted form. We are able to do that using the API parameters in json format (plain text) but the customer wants to transfer that using a signed request as encrypted data that can be protected with signature keys they would like to manage.

Hope it clarifies.

regards,

[Renaissance]

@rohit_acutedge 

Not trying to step on anyone's toes here, but a few points: 1. You cannot prepopulate billing addresses on the Accept Hosted form, not exactly. You can pass the billing address, as well as the shipping address, and all kinds of other information that you may be collecting from the customer on your web application. You can retrieve them all later via the API. The input fields will not be prepopulated, however. I think the billing address may show up on the receipt if you pass it to authorize in the API call. The shipping address will. 

2. The go to way to encrypt data in transmission is to use an SSL certificate. There are several providers that offer these completely free now. You want an SSL certificate on your website in all cases. Google's SE algorithm penalizes sites without SSL, and most browsers will now have a warning next to the address bar "not secure". 

So the process works like this, behind the scenes:

-You collect data on your website.

-If you are SSL encrypted no one  electronically "spying" on your customers while they're on your website has a prayer of getting sensitive information from form submissions. So when your customer fills out their shipping address, billing address, etc. and then clicks "Next" to go to authorizes Accept Hosted Form, all of the data is secure as it is being passed from your server to authorize.net's server. 

-Authorize.net's Accept Hosted Form is also SSL encrypted and meets the most stringent security standards set by the Payment Card Industry Security Council. No one has a prayer there either. You are not likely to find a more secure environment anywhere, period. 

The data you submit will be stored by authorize and can be retrieved through an API call. As long as you do any API calls over SSL encryption, then the data is safe there too.  If you pull customer data from API calls and store it on your client's backend database (as I do), you can implement an encryption method to encrypt it in storage. That way if someone ever gets your database, the info will be unusable. Also note that companies like AWS will encrypt data stored on your backend database as part of their service offering. 

I would run this all by your client. They are probably coming from a place of incomplete information. I love this service. It is awesome and I see no reason to ever move any of my clients elsewhere. I have however looked at other providers' documentation.  This service they appear to be asking for, where the payment gateway implements a custom encryption/decryption method in conjunction with the merchant's website does not exist anywhere and I think will not ever. 

[rohit_acutedge]

Thanks for your inputs.

Few points to clarify.

1. We have the billing address available on a db record in our Salesforce app. 

2. We are able to pass the detail using api with the following payload:

{"getHostedPaymentPageRequest": {"merchantAuthentication": {"name": "xxxxx","transactionKey": "xxxx"},"transactionRequest": {"transactionType": "authCaptureTransaction","amount":"410.00" ,"profile": {"customerProfileId": "xxx"},"customer": {"email": "xxx@xxx.xxx"},"billTo": {"firstName": "TestFirstName ","lastName": "TestLastName","company": "xxx","address": "1 Main Street","city": "Bellevue","state": "WA","zip": "xxx","country": "USA"}},"hostedPaymentSettings": {"setting": [{"settingName": "hostedPaymentReturnOptions","settingValue": "{\"showReceipt\": true, \"url\":\"https://c.xxx.visual.force.com/xxx\", \"urlText\": \"Continue\", \"cancelUrl\": \"https://c.xxx.visual.force.com/xxx\", \"cancelUrlText\": \"Cancel\"}"}, {"settingName": "hostedPaymentButtonOptions","settingValue": "{\"text\": \"Pay\"}"}, {"settingName": "hostedPaymentStyleOptions","settingValue": "{\"bgColor\": \"blue\"}"}, {"settingName": "hostedPaymentPaymentOptions","settingValue": "{\"cardCodeRequired\": false, \"showCreditCard\": true, \"showBankAccount\": false}"}, {"settingName": "hostedPaymentSecurityOptions","settingValue": "{\"captcha\": false}"}, {"settingName": "hostedPaymentShippingAddressOptions","settingValue": "{\"show\": false, \"required\": false}"}, {"settingName": "hostedPaymentBillingAddressOptions","settingValue": "{\"show\": true, \"required\": false}"}, {"settingName": "hostedPaymentCustomerOptions","settingValue": "{\"showEmail\": false, \"requiredEmail\": false, \"addPaymentProfile\": true}"}, {"settingName": "hostedPaymentOrderOptions","settingValue": "{\"show\": true, \"merchantName\": \"G and S Questions Inc.\"}"}, {"settingName": "hostedPaymentIFrameCommunicatorUrl","settingValue": "{\"url\": \"https://mysite.com/special\"}"}]}}}

3. Based on this payload, the form appears as shown in the screenshot at https://ibb.co/tLNjBQQ

4. So you can see that the json payload has address elements in clear text. We are using the endpoint: https://apitest.authorize.net/xml/v1/request.api

5. The question is if we can encrypt this payload so that when the api is called from our Salesforce app, the data is sent to the api in an encrypted form.

regards,

[Renaissance]

You are correct sir!!

I have tried this before and it didn't work. Others have commented that it would not work for them either in previous threads. Not sure what has changed or what I was somehow doing wrong. 

So to amend my original reply, scratch this sentence:

1. You cannot prepopulate billing addresses on the Accept Hosted form, not exactly. 

I will have to test the shipping address again. I just tested the billing address and it works. The remainder of my reply is still applicable. Anything you send to the API over an SSL encrypted web address will be encrypted. The fact that you or your customer enters it in plain text doesn't change that.  It will be encrypted in transmission. 

[rohit_acutedge]

Thanks again. Their primary concern is the level of encryption that they want to control with a key they can authorize. I have seen the presence of signature key instead of transaction key in documentation but if the body is expected as json text in the api call, I am not sure how I should be able to encrypt this in Authorize.net api.

At a high level, this concept is shown at https://developers.flipsnack.com/sign-request.html but I need documented resource if this is possible in Authorize.net or not.

Thanks for your help.

[Renaissance]

@rohit_acutedge 

I fully understand what you want. SSL encryption provides exactly that. Authorize does receive the data in plain text after it is decrypted. Here is a link that explains how this works. 

https://www.digicert.com/ssl/

The encryption/decryption happens automatically.  As for the level of encryption, you're going to be more than fine with the 2048 bit encryption that is the current standard for SSL/TLS. For a cyber criminal using the best currently available technology, it would take longer to break such an encryption than the entire age of the universe * 300,000.  I don't want to get long winded, but I encourage you to check it out. There isn't really anything better that can be used right now. 

The link you posted does not describe exactly what your clients are looking for. That is a process of using a signature key to verify ones identity before submitting requests. Authorize.net does have that, and their method is better and more secure than the signature process that link describes. It is more secure because it uses a stronger hashing algorithm, and in your case, because you are using Accept Hosted, it is better because the process for generating the fingerprint is easier.  You have actually already did this in the json request that you posted. The same API call does it all.  

[rohit_acutedge]

Thanks again.

Regarding your comments:

The link you posted does not describe exactly what your clients are looking for. That is a process of using a signature key to verify ones identity before submitting requests. Authorize.net does have that, and their method is better and more secure than the signature process that link describes. It is more secure because it uses a stronger hashing algorithm, and in your case, because you are using Accept Hosted, it is better because the process for generating the fingerprint is easier.  You have actually already did this in the json request that you posted. The same API call does it all. 

Can you point me to the documentation and preferably an example where this is described for Authorize.net where signature key has been used for signing and hashing the payload?

regards,

[Renaissance]

https://developer.authorize.net/api/reference/features/accept_hosted.html#Requesting_the_Form_Valida...

This is the fingerprint. Rather than use the signature key, you use the transaction key and API login. Authorize provides the token in the response. Then you use that to pull up the form. The purpose of this is to verify that the request is coming from you, not to hash the customers data.  That is the security feature, and is apples to apples with the signature fingerprint  process you linked. It serves the exact same purpose, only it does so better.

My advice to you would be to do a little education with your clients. All they need to know is this-

install an SSL certificate and anything that gets sent anywhere will be encrypted in transmission.  They already have done this per your json request-

https://c.xxx.visual.force.com/xxx\

The https://  in the url, as opposed to http:// means they are SSL/TLS encrypted.

https://accept.authorize.net/payment/payment is the hosted form address. It also has https://.