Integration and Testing

[lib]

Hello,

Our application is card-present.

The field x_zip is optional, and we are not currently using it.  Our application takes the card track data and sends it

directly without it being typed in anywhere.  So unless we figure out how to rewrite the track data on our

test cards, we can't even use the account number as a trigger without modifying our application-under-test.

So, could you please set up some test responses like you did using the zip code, that instead use the amount to

trigger a partial authorization?

You can use weird numbers that testers would not likely accidentally land on, like 15.37, 17.91, or even 137.31.

I guess if you really want to be safe, you can even make this behavior active only if x_zip is absent from the submission.

Thank you very much.

[lib]

Hello,

Our application is card-present.

The field x_zip is optional, and we are not currently using it.  Our application takes the card track data and sends it

directly without it being typed in anywhere.  So unless we figure out how to rewrite the track data on our

test cards, we can't even use the account number as a trigger without modifying our application-under-test.

So, could you please set up some test responses like you did using the zip code, that instead use the amount to

trigger a partial authorization?

You can use weird numbers that testers would not likely accidentally land on, like 15.37, 17.91, or even 137.31.

I guess if you really want to be safe, you can even make this behavior active only if x_zip is absent from the submission.

Thank you very much.

[Michelle]

Hi lib,

Thanks for the suggestion. I'll pass that on to your development teams and let them know.

Thanks,

Michelle

Developer Community Manager

[tangent]

Hi,

Integration Method: AIM

Version: 3.1

Currently testing with my AuthNet Developer test account in Live Mode on this test account.

My website's payment pages are using SSL.

AVS Filter is enabled  (I understand what the different filter settings do).

CVV Filter is enabled  (I understand what the different filter settings do).

Using the excellent AuthnetAIM.class.php provided at http://www.johnconde.net/blog/tutorial-integrating-the-authorizenet-aim-api-with-php/ (many thanks and kudos to John Conde for making it available!) I successfully integrated AIM with my website yesterday and all of my tests of AIM have gone smoothly.

I have almost completed testing my AIM integration using my developer test account. I have a Merchant Account and a Production AuthNet account and will start testing later this week using my Production AuthNet Account. 

 
The credit card form on my site is validating the credit card info per the validation rules specified at http://www.johnconde.net/blog/tutorial-integrating-the-authorizenet-aim-api-with-php/?.

The Card Code (a/k/a CCV) is a required field on my credit card form, and my question relates to testing the Card Code using my developer test account in Live Mode.

I understand how the special Zip Codes and Card Codes can be used in my developer test account to generate specific responses (E.g., I tested them using a test Visa card with the special Zip Codes and 3 digit Card Codes and produced the expected responses (response code and response reason text). 

I understand that all credit cards except American Express Cards use a 3 digit Card Code when the Card Code filter is enabled. And that American Express Cards use a 4 digit Card Code

The validation of the submitted credit card form on my site will only allow a 4 digit Card Code for an American Express card. So far I have only been able to locate the special 3 digit Card Codes to generate the specific responses.

When I test with an American Express card, the validation on my site requires me to enter a 4 digit Card Code. I don't know of any 4 digit card code that I can use to generate that the response CCV card code matched, or any of the other Card Code responses. Consequently, I haven't been able to test the Card Code Filter matching rules using an American Express Card.

My question is:

Are there any 4 digit Card Codes that I can use with an American Express Card to generate all of the specific responses?

Thank you.

P.S.

I understand that the special Zip Codes and Card Codes only generate specific responses in the developer test account, and not in a Production AuthNet account.

I also understand how the 13 digit 4222222222222 test credit card can be used in the Live mode of a Production AuthNet account (or the Live Mode of a Developer test account) to generate specific errors by entering an amount that corresponds to the desired error to generate.

[Trevor]

There is not a 4 digit code specifically for American Express, but there is no validation performed on the Authorize.Net side that requires a 4 digit code for AmEx so you can trigger a successful card code validation response using the same 3 digit card code.

I also want to clarify that the 4222222222222 test card only functions on accounts in in test mode.

[tangent]

Trevor.

Thank you for answering my question, and for correcting that I misstated the mode in which the 4222222222222 test card functions in the accounts.

[WHeisenberg]

Hello,

 I posted a question in the Integration forum about this, but it appears I might be able to get an answer through this thread just as well.

 I am using my test account to make sure my e-commerce system is working correctly before going live.

 I am using the CIM system.

 When a new customer is added to the site,  the system gets them their customer profile ID and sets up their customer payment profile ID(s) correctly.

 I'm having a problem when I attempt to run an actual payment through the system.   The payment process goes through the AuthNet server,  but when the system returns to my site it is giving a response of 3.

 I 'thought' that response code 3 meant the payment was placed on hold, but after checking it turns out that a 3 means there was an error.

 I re-ran the exact same authorization through the system just a few minutes ago, and it went through without a problem.  I did not change any code at all, anywhere.

 What would cause the transaction server to throw a response code of 3 on the first few tries, and then work fine on the latest try, without any code having been changed?   A glitch?

 Sorry if this seems redundant :)

WH

[TJPride Expert]

The developer server is occasionally unreliable. It's also possible something changed in what you were sending, is the error code of 3 the primary error code or the error sub-code? Can you post a var dump of your response (using print_r()  if PHP)?

[entitydc]

I'm running into similar errors as others have posted. This is using CIM.

I'm posting live results against a sandbox account. The zipcodes work (for AVS responses), but Card Code Status returns "Not Applicable" no matter what I enter.

Posted to this URI: https://apitest.authorize.net:443/xml/v1/request.api

    method: :post
    uri: https://apitest.authorize.net:443/xml/v1/request.api
    body: |
      <?xml version="1.0" encoding="utf-8"?>
      <createCustomerProfileRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
        <merchantAuthentication>
          <name>65VCab8p</name>
          <transactionKey>887Dy2KXc5JkW8Se</transactionKey>
        </merchantAuthentication>
        <profile>
          <merchantCustomerId>entity13321979715987</merchantCustomerId>
          <email>entity+1332193519@asdf.com</email>
          <paymentProfiles>
            <customerType>individual</customerType>
            <billTo>
              <firstName>First</firstName>
              <lastName>Name</lastName>
              <company></company>
              <city></city>
              <state></state>
              <zip>46204</zip>
              <country>United States</country>
            </billTo>
            <payment>
              <creditCard>
                <cardNumber>4012888888881881</cardNumber>
                <expirationDate>2013-01</expirationDate>
                <cardCode>901</cardCode>
              </creditCard>
            </payment>
          </paymentProfiles>
        </profile>
      </createCustomerProfileRequest>

When I validate the transaction via the sandbox, I see that AVS returned the proper result:

Address Verification Status:

Non US Card Issuing Bank (G)

I should be seeing a status of "N" being returned. Even if I remove zip code, etc., I can never get a CVV response returned.

Card Code Status:

Not Applicable

Any suggestions?

thanks,

Rob

[TJPride Expert]

According to this, you should be getting Does Not Match:

http://community.developer.authorize.net/t5/Integration-and-Testing/Triggering-Specific-Transaction-...

The documentation does say this, however:

cardCode is used only for validation and is not stored in the customer profile. Use it only when submitting validationMode with a value of testMode or liveMode.

[entitydc]

Thanks. In testMode, the validation passes no matter what, which is what we're trying to avoid.

It looks like I need to force either oldLive or liveMode, but haven't decided which of those is better yet (we're processing a significant # of international credit cards). Are there differences in how those two handle the $.01/$0.00 authorization charges?

Additionally, is it considered ok to use a dummy address for liveMode? I've seen that suggested here (and by Authorize.net staff), but any time I'm processing credit cards, I'm concerned about sending invalid data intentionally. We are an subscription-based digital company, so we don't require confirmation of shipping addresses for our customers.