Authorize.net and AVS

[wdillsmith]

I'm having a problem with authorize.net and I'm hoping someone has an idea on how to fix it.

On our website, we have integrated authorize.net into our shopping cart (using their Advanced Integration Method - AIM). When a customer clicks the final submit button, we do a real-time "authorize only" event on their credit card. We also have the address verification system (AVS) turned on. Authorize.net attempts to do the card authorization first, and if that succeeds, then they do the address verification. So what happens is sometimes a legitimate customer will put in the wrong billing address (e.g., moved recently, used work address instead of home address, etc.), which will result in a transaction being declined. However, in reality, the authorization on their card was approved, but since the AVS was declined, the overall status of the transaction from our end results in a decline. If a customer is using a debit card, the bank will withdraw the money immediately upon authorization, even if the AVS fails, because the authorization is done first. What we end up with are customers that never actually completed a sale, but still showing that we charged their card, or completed sales with duplicate transactions. These pseudo-charges can take up to 30 days to be removed from the customers account by the bank, and there is nothing we as a merchant can do to speed up the process.

The banks have gotten even worse the past few months and often are hitting our customers with overdraft charges in these instances. Here is an example:

- Customer has $500 in their checking account

- Customer places a $300 order with us using their debit card. On the first submission, they put their new address, but the bank has not updated the AVS system, so the AVS fails, but the bank shows $300 withdrawn

- Customer enters their old billing address and re-submits the transaction. This time AVS is successful. However, now the charge has gone through twice, so the bank has taken out a total of $600, and customer gets an overdraft fee.

We are having these kinds of issues on a weekly basis now. Authorize.net claims they can't reverse the processing order to do AVS before authorization. This is what I got back from authorize after I basically asked them to reconsider:

"We can not reconsider our policy. It is part of our agreement with the Card-Issuing Banks and the Payment Processors that we will only decline the transactions because of an AVS mismatch after the bank has already authorized the transaction. That is not something that we can reconsider or that we can do differently. I am so sorry about that."

There is also no way to do an "AVS only" type transaction. I can't believe that as big as authorize.net is, that nobody else is having this problem. I'm open to any suggestions on how to get around this issue. Thanks,

Bill

[crankydave]

Welcome to the "Banks Suck" club.

I went on a bit of a rant on this about a year ago...

Merchants Protect Consumers

The banks don't actually take the money out of their account. The put a hold on the amount that is authorized for a period. Lat customer I talked to was told by their bank the hold was for 10 days. They requested that a fax a letter to their bank with a whole bunch of info in order to release the funds. If I did that every time AVS declined a transaction I'd get nothing done.

Bottom line... there's nothing you can do and still protect yourself.

Banks suck! The take no responsibility for anything and throw it all upon the merchant and don't care who they inconvenience.

These types of transactions are a daily occurrence for me. I field emails and phone calls on a regular basis because of it. When it happens, I tell my customers the truth.

I tell them that we take the potential unauthorized use of their credit card very seriously and we make every effort to protect them from potential fraud. I tell them that their bank verifies literally nothing when it comes to approving transactions made online with their credit card and that we attempt to verify as much information as we can in order to protect them.

One thing you can do when this happens is to capture the transaction that has been declined. Once you've satisfied yourself that the transaction is legitimate, go into your virtual terminal and capture only using the authorization number.

I keep typing but that would only lead me into another rant on how and why banks suck. It's too early in the day and I'm in too good a mood this morning to get started... again.

Dave

[Feydakin]

Let me add that anyone using a debit card online is an idiot.. For that matter, debit cards in general are stupid..

As David said, the problem is not with Authorize.Net, its with the banks.. They have set up the process so that they accept "no" liability for anything, even when they cause the problem directly..

They are easily the most qualified to authorize transactions since they hold all of the information, yet they refuse to do so.. They leave it up to the merchant to make the merchants take all the risk..

Banks suck..

[cw1865]

Originally Posted by wdillsmith

On our website, we have integrated authorize.net into our shopping cart (using their Advanced Integration Method - AIM). When a customer clicks the final submit button, we do a real-time "authorize only" event on their credit card. We also have the address verification system (AVS) turned on. Authorize.net attempts to do the card authorization first, and if that succeeds, then they do the address verification. So what happens is sometimes a legitimate customer will put in the wrong billing address (e.g., moved recently, used work address instead of home address, etc.), which will result in a transaction being declined. However, in reality, the authorization on their card was approved, but since the AVS was declined, the overall status of the transaction from our end results in a decline. If a customer is using a debit card, the bank will withdraw the money immediately upon authorization, even if the AVS fails, because the authorization is done first. What we end up with are customers that never actually completed a sale, but still showing that we charged their card, or completed sales with duplicate transactions. These pseudo-charges can take up to 30 days to be removed from the customers account by the bank, and there is nothing we as a merchant can do to speed up the process.

1. If the order volume is such that manually running the orders makes sense, do that.
2. If the order volume exceeds this, perhaps the system can do an authorize and capture (instead of simply authorizing)

Personally, I manually do it and frankly its the favorite part of my day.

1. If billing matches shipping, I run the transaction, if AVS is in any way negative, I'm looking at IP Address, if area code for zip code is correct and things of that nature. Even aside from fraud, this also helps to prevent shipping to an incorrect address, you'd think people would type their addresses correctly all the time, but believe it or not they do make errors. I'll even google the phone number/address because sometimes that helps {you'll find addresses linked to freight forwarding companies, and that to me is an automatic kill order}
2. If billing doesn't match shipping, I do all of the above first and make the decision to authorize/capture based on my own 'subjective' feel AFTER 12 hours has passed. <-this snares most stolen cards because most people DO report their cards stolen.

Last year I got tagged for ONE fraudulent order and frankly I should've known better.

[Dinghus]

It is not just the banks, but Authorize.net sucks too. I heard so many complaints about them and had so many complaints about them myself (customers) that I actually switched to PayPal Pro. Tho not perfect and some people laugh, they are actually far more flexible and much better overall than companies like Authorize.net.

If you get a programmer who knows the PPP API, you can get it to work the way YOU want it to, and not hear "that's just the way it is, kid, now go away, you bother me" from Authorize.net.

[wdillsmith]

I'm not sure if I should be comforted that it's not just me, or more annoyed because it's not just me...

To answer some of the questions in posts above:

Doing a Capture instead of Auth & Capture at the time of entry will not help because the goods may not be shipping right away, and charging the customer at order time would be a violation of the card terms of service. Also, if the transaction is declined for AVS, regardless of which method I use, it will be declined and can only be captured manually, at authorize.net.

No, I don't have time to manually force capture AVS errors, as they occur all day every day.

We are a gift company, so the billing address and shipping address almost never match, because most of our customers are sending gifts to other people. Thus I cannot rely on that check for fraud, but we do employ other methods that are pretty effective, although they are time consuming as they all involve human intervention.

The ones that seem to get hurt the worst are the debit card holders, as the withdrawals are immediate. Did I mention there is also no way to determine ahead of time whether a card is debit or credit? I'm looking at a bunch of workarounds, which vary from really stinky to just a faint odor, but I'm not happy about any of them.

Thanks for the feedback though, as at least now I know to move ahead with my workarounds.

Bill

[msinfo]

You can turn off the switch in Authorize.net to decline transactions where the AVS do not match. That way the system will notify you that the AVS did not match but also aprove the transaction.

So you can in fact process sales without AVS matching and that's not a problem (many merchants do it).

What they do is call the customer directly if the transaction looks suspicious.

If you would like to discuss this via email contact me any time at msinfo@merchantseek.com

Joe

[crankydave]

Originally Posted by msinfo

You can turn off the switch in Authorize.net to decline transactions where the AVS do not match. That way the system will notify you that the AVS did not match but also aprove the transaction.

So you can in fact process sales without AVS matching and that's not a problem (many merchants do it).

What they do is call the customer directly if the transaction looks suspicious.

If you would like to discuss this via email contact me any time at msinfo@merchantseek.com

Joe

And you get to pay your discount/transactions fees on all bank approved transactions. Not to mention far more time consuming. Not a viable option as I see it. Unless of course you want to pay those fees and potential loses for me.

The banks have the needed info. If their interest is in protecting their cardholders they should be verifying it PRIOR to issuing an approval/authorization. Their interest is not in protecting their cardholders from potential fraud. They wash their hands of any responsibility and drop it straight into the laps of merchants.

Merchants who have to deal daily with their refusal to protect THEIR cardholders from potential misuse of a credit card.

Dave

[clumberman]

Originally Posted by cw1865

1. If the order volume is such that manually running the orders makes sense, do that.
2. If the order volume exceeds this, perhaps the system can do an authorize and capture (instead of simply authorizing)

Personally, I manually do it and frankly its the favorite part of my day.

1. If billing matches shipping, I run the transaction, if AVS is in any way negative, I'm looking at IP Address, if area code for zip code is correct and things of that nature. Even aside from fraud, this also helps to prevent shipping to an incorrect address, you'd think people would type their addresses correctly all the time, but believe it or not they do make errors. I'll even google the phone number/address because sometimes that helps {you'll find addresses linked to freight forwarding companies, and that to me is an automatic kill order}
2. If billing doesn't match shipping, I do all of the above first and make the decision to authorize/capture based on my own 'subjective' feel AFTER 12 hours has passed. <-this snares most stolen cards because most people DO report their cards stolen.

Last year I got tagged for ONE fraudulent order and frankly I should've known better.

This is the way we do it, too. Manually capture the information, call our CS line, get the number of the issuing bank, speak to a live person whenever possible to validate the information, then process the transaction, or not. We've also gotten pretty good at guessing if an order is fake or not, before we even call to try and verify anything. We also give card users a financial disincentive to using a card by having a 3% Handling Fee to manually process the transaction. On a $30k watch, that's $900 of disincentive; not small potatoes! Worst case scenario, which we've had happen, is for someone's account to be hacked and all the info changed, including addresses. You get a clean and validated transaction...until the real owner files the chargeback 45 days later. You're out the product =and= the cash. As usual, the bank claims no responsibility, even though =their= system was breached. We had this happen one time on a, for us, fairly small transaction; total loss was about $13k. Next time it happens, I think we'll sue the card holder themselves for not protecting their card information better thus allowing the hack.

Lyle Knox
FeelGoodWatches.com

[Bronksknifeworks]

Do your self a big favor and do not use Authorize dot net to transact your cards. Eventually you will wind up with problems and it will cost you.

In there very own words to me during a phone conversation after they conducted several fraudulent credit card transactions that cost me dearly in fees etc.

I quote "You don't understand, we don't authorize credit card transaction, we only transport numbers from one place to another. You have to check the transaction, it is you responsibility to verify whether or not the card is valid."

One of the fraudulent cards that they had authorized was used with a 00/00 expiration date.

Always remember that banks, governments and corporations do not have your interest at heart.

[danlefree]

You need a zero-dollar authorization with AVS - Authorize.net may not support this, but it couldn't hurt to ask.

A large company I worked for in the past (very high volume, high fraud incidence) was able to find a processor and work out a zero dollar authorization w/capture.

I do not have the name of the processor or any of the details of the technical implementation though I can say that this solution does exist.

Try asking around with different processors.

[msinfo]

Well it is a very viable option. As someone that works in this industry 24 hours a day 7 days a week I can say that I've seen so many merchant processing scenarios that I can't even begin to go into all.

But what I can say is that small-mid sized merchants that don't want to lose money do not reject cards just because an address doesn't match. What they do is accept the card and call the client afterwards to verify the info. If they cannot verify or get the customer on the phone they can always go into the Virtual Terminal to void the transaction (that's what virtual terminals are for).

The address could not match for trival reasons such as the bank/card issuer somehow losing the primary address on file and the customer may have to call them to re-add that number.

As for higher fees you can always negotiate a lower non-qualified rate because the transaction will fall under non-qualified as it's risker, but what's worse, paying 0.75-1.00 percentage ponits higher or losing the sale completely?

We can get into the "banks are bad, merchants are good" argument by talking about the responsibility that the banks do not want to take on, but I can assure you that Visa/MC and acquiring banks do already take on ALOT in the area of combatting fraud.

Furthermore yes the customer's bank has the information needed but they rely on the customer to enter that information for verification purposes.

If you would like to discuss this via email contact me any time at msinfo@merchantseek.com

Joe
Merchantseek.com
<please add your link to your signature>

[maxsun]

We have a "canned" message we reuse for the problem--it's that common. We even have people submit the same credit card transaction three times, then get hysterical calls about how we "charged them 3 times". (We never took a red cent).

I will say--I've never heard of bank taking more than about 3 business days to return the money to the account. So 30 days sounded high to me...

But you're right--banks have a TOTAL monopoly--with no risk. We merchants accept it all--it's terribly unfair. That said, most customers are so honest it restores my faith in humankind.

I've added GOOGLE Checkout--and so far, really like them. They accept the loss if they "verify" their shipping address and their fees are much more reasonable than anyone else. Perhaps it's because they want to compete with PayPal, etc. But so far, wish ALL of my customers would pay via Google! Lol

MaxSun

[msinfo]

Originally Posted by danlefree

You need a zero-dollar authorization with AVS - Authorize.net may not support this, but it couldn't hurt to ask.

A large company I worked for in the past (very high volume, high fraud incidence) was able to find a processor and work out a zero dollar authorization w/capture.

I do not have the name of the processor or any of the details of the technical implementation though I can say that this solution does exist.

Try asking around with different processors.

A 0 cent authorization is only possible if you're large and the processor can see where they can make it elsewhere. If you're small without any history this is almost impossible. Authorizations can be lowered but rarely waived unless you're very large with either deep pockets, the willingness to pay for it elsewhere, or lots of processing history (usually 7 figures at least).

It's a numbers game when you talk about having fees completely waived as merchant providers do have to pay fees for each transaction.

But sure, a search is always worth it.

[maxsun]

What's up with WebproWorld???

Haven't been here in months and there are TONS OF ADS!!! Lord! And my inbox is full of emails from porn sites. What????

Times are tough--but come on guys...

[starbuck]

I feel I was overharged for 1 year -They keep taking $$$out of my acct.,, and would never help me

Isay get another company

Cost me $500-$1000-$$$$$$$$$$$$$$$$$$$

[crankydave]

AFAIC that's nonsense msinfo. Thats nothing more than an excuse for the way way banks operate and who they hold resonsible for the way they operate. It's not themselves.

Banks don't "eat" fraudulent transactions they approve. They charge the merchant AND charge them again for refunds and chargebacks whether or not they're legitimate.

As so far as voiding a transaction, only prior to settlement. You got time to scan every single transaction, and call customers, for every single transaction prior to settlement? Don't tell me yes.

Dave

[msinfo]

Crankydave I won't argue with you about this. I can simply say I've been in this industry for 11 years, have personally integrated with over 25 payment gateways, have certified with several direct processors, have worked as a developer for a payment software company, and have done merchant consulting and account setups. Just as I can't measure up to you in blog posts, forums and probably site placement I feel pretty confident that I know what I'm talkinga bout here.

For the record credit card processors/providers CAN eat fines by Visa/MC as they build a portfolio of more fraudulent merchants than Visa/MC thinks they should. If a provider takes on a merchant that processes a hefty amount of stolen cards, trust me, they are subject to hefty fines in the thousands. The processor can try to pass the fines down to the merchant but if the merchant runs off, then who pays? The merchant bank and provider pays that's who

Furthermore each Chargeback is assigned a person that much go through and investigate the matter and communicate back and forth to the issuer/customer. How do you think these people are employed?? That stuff isn't free.

And as for "scanning" for each transaction that depends on the Virtual Terminal that you're using. I know for a fact that most of the gateway's that I've programmed into had Virtual Terminals that allowed you to simply search and filter through transactions by searching via last name, authorization code, etc. If Authorize.net doesn't have this capability to search and narrow down transaction results tell me as I can recommend a few others.

These are factual statements. And if you show me proof that my statements are "nonsense" I'm open to hear your evidence.

I'm only offering suggestions on how this merchant can still accept cards and not losing money by trying to "protest the system" here.

Not all merchants are honest guys that mean well, if it weren't for the scum out there using stolen cards and trying to open accounts with false bank account information and stolen Social Security Numbers these rules would be much more flexible I'll assure you.

[wdillsmith]

I tried a 0 dollar transaction at authorize using the virtual terminal. It got rejected because the amount entered was not valid. I did successfully put through a 1 cent transaction using my own credit card though (there goes another 27 cents...).

There is no "AVS" only transaction either, at least not with Authorize.

If I turn off AVS, not only will my fraud go way up, but the transaction fee per charge also goes up. This is because without AVS, my transactions get charged the "non-qualified" rate, which has a much higher fee.

The money does typically get put back in the customers account with 2-3 business days, but as I mentioned, banks are hitting customers with overdraft charges too now. At the very least, I get phone calls from angry or suspicious customers thinking we are one of those shady businesses. At the worst, well, it can get pretty ugly.

If there are other payment gateways out there that do a better job, I'd be glad to hear about them. Other than this problem, I have found authorize.net to actually be pretty good. They have good APIs and reports and we are fully integrated with them, which makes things generally smooth. I can also have users with different roles, and change settings on the fly. Integrating payment gateways in real time is not a trivial task, and switching is probably more painful than the pain I am dealing with now regarding AVS.

[crankydave]

msinfo... I'm not at all trying to suggest you don't know what you're talking about. But having myself spent almost 30 years in card present and card not present environments, and having worked with a multitude of banks and processors, I've a bit of experience as well.

Granted you were/are most definitely trying to assist the OP with options.

Also granted, as merchants "run off" someone gets stuck. But that sums up my point. It's the merchants who are held responsible from the very beginning on only in a situation where there's no merchant does someone else have to pony up. That's just flat ass wrong.

Banks have this information at their fingertips. Very easy for them to verify. They don't and won't. It all requires merchants to spend more man hours, more resources, more money, to do what they won't. Simple enough concept in my mind. Take some initiative, take some responsibility, for the transactions they approve. They have all the information. Merchants don't. Yet all they verify is CC#, expiry date, available credit, and (when applicable) CVV2. That's it.

As so far as your picture of the Chargeback process, that's simply not the case. Many banks have online forms that can be filled out by the cardholder that get auto processed. They verify almost nothing. Name me one bank that verifies whether or not a merchant even has a return policy or whether or not they have an "all sales final" policy before issuing a chargeback. They don't.

When a chargeback to merchant occurs, that turns out to be incorrect, name me one bank that reverses the fees associated with that chargeback. They don't.

Banks don't verify squat unless they're issuing a card. I'm not suggesting that merchants be held blameless or should have no responsibility but compared to what banks actually verify it's sinfull.

You can scan all the transactions you want, but once submitted for settlement you cannot void them anywhere. Please name a processor that allows you to void a transaction after being settled. You can't.

Dave

[crankydave]

Originally Posted by wdillsmith

The money does typically get put back in the customers account with 2-3 business days, but as I mentioned, banks are hitting customers with overdraft charges too now. At the very least, I get phone calls from angry or suspicious customers thinking we are one of those shady businesses. At the worst, well, it can get pretty ugly.

This is the hardest part about it all. The phone calls and emails from angry customers. All I can share is how we handle them. With the truth. That we are, first and foremost, trying to protect them from the potential misuse of their card. It's rather humbling to have to apologize profusely for their inconvenience when it's no fault of your own.

Gonna drop you a PM.

Dave

[msinfo]

Originally Posted by crankydave

msinfo... I'm not at all trying to suggest you don't know what you're talking about. But having myself spent almost 30 years in card present and card not present environments, and having worked with a multitude of banks and processors, I've a bit of experience as well.

Granted you were/are most definitely trying to assist the OP with options.

Also granted, as merchants "run off" someone gets stuck. But that sums up my point. It's the merchants who are held responsible from the very beginning on only in a situation where there's no merchant does someone else have to pony up. That's just flat ass wrong.

Banks have this information at their fingertips. Very easy for them to verify. They don't and won't. It all requires merchants to spend more man hours, more resources, more money, to do what they won't. Simple enough concept in my mind. Take some initiative, take some responsibility, for the transactions they approve. They have all the information. Merchants don't. Yet all they verify is CC#, expiry date, available credit, and (when applicable) CVV2. That's it.

As so far as your picture of the Chargeback process, that's simply not the case. Many banks have online forms that can be filled out by the cardholder that get auto processed. They verify almost nothing. Name me one bank that verifies whether or not a merchant even has a return policy or whether or not they have an "all sales final" policy before issuing a chargeback. They don't.

When a chargeback to merchant occurs, that turns out to be incorrect, name me one bank that reverses the fees associated with that chargeback. They don't.

Banks don't verify squat unless they're issuing a card. I'm not suggesting that merchants be held blameless or should have no responsibility but compared to what banks actually verify it's sinfull.

You can scan all the transactions you want, but once submitted for settlement you cannot void them anywhere. Please name a processor that allows you to void a transaction after being settled. You can't.

Dave

One bank that verifies whether or not a merchant has a return policy? How about 3:

1: Chase
2: ECHO
3. Nationwide Payments.

I'm sure there are more.

As for voiding a transaction that has been settled where did I say anything about a transaction being voided after being settled? You cannot void a transaction that has been settled but you can perform a refund.

Also, most merchant accounts allow online merchants to MANUAL Settle, this way you can be sure that the batch checks out before you settle it.

I'm sorry but you really don't sound as if you've spent much time in the recent payments circle. You say that I'm "flat ass wrong". Well here's a simple enough example:

- A merchant applies for an account, without the best intentions, they are somehow approved by the bank's underwriting
- The merchant gets access to stolen card information and manually enters that info themselves via either their Virtual Terminal or Web Interface. Let's say $500
- The real customer, back somewhere in the middle of the country sees that their card was used fraudulently
- The customer disputes that transaction with their credit card company
- The merchant provider/processor attempts to tell the merchant that they have to refund this customer because the customer charged this transaction back with their credit card company and the merchant has no proof of customer authorization
- The problem is that the merchant had bad intentions to begin with and they're long gone.
- Guess who has to refund the customer that money because the merchant is no where to be found?? You guessed it! The merchant processor and processing bank does!!

Now you asked for a scenario and I gave you one...

Again I'm speaking factually here. I'm not sure where you're getting your info but I hope I'm shedding some light for you.

[crankydave]

Originally Posted by msinfo

One bank that verifies whether or not a merchant has a return policy? How about 3:

1: Chase
2: ECHO
3. Nationwide Payments.

I can tell you for a fact that Chase does not when it comes to disputes. One of my sites uses them so I know first hand they do not. ECHO does not either when it comes to a disputed transaction. Neither does Nationwide after the fact.

Originally Posted by msinfo

As for voiding a transaction that has been settled where did I say anything about a transaction being voided after being settled? You cannot void a transaction that has been settled but you can perform a refund.

No kidding. At which point the merchant has paid fees for your so called "viable" option. Not to mention fees for the refund. This was my point to beigin with. Merchant pays fees for your "viable" option and the bank skates. THAT'S what makes it a non-viable option IMO.

Originally Posted by msinfo

Also, most merchant accounts allow online merchants to MANUAL Settle, this way you can be sure that the batch checks out before you settle it.

Which completely and utterly defeats real time processing. THAT is the purpose intended when it comes to CC's. You make nothing but excuses for the way banks handle transactions whether or not they are card present. Not to mention that this in no way addresses the bank issuing ann approval to begin with.

Pray tell me, what does a bank verify PRIOR to issuing an approval that I've colored or mistated in any way?

Originally Posted by msinfo

I'm sorry but you really don't sound as if you've spent much time in the recent payments circle. You say that I'm "flat ass wrong". Well here's a simple enough example:

- A merchant applies for an account, without the best intentions, they are somehow approved by the bank's underwriting
- The merchant gets access to stolen card information and manually enters that info themselves via either their Virtual Terminal or Web Interface. Let's say $500
- The real customer, back somewhere in the middle of the country sees that their card was used fraudulently
- The customer disputes that transaction with their credit card company
- The merchant provider/processor attempts to tell the merchant that they have to refund this customer because the customer charged this transaction back with their credit card company and the merchant has no proof of customer authorization
- The problem is that the merchant had bad intentions to begin with and they're long gone.
- Guess who has to refund the customer that money because the merchant is no where to be found?? You guessed it! The merchant processor and processing bank does!!

What a load of BS spin control.

When was the last time you spent some time in the "real world" when it comes to what merchants and consumers face? Clearly by your posts it's not been recently.

When was the last time you had to field a phone call from an irrate consumer because one of your sites declined a transaction because the billing information provided failed an AVS check even though their bank approved it? Information the bank has but will not verify. Clearly you haven't done this in current "payment circle".

When was the last time as a consumer you had a transaction declined by a website only to find out that your bank has held those funds against you and you don't know why? Only to have your bank tell you have to contact the merchant? Clearly you've not encountered this in the current "payment circle".

Your example is crap. It's not what real world merchants deal with every single day because banks refuse to. It's not what costs real world merchants money every day because banks refuse to. It's not what costs consumers more money every day because banks refuse to. Join the real world world instead of making excuses.

Originally Posted by msinfo

Now you asked for a scenario and I gave you one...

Again I'm speaking factually here. I'm not sure where you're getting your info but I hope I'm shedding some light for you.

You provided an excuse.

I hope I'm shedding a bit of light on all the merchants and consumers that have to deal with this in the real world every day, that get needlessly cost money and resources every day, and not defending and making excuses for the actual problem.

Dave

[msinfo]

Ok I guess a part of your "brand" is to be this online tough guy that takes us "bad guys" to court via the web and sheds light on the truth? Correct?

Well you tell me that I'm not in touch with what every day merchants are doing, well how many thousands of different merchants/businesses have you helped setup and manage accounts yourself?? In reading your posts I'm seeing that this is just a way for you to vent frustrations with the provider/bankcard industry. But you have you real solutions to help merchants on here. When I post a solution you come back with some childish rant, but again, I guess that's a part of your "brand" right as the "Cranky Guy" that takes no crap.

Well I'm actually beginning to feel sorry for anyone that listens to your payment industry advice on this forum. Because what advice do you have? None at all apparrantly!!

You even call batch settlement NON REAL TIME??? Wow, you're so mis informed. Do you realize that all credit card transactions are processed into a batch that must be settled at the end of the day?? The only difference between Manual batch settlement and Automatic batch settlement is that with Autosettle the gateway settles the batch for the merchant at the end of the day!! But it's the same system, it's just that with a Manual batch settlement the merchant is doing it himself instead of the gateway. You do realize that ALL credit card transactions must be settled in a batch correct (Whether "real-time" or non-real-time). I don't care how many rants you post on here you're clearly mis informed, and anyone that listens to what you're saying is going to find themselves in even worse of a situation I swear.

I even gave you the example that you asked for you and you called in BS Spin?? This is getting funnier by the minute.

You clearly have no idea what you're talking about here. Stop wasting so much time posting on topics that you have no knowledge of. Your answer to everything is that banks are bad, my answers are much more practical and actually explain what's going on. Why don't you go back and read everything you've posted.

And I hope I'm shedding light on just what a childish and mis-informed moderator this forum has. I won't waste my time on this topic any further as it's unfortunate that someone can come with good intentions and end up dealing with a kid with nothing better to do and that's too ignorant to learn how this stuff actually works.

I can't believe that with all your senseless comments about the industry that I've corrected you on that you still have the nerve to tell me that I don't deal with real merchant's every day??? I would bet that I deal and have dealt with far more merchants looking to accept and integrate electronic payments than you.

I've done provider training at merchant banks and have actual formal knowledge in this industry, and have provided nothing but facts on my posts, while you rant in what appears to be an effort to further promote your "Cranky Dave" brand...

Cranky Dave: the guy that is an expert in everything from Bailouts, to Tomatos, to Pickle Juice, to Westmont Ho-Hum, to Coke, to Pickles, and now he's an expert in the Merchant Account industry too! (I'm not making this up). He's even more of an expert than someone who has advised thousands of merchants, have held real jobs in the field and have trained in a merchant acquiring bank.

Who looks more like they're BSing to you?

AND TO CLARIFY THE AVS NOT GOING THROUGH BUT CARD BEING CHARGED ISSUE:
If the your gateway is setup to not approve transactions where the AVS is not approved the card amount will be reserved on the bank end until the batch is settled and up around 2 days after but the money will not change hands because the card that did not pass the AVS check may pass the Authorized's funds check but it is not put into the merchant's batch for actual transfer - so though it appears that the customer is actually being charged they're not because the gateway saw that the AVS was not verified and it did not put that credit card into the batch which prevents that card from actually having funds taken from it's customer and given to the merchant. The purpose of batch settlement (Whether it's manual or automatic) is to actually move funds from the customer's account to the merchant's bank account.

So if the AVS was not passed and the gateway was set to not settle cards that did not pass the AVS check the customer will see their held funds released in 2-3 days and the merchant will not actually get the money. This is how settlement works, they're not actually being "charged" unless the card was settled at the end of day batch by the merchant.

[deepsand]

Originally Posted by wdillsmith

... What we end up with are ... completed sales with duplicate transactions.

Why are you having customers initiate a new transaction, rather than simply executing a Capture, using the Authorization originally received, once the address is resolved?

If it's the case that the volume of such is too high, then you need to face the fact that you've a big problem with customers entering bad address information, and look for ways to make your site more prominently display the requirement that the proper Billing/Statement Address be provided.

If all efforts in this regard fail, or have failed, then recognize that any undesirable consequences suffered by the customers are of their own making, rather than look to your card processor and/or the banks for scapegoats.

[deepsand]

Originally Posted by Dinghus

It is not just the banks, but Authorize.net sucks too. I heard so many complaints about them and had so many complaints about them myself (customers) that I actually switched to PayPal Pro..

PayPal's "address verification" is a joke. They've even "verified" non-existent addresses!

[deepsand]

Originally Posted by msinfo

You can turn off the switch in Authorize.net to decline transactions where the AVS do not match. That way the system will notify you that the AVS did not match but also aprove the transaction.

Originally Posted by crankydave

And you get to pay your discount/transactions fees on all bank approved transactions.

Not if it's an Authorize only transaction; there's no juice until the Capture is effected.

Originally Posted by crankydave

The banks have the needed info. If their interest is in protecting their cardholders they should be verifying it PRIOR to issuing an approval/authorization.

Still leads to a 2-step solution.

If the Authorization is not completed unless a successful AVS response is first obtained, and the latter fails, then a 2nd attempt is required after such problem is resolved.

[deepsand]

Originally Posted by Bronksknifeworks

Do your self a big favor and do not use Authorize dot net to transact your cards. Eventually you will wind up with problems and it will cost you.

In there very own words to me during a phone conversation after they conducted several fraudulent credit card transactions that cost me dearly in fees etc.

I quote "You don't understand, we don't authorize credit card transaction, we only transport numbers from one place to another. You have to check the transaction, it is you responsibility to verify whether or not the card is valid."

In this regard, it is the case that A.net is both correct, and no different from any other card processor in this regard.

Millions of $$$ in transactions, and no cause for complaint, other than a minor technical problem re. the automatic generation of confirming e-mails not being produced under a certain specific condition.

A.net is, in fact, one of the best processors to be had.

[deepsand]

Originally Posted by crankydave

IWhich completely and utterly defeats real time processing. THAT is the purpose intended when it comes to CC's.

Sorry, Dave, but there's no such thing as "real time processing" when it comes to the remote use of credit/debit cards.

Only the Authorization occurs immediately; all Captures, no matter how collected, are Batch Processed, and then distributed to the corresponding banks for their
(batch) processing.

This is why transaction generally take several days to Post to the card holder's accounts; and, where shown on the statement, the Transaction & Posts Dates are different.

[crankydave]

Originally Posted by msinfo

You even call batch settlement NON REAL TIME??? Wow, you're so mis informed. Do you realize that all credit card transactions are processed into a batch that must be settled at the end of the day?? The only difference between Manual batch settlement and Automatic batch settlement is that with Autosettle the gateway settles the batch for the merchant at the end of the day!! But it's the same system, it's just that with a Manual batch settlement the merchant is doing it himself instead of the gateway. You do realize that ALL credit card transactions must be settled in a batch correct (Whether "real-time" or non-real-time). I don't care how many rants you post on here you're clearly mis informed, and anyone that listens to what you're saying is going to find themselves in even worse of a situation I swear.

Is msinfo short for misinformation?

Transactions do not have to be settled before the end of the day. They can be settled days later if the merchant likes.

Originally Posted by msinfo

I even gave you the example that you asked for you and you called in BS Spin?? This is getting funnier by the minute.

That's exactly what it was. Your so called example in no way whatsoever addressed how a bank handles a transaction(s). That is what is being discussed in this thread. Not the application process for a merchant. The application process has nothing to with how transactions are processed.

Originally Posted by msinfo

And I hope I'm shedding light on just what a childish and mis-informed moderator this forum has. I won't waste my time on this topic any further as it's unfortunate that someone can come with good intentions and end up dealing with a kid with nothing better to do and that's too ignorant to learn how this stuff actually works.

I can't believe that with all your senseless comments about the industry that I've corrected you on that you still have the nerve to tell me that I don't deal with real merchant's every day??? I would bet that I deal and have dealt with far more merchants looking to accept and integrate electronic payments than you.

I've done provider training at merchant banks and have actual formal knowledge in this industry, and have provided nothing but facts on my posts, while you rant in what appears to be an effort to further promote your "Cranky Dave" brand...

You've corrected me? There's not one iota of factual information that you have or are able to "correct". You on the other hand have continued to post factually incorrect information. The latest being that transactions must be settled by the end of the day.

And a kid? Don't make me laugh.

Originally Posted by msinfo

AND TO CLARIFY THE AVS NOT GOING THROUGH BUT CARD BEING CHARGED ISSUE:
If the your gateway is setup to not approve transactions where the AVS is not approved the card amount will be reserved on the bank end until the batch is settled and up around 2 days after but the money will not change hands because the card that did not pass the AVS check may pass the Authorized's funds check but it is not put into the merchant's batch for actual transfer - so though it appears that the customer is actually being charged they're not because the gateway saw that the AVS was not verified and it did not put that credit card into the batch which prevents that card from actually having funds taken from it's customer and given to the merchant. The purpose of batch settlement (Whether it's manual or automatic) is to actually move funds from the customer's account to the merchant's bank account.

wow... First off, the consumer doesn't know that the funds have not changed hands. THAT'S part of the problem the OP is referring to. The funds are held and the consumer is given every indication by the bank that the merchant has been paid. THAT'S the other part of the problem.

And what happens when the consumer calls their bank? They say call the merchant.

This is the real world msinfo. This is what happens everyday. Not the rosy picture and so called "solutions" you portray.

Originally Posted by msinfo

So if the AVS was not passed and the gateway was set to not settle cards that did not pass the AVS check the customer will see their held funds released in 2-3 days and the merchant will not actually get the money. This is how settlement works, they're not actually being "charged" unless the card was settled at the end of day batch by the merchant.

Even more misinformation. If funds were only held for 2-3 days it wouldn't be as big an issue. An issue but not as big. They hold funds for up to 30 days. This is fact.

If you wish to discuss fact, my suggestion would be to post fact.

Dave

[wdillsmith]

Originally Posted by deepsand

Why are you having customers initiate a new transaction, rather than simply executing a Capture, using the Authorization originally received, once the address is resolved?

If it's the case that the volume of such is too high, then you need to face the fact that you've a big problem with customers entering bad address information, and look for ways to make your site more prominently display the requirement that the proper Billing/Statement Address be provided.

If all efforts in this regard fail, or have failed, then recognize that any undesirable consequences suffered by the customers are of their own making, rather than look to your card processor and/or the banks for scapegoats.

I think you've missed my point. Why can't the banks check the AVS before they try the authorization? Saying "That's the way it is" may be true, but in my opinion that means they are doing it backwards. I would not call that looking for scapegoats, I call that doing your job correctly. This entire thread would be unnecessary if I had the option at least to do it that way.

As an earlier post pointed out, no money changes hands when an AVS fails. Yet banks are actively charging their customers overdraft fees on these imaginary charges. This has happened more than once and I've even talked to a couple of banks myself about the problem. This is unfair to their customers and to our company.

[crankydave]

Originally Posted by deepsand

Not if it's an Authorize only transaction; there's no juice until the Capture is effected.

Granted but my reply was to the suggestion that the AVS be turned off so that transactions would never be declined by the AVS. Turning off the AVS is not a viable solution for a multitude of reasons.

Originally Posted by deepsand

Still leads to a 2-step solution.

If the Authorization is not completed unless a successful AVS response is first obtained, and the latter fails, then a 2nd attempt is required after such problem is resolved.

It's a 2 step solution now. The solution would be for the industry that has the information to verify it. That would be the banks.

Dave

[crankydave]

Originally Posted by deepsand

Sorry, Dave, but there's no such thing as "real time processing" when it comes to the remote use of credit/debit cards.

Only the Authorization occurs immediately; all Captures, no matter how collected, are Batch Processed, and then distributed to the corresponding banks for their
(batch) processing.

This is why transaction generally take several days to Post to the card holder's accounts; and, where shown on the statement, the Transaction & Posts Dates are different.

Deepsand... The transaction shows up on a cardholders account from the moment it is authorized. They can go online and see it. Scenerio... Cardholder makes a purchase that is declined by the AVS. They go online and can see that bank has added that transaction to their statement. They call the merchant furious because they are given every indication that the merchant has been paid.

It left up to the merchant to try and explain to a cardholder what happened and why.

This is the crux of the problem and is exactly what the OP is referring to. All a bank considers when issuing an authorization is the validity of the CC#, the expiration date, available credit, and where applicable the CCV2 code and nothing more.

The merchant is required to verify far more in order to protect themselves and cardholders from potential fraud AND this is done after the fact. After the bank has already authorized the transaction and AFTER having held those funds aside.

How backwards is that?!?!

Dave

[Kentj]

The credit card companies seem to rank internet merchants as nothing more than a bothersome gnat around their faces. With the rules that internet merchants must face, it is in the credit card companies best interest to keep fraud going. See my story at Discount Leather Mart policy pages re security at the bottom of the page.

As far as the gentleman from Merchant Seek: I had to fill out tons of forms, have a complete credit check and almost provide a DNA check in order to get my merchant account (s) How is that a merchant account is handed out to an online merchant that wants to run fraudulent transactions? How can this happen?

[deepsand]

Originally Posted by wdillsmith

Why can't the banks check the AVS before they try the authorization?

Actually, both are done independently. As noted in my earlier post to CD, making the one dependent on the other ...

Still leads to a 2-step solution.

If the Authorization is not completed unless a successful AVS response is first obtained, and the latter fails, then a 2nd attempt is required after such problem is resolved

More importantly, the issuing/servicing bank has no way of knowing whether or not AVS is required for a given transaction. That is why control over such is placed in the hands of the merchant.

[deepsand]

Originally Posted by crankydave

Deepsand... The transaction shows up on a cardholders account from the moment it is authorized. They can go online and see it. Scenerio... Cardholder makes a purchase that is declined by the AVS. They go online and can see that bank has added that transaction to their statement.

The only thing that changes in real time is their funds availability. Some card servicers do separately display the total dollar amount of holds; ditto for their IVR systems.

The actual transactions are not visible on-line unless and until 1) the transaction has been Captured; 2) the Batch that that Capture is part of has been Settled; and, 3) that Settled transaction has been received and posted by the card servicer.

[deepsand]

Originally Posted by crankydave

All a bank considers when issuing an authorization is the validity of the CC#, the expiration date, available credit, and where applicable the CCV2 code and nothing more.

The merchant is required to verify far more in order to protect themselves and cardholders from potential fraud AND this is done after the fact. After the bank has already authorized the transaction and AFTER having held those funds aside.

Given that there are multiple conditions that must be met in order to successfully reach the Capture stage, there are but 2 general approaches available :

1) Process each data element or element group sequentially,halting upon the 1st error; or.

2) To the extent possible, process in parallel & identify all errors detected.

The present approach employs the 2nd, providing both for funds having been temporarily sequestered for the use of the merchant as well as affording the merchant discretionary authority as to how to proceed under various error conditions.

The approach that you seem to advocate, i.e. no. 1, would remove all discretionary powers from the merchant, as well as requiring that errors be resolved sequentially in multiple steps. I doubt that most merchants and card holders would find this preferable.

[deepsand]

Originally Posted by Kentj

How is that a merchant account is handed out to an online merchant that wants to run fraudulent transactions? How can this happen?

Just as there are mortgage brokers who game the system so as to earn their commissions, etal., so too with merchant accounts ISOs.

[crankydave]

Originally Posted by deepsand

The only thing that changes in real time is their funds availability. Some card servicers do separately display the total dollar amount of holds; ditto for their IVR systems.

The actual transactions are not visible on-line unless and until 1) the transaction has been Captured; 2) the Batch that that Capture is part of has been Settled; and, 3) that Settled transaction has been received and posted by the card servicer.

That's really big thing deepsand. Funds available. And when they become unavailable in the event of an AVS decline. Up to 30 days.

As for your latter point. Not true. A transaction becomes visible right after authorization. I've not only fielded phone calls describing such, I've tested it with my own cards. All that has to happen is authorization and nothing more.

Dave

[deepsand]

Originally Posted by crankydave

That's really big thing deepsand. Funds available. And when they become available in the event of an AVS decline. Up to 30 days.

As for your latter point. Not true. A transaction becomes visible right after authorization. I've not only fielded phone calls describing such, I've tested it with my own cards. All that has to happen is authorization and nothing more.

Credit or Debit?

If Debit, processed as Credit or Debit? Card-in-hand or not? PIN or non-PIN?

[crankydave]

Originally Posted by deepsand

Given that there are multiple conditions that must be met in order to successfully reach the Capture stage, there are but 2 general approaches available :

1) Process each data element or element group sequentially,halting upon the 1st error; or.

2) To the extent possible, process in parallel & identify all errors detected.

The present approach employs the 2nd, providing both for funds having been temporarily sequestered for the use of the merchant as well as affording the merchant discretionary authority as to how to proceed under various error conditions.

The approach that you seem to advocate, i.e. no. 1, would remove all discretionary powers from the merchant, as well as requiring that errors be resolved sequentially in multiple steps. I doubt that most merchants and card holders would find this preferable.

Nope. Not at all. No reason banks cannot implement the very same process employed by processors. Save that they would have to assume some sort of responsibility.

My suggestion simply advocates neccessary verification before authorization. What is "required" for a merchant to verify in order to try and protect themselves and consumers is far more extensive than what a bank verfies for an authorization. You know that and I know that.

In the end, everybody wins.

Dave

[crankydave]

Originally Posted by deepsand

Credit or Debit?

If Debit, processed as Credit or Debit? Card-in-hand or not? PIN or non-PIN?

Credit. More than one bank and more than one type of card.

Dave

[deepsand]

Originally Posted by crankydave

Nope. Not at all. No reason banks cannot implement the very same process employed by processors.

Not sure what you mean by "same process employed by processors."

Originally Posted by crankydave

My suggestion simply advocates neccessary verification before authorization.

Still leads to additional, sequential steps. How would you propose to avoid such without parallel processing?

Originally Posted by crankydave

What is "required" for a merchant to verify in order to try and protect themselves and consumers is far more extensive than what a bank verfies for an authorization.

Requirements vary by merchant. It seems that you would subject all to same requirements & same procedures.

[deepsand]

Originally Posted by crankydave

Credit. More than one bank and more than one type of card.

Which banks?

What do you mean by "more than one type of card?"

[crankydave]

Originally Posted by deepsand

Which banks?

What do you mean by "more than one type of card?"

Wanna test it for yourself?

I'll PM you (or email if you prefer) details.

Depends upon whether or not you trust me. In return, I'll send you a bottle of my favorite Bloody Mary mix for doing so.

Dave

[deepsand]

Originally Posted by crankydave

Wanna test it for yourself?

As this does not well comport with my over 4 decades of experiences with personal credit card accts. & 9 years with merchant accts., you've sufficiently piqued my curiosity.

Originally Posted by crankydave

I'll PM you (or email if you prefer) details.

Given that I check my e-mail accounts the more frequently, and have, on ocassion, had problems with 404s in the PM center, I'll PM you a preferred e-mail address.

Originally Posted by crankydave

Depends upon whether or not you trust me. In return, I'll send you a bottle of my favorite Bloody Mary mix for doing so.

Not a problem; remember, I know where your tomato plants live.

[crankydave]

lol... Sent you an email

Dave

[ladraut]

This is amazing that so many think that authorize dot net is doing the authorization.

They are just the payment gateway between your shopping cart and the authorizing merchant bank.

[deepsand]

Originally Posted by crankydave

lol... Sent you an email

Dave

Got it.

It's been a herding cats day; and, tomorrow looks to be no better. May be Monday before I've time to address.

[crankydave]

Originally Posted by deepsand

Got it.

It's been a herding cats day; and, tomorrow looks to be no better. May be Monday before I've time to address.

No worries.

Dave