One common question we hear is "why are the processing fees so high for gift card?" and "why does it cost so much for gift card software?" When computer programmers call in, they wonder why it costs so much for what they see as little work.
When we look at what the system is asked to do, the processing is quite simple: add some money to the current value or subtract some money from the current value. That is fairly easy to do.
Gift card processing could be very simple (and cheap) if that were all that was asked for from such systems.
The first extra requirement is that the system has to make sure that the merchant requesting that addition is a valid merchant. There are two layers to that requirement.
The first layer is that of web security. For any system exposed to the web, people will try to break into it. The speed at which people are finding and breaking into systems is surprising. An unprotected system has about five minutes before it will be broken into. Web security starts with the server security and then every page exposed to the web has to be designed to prevent any number of different styles of trying to break it. Web security is not cheap and it is never finished. All we can do is prevent most people from getting into the system.
Do people want to break into a gift card system? Absolutely. For example, we were talking to a chain of repair shops. I could easily see someone trying to break in to get a $1,000 repair for free.
The second layer is that of merchant ID verification. That means that we have to have all the screens to manage merchant names and ID's. On our web system, that process of managing the merchants and clerks takes over ten screens. Yes, I'm sure that other people do that with fewer screens, but the point is that a lot of work goes into building a system to manage the merchants
The second extra requirement is that of handling all the transactions that a merchant would want. Activate and Sell from Card are not the only thing merchants want to do. Others include, balance inquiry, balance transfer, top up card, daily sales reports, and batch management. Ok, so we add those into the system.
The third requirement is that of being able to provide an audit trail of all transactions and other changes to the system. This audit trail requirement gives us the data for the reporting.
The fourth requirement is the ability to back out transactions. Some merchants ask for a "void last transaction" capability. Even more important are the dial up terminals. Dial up transactions break down at a known rate (1 to 10%) of the calls. That means that the server sees a transaction that does not get completed at a terminal. The next time that terminal calls in, the previous unfinished transaction has to be backed out and logged in the audit trail.
Each of these extra requirements add complexity. For example, look at the backing out of a void of a balance transfer. The system has to move the amount correctly back and properly restore the balance transfer. Backing out voids is a major piece of code and testing it is even more challenging.
What else do people ask for from a gift card system?
Some merchants want their customers to be able to log in and see the outstanding balance on their card. That means that we have to build a way for those customers to register and get a password. We may need to allow them to see not just the balance, but all the transactions on that card.
Other merchants want to use credit card machines to run these transactions. That adds two different layers to the system. To support the old dial up terminals, the system has to be able to manage multiple modems and their protocol. The dial up terminals do not use the same protocols that dial up internet users use. That means that the operating systems and/or digital modem banks do not have that protocol built in. So, we have to add a protocol handler. Protocol handlers often cost $10,000 or more depending on the throughput required.
The other way these POS terminals interact with a server is through the Internet. There are several protocols that could be used to talk to a POS terminal over the Internet. We may need to support multple protocols. Thus, we may have to have multiple programming efforts.
Other merchants want to have their POS registers talk to the server. This can be a significant effort. Some of the POS register companies are not really willing to work with other vendors. Some POS register software is quite complex to interface in with the system. For example, we did an interfacing project for one gift card system that cost $40,000.
One issue that ISO's often have is that they want to have a server that supports all the known credit card terminals out there. This is a major development cost. A good way to estimate that is that each terminal line from each terminal vendor will cost $20,000 to support.
Given all these additional requirements, it is hard to have a system at a real low cost. The question is "how many merchants will be on that system?" The more merchants we can put on a system, the lower the cost per merchant. However, the more merchants we put on a system, the more varied the requirements become. At some point, a merchant will cost more to sign up than we will get from that merchant.
Give us a call to talk over your ideas of what you want.
1-800-618-4199
Back