I get a lot of questions from my clients about online credit card processing: how it works, how the fees are structured, and how to lower the fees. This whole system is very, very complex, and I’m not convinced that there is anyone in the world who really understands every aspect of it.
High level summary:
- You fill in a commerce payment form on a website, then click SUBMIT. (There are thousands web vendors who can provide custom or off-the-shelf web forms for this purpose.)
- Your payment info goes through a Payment Gateway (e.g., PayFlow Pro or Authorize.net) to the Processor of the Merchant’s Bank
- Next comes authorization. Depending on card type, this might come from the Processor or the card-issuing Bank. Bottom line: someone says ‘approved’ or ‘declined.’
- Approved transactions are then ‘cleared’ for settlement
- Settlement is when the money actually moves around. This is usually in a nightly batch but sometimes it is real-time (which can lead to reconciliation headaches for businesses as then the fees are often deducted per transaction as opposed to a separate charge by batch or time-period).
This is a highly simplified breakdown; the process varies depending on the vendors involved. (For example, some vendors can handle more than one step in this process.) There are industry professionals who spend all of their time, every day, thinking about credit card processing. I actually spoke to a ‘Durbin Amendment’ Specialist’ a few weeks ago. His entire job focuses on understanding the so-called Durbin Amendment (and the Durbin amendment’s associated scams) which is just one piece of the larger Dodd-Frank Wall Street Reform and Consumer Protection Act (effective 10/1/2011), which only impacts certain pieces of the huge card processing industry.
This complexity helps to explain why fees are so high. Every single ‘player’ in this system needs to get paid for doing their part. The more complexity, the higher the cost.
So how do you lower the cost of these fees?
- Talk to your current merchant bank. They might actually have some immediate ideas for you.
- Ask for and include CID/CSV on your payment transmissions, whenever feasible.
- Ask for and include Billing Address on your payment transmissions, whenever feasible (Note: some banks give a processing fee break for just providing zip code, so you can save your user some time by just asking for it.)
- Shop around for a new merchant bank, processor, or gateway. Everyone wants your business, and sometimes a ‘little guy’ can give you a better deal than a ‘big guy’. But beware! There are costs to making these changes, so be sure that the money you’d save in fees justifies the cost to make the change.
Has anyone stumbled upon good articles, diagrams, or explanations of this complex industry that are aimed at the novice as opposed to the expert? I’d love to see them.
There are certain tags that by default are enabled in ColdFusion that I am never going to use and are a security risk. With this in mind I wanted to disable these CF Tags in a ColdFusion enterprise environment.
We have done this before in the ColdFusion standard edition and it is quite straight forward. So I went ahead and enabled Sandbox Security in a specific CF instance. One of the differences in the Enterprise edition is that you can specify specific directories to define specific permissions. So you can have different permissions on different instances.
I added the directory of the site that I wanted to disable cfexecute and then disabled the cfexecute tag. I was prompted to restart the CF instance and then went to my site. I got an error. I went to CF administrator to change the settings back and it wouldn’t respond! What the…?
Having played around with the guts of ColdFusion and its settings, I knew that I could revert the Sandbox Security by changing the xml file. That file is called neo-security.xml in the \WEB-INF\cfusion\lib folder of the instance that I was updating.
So, what next?
We’ve talked about how we love Keepass and LastPass because they’re good for password management. Instead of using a manager, lots of people let their browsers save their passwords. Easy, right?
But, is this a good practice?
Not so much.
Lifehacker shows us why you should never do that. Here’s how a person can easily reveal your hidden passwords in any browser!
Once again, a password manager is a better way to store your passwords.
Do you have any stories about password protection you’d like to share?
Pardon me for being verbose here, but we need to talk. It’s about your passwords.
It’s official. There is no longer any excuse for any of us to not be using multi-factor authentication with our sensitive accounts. There is also no longer any excuse for any of us to not be using complex and unique passwords for every site we visit. None.
It’s all over the blogosphere. Everywhere. Online businesses and services are being compromised. Accounts are being stolen. It does not take a PhD to have a secure online identity, but sadly, some people still don’t take this seriously.
The resources are out there, and they’re mostly free. Yes, 100% gratis.
I’m going to talk about two components: password security, and multi-factor-authentication (MFA), (aka, two-step verification).
Any user input that is reflected back to users in a web application is a potential vector for cross-site scripting and similar code injection attacks by marauding nasties. One way to thwart these reprobates is to encode special characters in the user input before saving or displaying it. And in ColdFusion, xmlFormat is available to help with that.
It’s also good practice to enforce maxlengths on user input. But if we allow special characters and then sanitize them with xmlFormat, the maxlength on the text field will no longer match the size of the string that we then need to store.
That’s because those special characters will be escaped. An apostrophe uses one character when the user inputs it but 6 when it has been escaped:
How do we calculate the column size to store our expanding string?
Easy. The longest escapes produced by xmlFormat are ' and the ASCII characters 128 to 255, which also take six characters (eg É). So the column size is simply (maxlength * 6).
If we are enforcing a maxlength of 50 characters on the text field, then the longest string we need to store in the database will be 300 characters.
NOTE: Calculating the column size doesn’t mean you don’t have catch and handle truncated data errors! Just because you enforce a maxlength via HTML doesn’t stop evildoers posting parameters of arbitrary length to your application. The first thing an attacker will do is reconnaissance on your application, which means fuzzing those parameters until it breaks. With luck, the platform or a web application firewall will be there to keep errors from leaking juicy info about the app, but let’s not rely on it. It pays to be a little paranoid.
Besides, handling errors gracefully is a hallmark of elegant code. We all prefer elegant code to ugly hacks, right?