cancel
Showing results for 
Search instead for 
Did you mean: 

Verify card information before charging

I've been seraching for the correct way to verify a card's information and there doesn't seem to be one definitive answer. 

 

I've seen suggestions on using authOnly for $0.00 (which I've tried in the sandbox and it doesn't work) The error text is "There is one or more missing or invalid required fields"

I've seen suggestions on using authOnly for $0.01 (this works but this article visa authorize rules suggests using $0.00 or face "Misuse of Authorization System" fee) Although this article is 8 years old. 

 

I'm at a loss, I don't know why this isn't explicitly listed out somewhere in the documentation. Why wouldn't you want to verify a card's information before charging and potentially leaving multiple holds for whatever $ amount the order was for?

 

 

ckrausko
Member
5 REPLIES 5

Hi @ckrausko,

 

For those merchants who need to verify a card without charging it, we definitely recommend doing a $0.00 auth-only transaction when possible. Whether or not you can do $0 auth transactions in productions depends on your merchant account's processor and whether or not they support it. However, it's definitely supported in sandbox.

 

If you go to our API reference at http://developer.authorize.net/api/reference/#payment-transactions-authorize-a-credit-card and click the Try It tab, you can test that a $0 auth works there. So, if it's not working for you when you try it in your code, feel free to post what you're sending and we'll troubleshoot it here.

Aaron
All Star

@Aaron

straight from the dev api link you sent me. sending 0 in the amount field returns an error. I've removed my actual name and key for obvious reasons. 

 

{
    "createTransactionRequest": {
        "merchantAuthentication": {
            "name": "devName",
            "transactionKey": "devKey"
        },
         "refId": "123456",
        "transactionRequest": {
            "transactionType": "authOnlyTransaction",
            "amount": "0",
            "payment": {
                "creditCard": {
                    "cardNumber": "5424000000000015",
                    "expirationDate": "1220",
                    "cardCode": "999"
                }
            }
        }
    }
}

returns 

 

{
    "transactionResponse": {
        "responseCode": "3",
        "authCode": "",
        "avsResultCode": "P",
        "cvvResultCode": "",
        "cavvResultCode": "",
        "transId": "0",
        "refTransID": "",
        "transHash": "9AE24866C22A19C890CD66FE6B44F1C4",
        "testRequest": "0",
        "accountNumber": "XXXX0015",
        "accountType": "MasterCard",
        "errors": [
            {
                "errorCode": "290",
                "errorText": "There is one or more missing or invalid required fields."
            }
        ],
        "transHashSha2": ""
    },
    "refId": "123456",
    "messages": {
        "resultCode": "Error",
        "message": [
            {
                "code": "E00027",
                "text": "The transaction was unsuccessful."
            }
        ]
    }
}

 

 

Thanks so much for following up with this. Thanks to you, I was able to uncover a couple of problems with our API reference, and fixing those will surely save someone some time and frustration in the future.

 

Here's what I've found:

  1. I did my testing with the XML request, which in its default form works just fine. You did your testing with the JSON request, which isn't actually sending the same information. That's a problem, because our samples should be consistent with each other. I jumped in and already fixed that (just waiting for the next build of the web site).
  2. The reason the JSON request as currently displayed isn't working is that it doesn't contain a billTo element (and the XML request does). That "billTo" element (with child elements of "address" and "zip") is required when transactionType=authOnlyTransaction and amount=0.
  3. There's nothing documented anywhere that this billTo element would be required in that scenario. It's not required if amount<>0, so I need to double-check that it actually needs to be required. If so, we'll change that in the documentation.

So again, thanks for your help. Just remember to include the billTo information, and it should work correctly in both sandbox and production. In sandbox at least, they don't even have to be valid values. The can both be "1" or something.

 

@Aaron
Well I'm glad I'm not crazy. I appreciate the followup about the sandbox samples. 

Going back to your earlier comment "$0.00 transactions in productions depends on your merchant account's processor" do you mean Visa, Mastercard, etc? Or does Merchant Account's processor mean something else? 

If you mean Visa, Mastercard, etc is there not a clearly defined list somewhere? What would be the return value if it's not allowed? I don't want to tell a user their card is invalid because the processor won't allow a $0.00 auth. 

Hi @ckrausko,

 

Every Authorize.Net account will be tied to a merchant account at an acquiring bank, like Wells Fargo or Bank of America. These banks almost always don't build their own system for receiving the transaction and passing it on the Visa or MasterCard. Instead, they utilize the services of a processing network who takes all of these transactions from all over, and gets them into the actual card schemes' (like Visa and MasterCard's) networks.

 

So, when you sign up for an Authorize.Net account, we get information about your merchant account, and set things up on our end to receive transactions from you and route those transactions into the correct processing network for your merchant account. Not all of the processing networks support all of the capabilities that the card schemes (like Visa and MasterCard) support, so that's why we sometimes have to be aware of processor support when discussing particular features and use phrases like "if supported by your processor".

 

Most processors should support this, but if you had a processor that didn't, you would receive a specific error code back on every zero dollar auth transaction you attempted.