X-Cart forums

[finestshops]

Hi guys,

Does anybody use Authorize.net CIM with X-Payments? Our client set CVV as required in Authorize.net CIM on Authorize.net side and now all orders are getting declined even though CVV is entered during checkout.

Order declined.
Reason: Card Code is required.

but we checked log with request sent to Authorize.net and it has cardCode submitted to Authorize.net

<payment>
<creditCard>
<cardNumber>****************</cardNumber>
<expirationDate>*******</expirationDate>
<cardCode>***</cardCode>
</creditCard>
</payment>

Any ideas why Authorize.net is not getting this card code?

[random]

Originally Posted by finestshops

Hi guys,

Does anybody use Authorize.net CIM with X-Payments? Our client set CVV as required in Authorize.net CIM on Authorize.net side and now all orders are getting declined even though CVV is entered during checkout.

Order declined.
Reason: Card Code is required.

but we checked log with request sent to Authorize.net and it has cardCode submitted to Authorize.net

<payment>
<creditCard>
<cardNumber>****************</cardNumber>
<expirationDate>*******</expirationDate>
<cardCode>***</cardCode>
</creditCard>
</payment>

Any ideas why Authorize.net is not getting this card code?

Hi, your client should not set CVV as required in the gateway settings since the same check is made by X-Payments itself.
Please see the following article for details:
http://help.x-cart.com/index.php?title=X-Payments:Tokenization_and_Re-Use_of_Saved_Credit_Cards_(X-Payment..._by_Intuit_Inc

[finestshops]

Thanks, Vladimir. but, unfortunately, right now Authorize.net is rejecting even the first transaction (not when saved card is used) when cvv is entered and sent to Authorize.net (according to the log) with "Card Code is required" error. It looks like x-payment is not sending CVV to Authorize.net in correct format when CIM method is used so Authorize.net does not see CVV in the transaction.

it works if we disable CVV requirement on Authorize.net side but in this case even first transaction on the card is not being checked for correct CVV and client just got over $2500 worth of fraud orders yesterday because CVV was not checked.

any solution for this?

[random]

Authorize.net CIM integration presumes that for each non-subsequent payment it does two steps: creates a payment token and then pays using it.
So, even for "first" payment it saves a card and then use its token to pay.
The mentioned issue appears on that second action performed during the single payment process - it uses a token but doesn't provide CVV again and this fails according to the merchant account setup.

So, you need to setup the merchant account so that it will decline incorrect CVV, but still accept payments without CVV at all. Please don't worry about payments without CVV because X-Payments doesn't let the payment without it. But Authorize.net still should check that CVV is valid.

[finestshops]

thanks, Vladimir. that makes sense. we'll try to set up authorize.net this way.

[finestshops]

Vladimir,

This did not help. According to Authorize.net, X-Payments is not passing the CVV to them at all, not even when card is used for the first time.
We do see it in <cardCode>***</cardCode> but Authorize.net is not getting it or getting it in incorrect format. Maybe it has to be in a different format but the root of this issue is with cardcode not getting to Authorize.net at all.
can you check integration documentation to make sure you are sending cardCode properly to them?

[finestshops]

Vladimir,

Your CIM integration in X-Payments is done incorrectly.
tech support at Authorize.net identified the problem.

If a CIM profile for the customer exists, then the CVV result code will always come back as "not applicable."

Auth.net believes that X-Payment is creating the CIM profile first, then drawing a transaction against that profile.
which is confirmed by your statement in previous post : " even for "first" payment it saves a card and then use its token to pay."
This will not allow merchant to check CVV causing lots of fraud charges

X-Payments has to submit transaction first, then create the CIM profile.
for $1500 you want for x-payments, would be nice to have integration done properly at least with the largest and most popular payment gateway

Can we expect this to be fixed in the near future?

[random]

Originally Posted by finestshops

Vladimir,

Your CIM integration in X-Payments is done incorrectly.
tech support at Authorize.net identified the problem.

If a CIM profile for the customer exists, then the CVV result code will always come back as "not applicable."

Auth.net believes that X-Payment is creating the CIM profile first, then drawing a transaction against that profile.
which is confirmed by your statement in previous post : " even for "first" payment it saves a card and then use its token to pay."
This will not allow merchant to check CVV causing lots of fraud charges

X-Payments has to submit transaction first, then create the CIM profile.
for $1500 you want for x-payments, would be nice to have integration done properly at least with the largest and most popular payment gateway

Can we expect this to be fixed in the near future?

Authorize.net CIM API allows both ways (place transaction + create profile from it OR create profile + place transaction using it) so we can't say that the integration is done incorrectly.
However, since it causes some issues for you we'll consider to change the behavior in a next release.