2 posts / 0 new
Last post
Inconsistent behavior of SecurityTokens regarding CVV

To whom it may concern,

My company is using the /SecurityTokens API method to tokenize our customers' credit cards. While testing the behavior of the system in Production today (using a company AmEx card), we noticed some puzzling behavior in response to tests with a deliberately incorrect CID number.

We have two merchant accounts, corresponding to different banks with which my company does business. Both have been configured with the same CVV authentication/blocking rules, both are using identical instances of payeezy. With the exception of the merchant JS keys, the API requests are identical - same auth=true, same api key, same cardholder and card data passed through, but:

1. For Merchant T, we can put total nonsense into the CID but SecurityTokens always succeeds, and our subsequent payment authorization succeeds.

2. For Merchant P, if we input the correct the correct CID on the first "try" on our website, SecurityTokens and the subsequent payment succeeds. However, if we input a nonsense CID on the first try, SecurityTokens fails as expected and throws an "invalid CID" error. If we then correct the CID and submit again, we receive the same error. Submitting the same data again using a web debugger like Fiddler consistently receives the same error message, regardless of the CID value being correct or incorrect. If we reload our webpage (thereby reloading payeezy.js) and try again, we can get a success with the correct CID.

Setting auth=false in the SecurityTokens request bypasses the issue entirely, but I don't want to CVV/CID authorization without needing to.

Has anyone else had a similar problem? Is anyone aware of a workaround?

Thanks very much for your time.

Re: Inconsistent behavior of SecurityTokens regarding CVV

When generating the Transarmor Token that replaces the PAN (credit card number) no AVS or CVV validation is performed. Only when you submit the transaction via Direct API would any AVS or CVV information be validated. Auth=true is no longer supported.