Integration and Testing

[willimus]

How is an integrator supposed to enable AVS support with Accept.js?  It is our understanding that it is not advisable to pass data collected in the Accept.js form to the payment details in the 'authCaptureTransaction' message. We see that the zip code is required to create the nonce token in the Accept.js form, so we assumed the AVS portion would occur when the nonce was generated. In our testing in sandbox and live accounts, we see now that AVS only works if the zip code is sent in the 'authCaptureTransaction' message. Can you confirm that this is the recommended approach, or do customers using the Accept.js method need to understand that Authorize.net's AVS service will no longer work?

[Aaron · Accepted solution]

Hi @willimus,

You actually have a couple of options with Accept.js. When you create the single-use token, none of the information sent is checked against the bank (like authorizing the card or doing an AVS check). The only thing that happens at that time is that a token is created containing all of the information passed.

When you process a transaction using the token, the system will run an AVS check using the ZIP specified in the <billTo> element in the transaction request. If that <billTo> element doesn't exist, then the system will look for a ZIP code embedded in the token. So, if the ZIP code exists both in the <billTo> element and the token, the one in the <billTo> element takes precedence.

There's two main use cases here:

Use case 1. You're collecting the customer's address because you need it to ship product or for some other reason. You have the address anyway, so send it with the transaction and get the benefit of AVS checking. No need to send the zip code in the token request.

Use case 2. You have no reason to collect the address, but still want AVS checking. Easiest thing to do there is to embed the ZIP into the token so you get AVS checking when the transaction is run without having to structure any of the address elements in the transaction request.

[Aaron · Accepted solution]

Hi @willimus,

You actually have a couple of options with Accept.js. When you create the single-use token, none of the information sent is checked against the bank (like authorizing the card or doing an AVS check). The only thing that happens at that time is that a token is created containing all of the information passed.

When you process a transaction using the token, the system will run an AVS check using the ZIP specified in the <billTo> element in the transaction request. If that <billTo> element doesn't exist, then the system will look for a ZIP code embedded in the token. So, if the ZIP code exists both in the <billTo> element and the token, the one in the <billTo> element takes precedence.

There's two main use cases here:

Use case 1. You're collecting the customer's address because you need it to ship product or for some other reason. You have the address anyway, so send it with the transaction and get the benefit of AVS checking. No need to send the zip code in the token request.

Use case 2. You have no reason to collect the address, but still want AVS checking. Easiest thing to do there is to embed the ZIP into the token so you get AVS checking when the transaction is run without having to structure any of the address elements in the transaction request.