High volume credit card transactions in a SAAS start-up

Given the volume of data and the need to preserve it for a long time, you need to set up a relational database and set up your various data sources (credit card info from the bank, sales order info from your systems, etc.) to upload the data to the DB.

You can build your reporting manually if you'd like. You should include reports on exceptions (payments that cannot be matched to an existing sales order, sales orders that are not paid in the right amount of time, denied credit card transactions, etc.) and on activity summary (cash coming in, age of paid invoices, A/R aging, etc.)

Sorry for a rather generic answer, but you asked a pretty generic question.

Best regards,

Daniel

It has been a while, but I had a similar situation. We processed online orders in one system, and I had a tool through which I could import all the orders into Quickbooks. That was an important step because I wanted to have all the order data in Quickbooks. You don't have to do that; you could just do journal entries for each day's orders, but then Quickbooks would not be your "system of record" for orders. I did not want to do it that way.

Then I could get detailed reports of each order and the credit card transaction by logging into the credit card gateway (Authorize.net at the time), and export those to Excel. Using the export from Authorize.net, I could receive payments against the orders in Quickbooks, and also see which credit card charges were grouped together as deposits in our bank account. The process required some manual work, but worked pretty well. (We processed hundreds of transactions per month, not thousands.) We were able to automate parts of the process along the way, and since my experience was a few years ago, you may find that there are better integrations between Quickbooks and credit card processors today. Also, you will likely have to deal with charge backs which add some complexity.

If you were to use the credit card processing though Quickbooks it might make all that easier, but I have not used it so I can't say.

Hope this helps,
Mark

In this scenario – assuming it is a high volume and lower dollar amount transaction model - most people separate the flow from ecommerce platform to accounting system into two separate data streams. Generally speaking the two flows are:

1) Revenue – Deferred Revenue in this scenario – which may be done by the individual sale or in a summary level by transaction type by day. Given your transaction volume you may need to consider a revenue management solution sooner than later – especially if your support team makes changes to specific revenue agreements post transaction creation.
2) Cash – this is the receivables transaction. Most people would not customers of this type into their accounting system. Accounting system customer files are useful for repeat business of larger dollar amounts. Customers for the cash management are usually the merchant accounts (master card, paypal).
The net result of the two transactions is a deferred revenue subledger, and daily invoices for the totals deposited by merchant bank account.

There are variables in the model – such as when the transaction is released by the ecommerce system, what type of analytics are required, what the exceptions are and how they are handled, and how to streamline the transaction flow.
Overall it is usually preferred to let the ecommerce platform manage the end customer and for the accounting system to concentrate on the cash flows and updates from the deferred revenue sub ledger.

Bob Scarborough
www.tensoft.com

We manually match over 1,000 credit card and cash transactions per month by loading the daily download from our 50+ bank accounts into Excel and inputting the cash and credit card settled daily paperwork from our 60+ stores into the Excel file. It's tedious work although the cash is quite straighforward. Our process improvement goal is to bring all the data from our stores into a centralized database, a challenge in itself. Once done I'll re-open my discussions with Trintech and Chesapeake Systems, two companies that build reconciliation software driven by algorithims we create, to automate this process.