However, thinking back over everything that we’ve done since we started, there were plenty of things that we did that made our lives difficult after the fact, especially when it came to reconciling accounts and processing refunds. Hopefully sharing our missteps and mistakes might help save you a bit of time if you plan on taking payments yourself.

The first mistake we made was to be too worried about what would happen if our payment processor’s API took a long time to respond. We coded a lot of safety nets around this, recording all the details of the transaction in case something went wrong so we could redo it at a later time if necessary.

As it turns out, we’ve never experienced a timeout or overly long delay, so all that safety net coding was a waste of time. I wouldn’t bother with it now if I was starting again. You could just log timeouts or send an email alert and deal with them by hand should it ever happen to you.

The next thing we did that made our life difficult was to store the credit transactions in one DB table, and the calls and responses to the payment processor in another. This meant that when we came to reconcile the credit transactions without bank statements, we were missing some vital information.

Our payment processor batches payments together and we couldn’t easily work out which payment belonged to which batch without a lot of complicated work after the fact. Now we store the payment processor’s transaction and batch IDs with our own record of payment and it makes it very easy to reconcile our accounts whenever we need to. I really wish we’d done this from the start!

Another thing to bear in mind is that inevitably people make mistakes, and at some point you are going to have to process refunds of one sort or another. Doing the refunds themselves isn’t difficult. In our case Realex has simple online tools to handle them. However, you will want to design your system to handle refunds in such a way that you can reconcile your accounts afterwards. Just deleting or altering your own record of the payment will make this very difficult. You’d be surprised at how quickly you forget what the heck went on.

By way of example, if you take a payment and then have to refund it two weeks later, you could just delete the original transaction from your system and the books will balance, but you will be out of sync with your payment processor in two places – the original transaction and the refund. If each of these happened in different accounting months it can lead to real headaches. Ultimately, even if you don’t handle refunds directly through your transaction system, you will need to setup your code to handle refunds transactions that you enter by hand.

New credit card details can also cause problems. People get issued new cards for all sorts of reasons, so the details you have today are not necessarily the details you will have tomorrow. If you ignore this and just let people overwrite their current credit card details, it can make looking back at old transactions next to impossible. You should code for multiple cards, so a new card is added rather than overwriting the current card’s details.

Finally, if and when a customer complains about a transaction to you, stop and listen. As soon as they go to their bank and ask for the transaction to be reversed, you will be punished with higher fees and a permanent flag against your account. The banks have made this very easy to do in recent times, so it is in your best interest to avoid any dispute as quickly as you can. If in any doubt, refund the transaction. Even if you are proved to be right in the long run, your account will still be flagged because you haven’t done enough quickly enough to avoid the dispute.

Hopefully the advice above is of some use to you. We’d love to hear your stories of setting up to receive online transactions too, so leave a comment.