Showing results for 
Search instead for 
Did you mean: 

AcceptJS not passing through CVC? (Problem with declines)

Hi Authorize,


We have integrated using the AcceptJS method to generate a token, and once that token is generated successfully, we pass that opaqueData.dataDescriptor and opaqueData.dataValue values through to create a customer payment profile, and then we issue charges against that profile.


Following the guide ( we use very similar code to submit the cardNumber, month, year and cardCode parameters to Accept.dispatchData.


In the majority of cases, everything is working properly, however in production we are getting higher-than-usual rates of declines. If we take a look at even an accepted transaction, it always shows the CVC status as 'Not applicable', even though that info WAS passed in via AcceptJS:


Can you help us figure out why this is?


If we turn on the following option (, we actually get an error that the 'card code is required', however this is being passed into AcceptJS to create the token in the first place, which goes through just fine and returns the correct opaqueData response.


Is that setting not designed to be used in conjunction with AcceptJS?


Is there some other setting that could be causing this problem? It especially concerns me that even settled transactions display the card code as 'Not applicable' as demonstrated above. Any help would be greatly appreciated.


Thanks very much,

Free online storage and sharing with 2 GB of storage and 2 GB of bandwidth per month for free. We won't compress, alter or take ownership of your content.
Free online storage and sharing with 2 GB of storage and 2 GB of bandwidth per month for free. We won't compress, alter or take ownership of your content.

We are having this issue too. We want to create a Customer Payment Profile after we have validated the CVV and AVS match the client’s banking records. Once there is a valid Customer Payment Profile with matching AVS and CVV, we want to charge the profile on file, but we don’t want to store the CVV or ask the client to provide it at the time of payment.


If we charge the Customer Payment Profile and fail to provide the CVV we are given: Declined (Authorization with the card issuer was successful but the transaction was declined due to a card code mismatch with the card code on file with the card issuing bank based on the settings in the Merchant Interface.)


That is because the charge fails to pass the fraud filter restrictions which require a CVV to be present. The only way that we have found to approve the transaction is by disabling this restriction and change the filter in CCV Handling Filter:

Tools → Fraud Detection Suite → Enhanced CCV Handling Filter


Change this setting:

P is NOT Processed from DeclineAllow


Our Enhanced Card Code Verification settings:
N Does NOT Match → Decline
P is NOT Processed → Allow

S Should be on card, but is not indicated → Decline

U Issuer is not certified or has not provided encryption key → Decline


Once you make this modification, you can successfully process a Customer Payment Profile without a providing (asking the client again/storing) a CVV.


In theory, if you are validating the AVS and CVV at the time of creation or updating of a Customer Payment Profile, and the profile has not changed, there isn’t a need to decline a transaction that does not include a matching CVV when charging a Customer Payment Profile.

However, this relies on your ability to ensure that only profiles with matching CVV and AVS are created in the first place.

If you find a different methodology, we would like to know.