cancel
Showing results for 
Search instead for 
Did you mean: 

CCV Filter settings and CIM

When using CIM, there are several opportunities to provide the "card code" (or CVV, or CCV) value when making a request.  Most notably, you can send the card code when:

 

 

  • You're creating and storing a payment profile
  • You're creating a transaction (i.e. auth and caputure) against a stored payment profile
BUT, there is only one set of settings for the CCV Filter.
What if you want to validate the CCV when storing the payment profile, but not every time you run a transaction against the stored payment profile?  Is this use case supported?
As a merchant, I have the CCV when the payment profile is first created, but not later when I want to run transactions against it.  From the docs it would seem that, in order to enable and use the CCV Filter, a merchant would need to also submit the card code with every transaction request.

 

moklett
Contributor
18 REPLIES 18

 


@moklett wrote:
What if you want to validate the CCV when storing the payment profile, but not every time you run a transaction against the stored payment profile?  Is this use case supported?

 


 

Yes. Naturally you are not expected to have the CVV code for future payments against a payment profile. That would mean you would either have to store it (against PCI guidelines) or ask the customer for it every time you make a payment (not realistic or practical). That's why recurring payments work since the CVV is obviously not submitted for each subscription payment. I suspect it works like recurring billing payments where once an initial payment has been made using the CVV code subsequent payments no longer require it.

 


-------------------------------------------------------------------------------------------------------------------------------------------
John Conde :: Certified Authorize.Net Developer (Brainyminds) :: Official Authorize.Net Blogger

NEW! Handling Authorize.Net's Webhooks with PHP

Integrate Every Authorize.Net JSON API with One PHP Class (Sample code included)

Tutorials for integrating Authorize.Net with PHP: AIM, ARB, CIM, Silent Post
All About Authorize.Net's Silent Post
stymiee
Expert
Expert

 


@moklett wrote:

When using CIM, there are several opportunities to provide the "card code" (or CVV, or CCV) value when making a request.  Most notably, you can send the card code when:

 

 

  • You're creating and storing a payment profile
  • You're creating a transaction (i.e. auth and caputure) against a stored payment profile
BUT, there is only one set of settings for the CCV Filter.
What if you want to validate the CCV when storing the payment profile, but not every time you run a transaction against the stored payment profile?  Is this use case supported?
As a merchant, I have the CCV when the payment profile is first created, but not later when I want to run transactions against it.  From the docs it would seem that, in order to enable and use the CCV Filter, a merchant would need to also submit the card code with every transaction request.

 


 

 

If I may ask, (just to play a little devils advocate) why would you need to submit the ccv again if it was successfully validated (or not) for the initial transaction?

 

Can we just assume that when charging the payment profile using "createCustomerProfileTransaction" the CCV passed in the prior transaction was indeed valid? (if a positive response was received for ccv)

 

My reason for exploring this topic is a matter of why? and not how?.

 

Rebuttals are welcomed :)

 

Thank You!

 

 

soundcommerce
Trusted Contributor
Trusted Contributor

@stymiee, thanks for the response.  I would suspect (and really do hope for) the same thing, but there is no indication in any documentation that this would be the case.  In fact, the CIM documentation for createCustomerProfileTransactionRequest says that, for cardCode:

 

This field is required if the merchant would like to use the CCV security feature.

Can you confirm that the docs are wrong?  And that if the CVV is validated when the profile is created, the CCV Filter will not prevent later transactions that are not sent with the CVV?

 

@soundcommerce: I'm with you on this.  What you say is what it seems _should_ happen, but its just not what the docs are saying.

 

 

The CIM integration guide requires this field if the merchants plans to use CCV filter on subsequent transactions.


Required only when the merchant would like to use the Card Code Verification (CCV) filter.

 

Why would you need to verify/validate the CCV code again after creating the payment profile?

 

That's my only question.

 

Thanks!

 


@moklett wrote:

Can you confirm that the docs are wrong?  And that if the CVV is validated when the profile is created, the CCV Filter will not prevent later transactions that are not sent with the CVV?

 


 

The CVV is only validated when a transaction is actually performed. If you use the AIM API to process a payment before using the CIM API to process a payment (this may or may not occur depending on your businessmodel) you can verify the CVV at that point intime. If no transaction will occur before before using the CIM API to process a transaction may wish to perform an AUTH_ONLY on the credit card to verify the CVV (and AVS while you're at it).

 

 

A scenario where you would use the AIM API before establishing a CIM profile or processing a payment via CIM is for a variable rate subscription. If the first payment for the subscription is made immediately upon registration you would use the AIM API to process it and then you would know the results of the CVV check. If it meets the criteria you have set forth then you can create the CIM profile and process all future payments using CIM. If not, you can let the user know they need to correct their information or try a new card.


-------------------------------------------------------------------------------------------------------------------------------------------
John Conde :: Certified Authorize.Net Developer (Brainyminds) :: Official Authorize.Net Blogger

NEW! Handling Authorize.Net's Webhooks with PHP

Integrate Every Authorize.Net JSON API with One PHP Class (Sample code included)

Tutorials for integrating Authorize.Net with PHP: AIM, ARB, CIM, Silent Post
All About Authorize.Net's Silent Post

I assumed that a blank cardCode would trigger an N, P, and/or S Card Code Response.  In other words, I thought enabling any of the CCV Filter checks then required a cardCode to be sent.

 

It seems like what you guys are saying is "if you don't want to use the CCV Filter, then don't send the cardCode", so my assumption must have been wrong.

 


@moklett wrote:

I assumed that a blank cardCode would trigger an N, P, and/or S Card Code Response.  In other words, I thought enabling any of the CCV Filter checks then required a cardCode to be sent.

 

It seems like what you guys are saying is "if you don't want to use the CCV Filter, then don't send the cardCode", so my assumption must have been wrong.


 

 

Hello Moklett,

 

That would be the correct assumption; but once again, I would like to challenge the reason of why would you need to send the ccv2 again to charge a payment profile that passed card code validation initially?

 

Collectively as a whole, we understand the features and limitations of the CIM API as it relates to card codes.

 

We must now dig deeper within self to explore the reason of why? You will find that there is no need to resend the card code after initial validation.

 

Thank You!

 

 

soundcommerce, are you asking a rhetorical question, or are you not understanding me?

 

I do not WANT to send the card code after it has first been validated.  I do not.  I cannot.

 

My reading of the documentation lead me to believe that it is not possible to enable CCV Filter in a way that would allow me to validate the CCV when the payment profile was first stored, but not trigger mismatches if I did not send the cardCode with later CIM transactions.

 

I am not saying I want to send the card code every time.  There is no "why?" that you keep referring to.

 

 

Is it currently giving you a mismatch for a previously stored payment profile when performing "createCustomerProfileTransaction"?