Testing With Real Money
When building a new website, or making changes to a current site, there is always some kind of testing in place. This testing usually involves every portion of the website, including any payment processing. However, because you wouldn’t want to spend real money just to test that an order form is working, payment systems usually have a test mode. This allows you to test you site without having to make real transactions, but also has a few shortcomings. This article is going to focus on, why and how you, as a client should test your payment gathering portions of the site.
A deeper explanation
To explain in deeper detail, we first need to look at how a website processes payment information. The following is a very rough and generic outline of a typical payment flow. It’s important to note that this is very inaccurate, and is meant only to demonstrate logical steps in a process. From a website’s point of view this is “close enough”. In truth there are many more steps, but for the purpose of this article this is complex enough.
First we start by preparing a server side payment record (think an order). We then authorize the payment. Authorization is sent to the gateway. Authorize.net, and Paypal are very common examples of payment gateways. The gateway then sends the details to the customers bank and the bank checks the customers account to make sure that they are able to spend the money. Authorization can mean many things. In the case of credit cards it can mean checking the security code, and address. For Paypal it could mean having the user log in. Once the customer’s bank approves the transaction they give permission to the gateway and they pass that permission back to the site.
At this point we haven’t actually received any money, just permission to ask for money. We move to the next step, capture. As the name implies this is where we get actual money. We take the authorization we just received, and try to get real funds. This of course goes back though the gateway. The gateway then talks to the customers bank, which checks the customers account and finally, after many steps sends the money (or promise of money) back to the gateway. Most gateways, hold this money for a while, to make sure everything is ok. Then the money is sent to your bank, and finally your account. If everything goes according to plan, data is passed back to the website, from the gateway.
Finally, your site has been notified of a completed transaction and it can do any post order work, like sending emails, granting access, or shipping products.
When testing any kind of code you want to break down that code into it’s smallest bits, and test that. This creates a very large number of tests. At the same time, you as the client want to see the site working and use it. When working with a site that has payment processing, both developer and client will need to test things like credit card forms. Because you could test these things several thousand times, you don’t really want to use real money. Payment gateways often have test environments that can be used to develop and test against. This is great, because it keeps you for using real money to test site functions over and over again. However, this also means that there is no testing for anything deeper then talking to the payment gateway.
When using a payment gateway’s test environment, any banks are ignored, and the gateway almost always returns that everything is working fine. This means that as a developer I can test that we are interacting with the gateway correctly, but I can not test that your bank, or even your real gateway account are setup correctly.
The fix is simple. After launching to production, but before you start any real advertising, simply buy something off your site. This can be a bit of an expense if your selling high value items or services, but it’s much better then not knowing if you can process payments at all. Testing with real money in production means that you have tested your payment section of the web site completely, from end to end, and that you have watched the money end up in your bank account.
How to test
Well, as stated, the best way to test that everything is working, is to buy something off your site. Here are a few tips:
- Buy using every payment method. If you accept check and credit card test both.
- Test in amounts that are normal for your site. If you sell $20 products try buying some $20 products. If you sell $20,000 products, buy some of those. Banks have different rules for different amounts of money, make sure your testing with real amounts for your site.
- If you accept credit cards, make sure to test with as many as you can. I have seen many people test with Visa and then fail Amex transactions because their bank forgot something. When transactions fail this way, it can be devastating, because the gateway often reports everything is fine, and thus the product is shipped, but you never get any money. Obviously, there are limits because your testing with real money and real credit cards, but you should try as many combinations as you can.
- Make sure the transactions actually result in increased funds in your bank account. This can take several days, but I have seen several clients get stuck trying to get funds to their actual bank, for weeks or months, all because a bank rep. forgot to fill out a form. This is especially true on large, or international transactions.
By taking the extra time, and spending the extra money to test your payment processing in production, you ensure that when you start getting traffic, you will be able to process payments correctly. If you choose not to test, you can run into a whole mess of problems that could result in anything from shipping thousands of dollars worth of physical products that you will never receive money for, to angering hundreds of customers because, no matter what they do, they can finish their purchase.
Coteyr.net Programming LLC. is about one thing. Getting your project done the way you like it. Using Agile development and management techniques, we are able to get even the most complex projects done in a short time frame and on a modest budget.
Feel free to contact me via any of the methods below. My normal hours are 10am to 10pm Eastern Standard Time. In case of emergency I am available 24/7.
Phone: (813) 421-4338