> They are insured against it, they will refund the money back and their risk analysis probably indicates that loosing all that money to fraud is cheaper than waiting and properly deploying and testing the solution.
This. Some behaviour i encountered by acquiring banks when working on backend software for interfacing with them:
- Authorising a transaction when they failed to contact the issuing bank, because the value of the transaction is lower than a certain threshold.
- Overloading fields in the APACS spec to get around 3D Secure / Verified By Visa, i.e. passing the cardholder straight through the process and then marking it as bypassed (a poorly implemented one factor auth becomes a "eh, this looks ok to me" zero factor auth by the issuing bank).
- Being sat in meetings where the max value of contactless transactions was explicitly stated as being that of a level that any contactless chargebacks were not defended because they're so low.
- Asking me to send PANs in clear text, split over two e-mails (no, i didn't).
Backend backing systems are horrible. Nobody really wants to work on them and they have so much legacy cruft that they're like concrete, so any change takes forever and carries massive amounts of dev/test/risk.
Even the seemingly sensible ones have major WTF's - One of the integrations i did at my previous job was interfacing to Amex's endpoint for online authorisations. HTTPS posts over the web, seems sensible enough right compared to APACS-70 over X.25? No, the ISO-8859-1 POST parameter values needed to be encoded as EBCDIC and then converted to hex (IIRC) before being sent.
Banks playing the chargeback cost balancing game is all well and good for them, but if you're living on the edge and experience fraud then this can lead to all sorts of financial problems.