Hi,
I am getting this error when trying to create a transaction using a payment profile stored in the CIM.
The steps im following:
- using accept.js to send all the required fields + cardCode (CVV) to authorize.net.
- getting an Accept payment nonce from the response.
- sending the nonce to the server and using it to do a createCustomerPaymentProfileRequest.
- getting and saving the customerPaymentProfileId from this request.
- using the customerPaymentProfileId to do a createTransactionRequest
According to the api reference, the card code is used only for validation and is not stored in the customer profile.
So if the processor or whoever requires a card code to create a transaction, then the payment payment profiles I have stored in CIM should never work, unless I get the CVV again and send it along with the transactionRequest?
Just want to confirm if this is correct or if there is any way around this problem.
05-30-2017 11:59 PM
Hi @bo,
You're correct. Card code can not be saved by anyone, per PCI-DSS guidelines. In the case of a profile, if you're doing payments from a profile where the customer is not interacting directly with your system (like in a recurring payment scenario), you wont have a card code and won't be able to send one. If the customer is directly interacting with your system and choosing one of their cards on file to pay with, you can optionally ask for the card code at that time as an additional level of verification to send with the transaction.
This is all by design of the card schemes. Sending a valid card code with the transaction is seen as proof that not only did you get the card number from the actual card holder, but that the cardholder was directly and immediately involved with the transaction. Saving the card code at any point in the process would subvert that chain of assumptions.
With regards to your specific error 33, do you by chance have card code set as a required field in the form field settings in the merchant interface? Despite the name, these settings of which fields are required will actually apply to all transactions, whether or not the transaction uses one of our forms.
05-31-2017 02:03 PM
This is an old thread, but I am having the same issue.
Please note that currently this works in Sandbox. We can create a customer payment profile using the opaque data and then charge the customer using that payment profile. As bo mentioned, in Production this gives error code 33. Sandbox and Production should behave the same.
So, how can we get around this limitation using Accept.js?
We are using the C# driver and Accept.js. The problem that we are having is that we need a payment profile to be associated with our transaction in order to do refunds.
If we try to create the customer profile first using the opaque data, we get error 33.
If we try to create the customer profile with the transaction we get error E00102 (Customer info is missing). We assume that an email and description are missing here, but the c# driver, does not provide any field to specify this info with the customerProfilePaymentType.
If we create the customer profile after the payment is processed using the transaction id that works, but we cannot refund the transaction using the customer payment profile, since they are not linked together.
How should we proceed to have a customer payment profile linked to a transaction using opaque data that can be re-used?
Thanks
12-03-2019 06:40 AM
To anyone that comes across this issue later, our fix was related to this ...
This error suggests you have set CVV as required for each transaction in the Merchant Interface. Follow the instructions here: https://developer.authorize.net/api/reference/responseCodes.html?code=33
Sandbox requests do not behave the same way because, by default, "Card Code" is not a required field in Sandbox accounts.
11-17-2022 11:47 AM