3 ms·

i've always found it to be profoundly messed up that address validation (AVS) and security code validation (CVV/CSC) happen after the funds are authorized and h

i've always found it to be profoundly messed up that address validation (AVS) and security code validation (CVV/CSC) happen after the funds are authorized and held by the issuing bank. this means if you choose to decline transactions for cvv or avs reasons in your gateway settings, those funds are still actually held by the customer's bank as pending for ~24h, preventing them from trying the auth again if it puts them over their credit limit. the only way to release them is for the merchant to call the customer's bank and provide the, cc number and auth code. we've had to leave these "security" settings off in our payment gateway and just assess the processor codes ourselves. then manually call the bank if there are mismatches. it's a massive pain in the ass and pretty much a neccessity if your avg order is hundreds of dollars. >:(

jacob019 10y ago
We wrote our own system that preauths to get AVS, mandates a match to proceed or automatically voids the auth. You wouldn't believe his many people don't seem to know their own billing address. Customers get frustrated about the strict enforcement but we've only ever had one or two complaints about held funds. We just explain that those pending charges will fall off in 24 hrs, and they accept. Frankly, if the charge risks putting the customer over their limit, then it might not be such a good idea to deal with those customers. The cheapest customers are the most trouble and carry a higher incidence of returns fraud, fraudulent chargebacks, etc.
leejo 10y ago
> i've always found it to be profoundly messed up that address validation (AVS) and security code validation (CVV/CSC) happen after the funds are authorized and held by the issuing bank. That's because the alternative is the acquiring/issuing bank doesn't immediately reflect the authorisation in the shadow balance and only deducts it once either a confirmation has been received or a certain amount of time has elapsed, and of course that leads to a very chatty protocol and race conditions. Not to mention that the systems on the backend side at the acquiring/issuing bank would have to put the parts together. My experience with writing integrations with acquiring banks was that you needed to issue a reversal to have the held funds actually removed from the shadow balance. But it didn't always work, something about the reversals having to be the next request immediately after the corresponding auth. Obviously this was a system not built to scale and the whole AVS/CVV was a bolt on. AVS is most interesting because (at least using APACS 70, not so much ISO 8583 depending on the acquirer/issuer) it only works on the address numerics and not the other chars. So when you input your street number and postcode (at least outside the US) you can put whatever you want in the form as long as numbers match, anything else is thrown away.
ryderm 10y ago
This isn't quite true. It is up to your issuer if they decide to approve the transaction despite failing AVS or CVV checks. Often they will decline the authorization, but depending on their risk signals, might decide to approve it. Then, the merchant (or the processor they are using) can decide if they want to let the transaction go through despite the failed checks, or call it a decline and reverse the authorization, which removes the pending charge. Crappy terminals might cause the pending authorization to sit there for 1-3 days by delaying or not sending the reversal, but in general that shouldn't be the case.
dlubarov 10y ago
> the only way to release them is for the merchant to call the customer's bank and provide the, cc number and auth code. Who is your payment processor? They should be voiding the auth after the AVS or CVV mismatch.

jacob019 10y ago

We wrote our own system that preauths to get AVS, mandates a match to proceed or automatically voids the auth. You wouldn't believe his many people don't seem to know their own billing address. Customers get frustrated about the strict enforcement but we've only ever had one or two complaints about held funds. We just explain that those pending charges will fall off in 24 hrs, and they accept. Frankly, if the charge risks putting the customer over their limit, then it might not be such a good idea to deal with those customers. The cheapest customers are the most trouble and carry a higher incidence of returns fraud, fraudulent chargebacks, etc.

leejo 10y ago

> i've always found it to be profoundly messed up that address validation (AVS) and security code validation (CVV/CSC) happen after the funds are authorized and held by the issuing bank. That's because the alternative is the acquiring/issuing bank doesn't immediately reflect the authorisation in the shadow balance and only deducts it once either a confirmation has been received or a certain amount of time has elapsed, and of course that leads to a very chatty protocol and race conditions. Not to mention that the systems on the backend side at the acquiring/issuing bank would have to put the parts together. My experience with writing integrations with acquiring banks was that you needed to issue a reversal to have the held funds actually removed from the shadow balance. But it didn't always work, something about the reversals having to be the next request immediately after the corresponding auth. Obviously this was a system not built to scale and the whole AVS/CVV was a bolt on. AVS is most interesting because (at least using APACS 70, not so much ISO 8583 depending on the acquirer/issuer) it only works on the address numerics and not the other chars. So when you input your street number and postcode (at least outside the US) you can put whatever you want in the form as long as numbers match, anything else is thrown away.

ryderm 10y ago

This isn't quite true. It is up to your issuer if they decide to approve the transaction despite failing AVS or CVV checks. Often they will decline the authorization, but depending on their risk signals, might decide to approve it. Then, the merchant (or the processor they are using) can decide if they want to let the transaction go through despite the failed checks, or call it a decline and reverse the authorization, which removes the pending charge. Crappy terminals might cause the pending authorization to sit there for 1-3 days by delaying or not sending the reversal, but in general that shouldn't be the case.

dlubarov 10y ago

> the only way to release them is for the merchant to call the customer's bank and provide the, cc number and auth code. Who is your payment processor? They should be voiding the auth after the AVS or CVV mismatch.