How does the Automatic Payment system work?

This is a great question and one that takes a little time to carefully understand how it works.

("AP" = Automatic Payments)

First of all a customer does not have the ability to specify when AP makes the payment. All AP payments are made on the due date of the charges. Another caveat is that upon a customer enrolling in AP they must pay their account off in full. This is for two reasons. First it gives us "known good payment information" so that they are not enrolling with, for example, a typo in their credit card number and fail payment the first time out of the gate. The second reason is that it pays the account down to zero which allows us to start nice and clean: charges are applied to the account, a due date is set, AP pays the balance on that due date and you billing software applies the payment in full. Clean all the way through.

This results in the following example:  Let's say your customer has a bill due on the 20th of the month and all future bills will also be due on the 20th.  If that customer enrolls in AP on the 10th of the month that results in the customer paying off their balance at that time and therefore would skip the very first due date because of the zero balance and would then get picked up the next month on the 20th and all further months on the 20th.

Our AP system checks your billing software every day at a time you specify (login as an admin, click on Settings at the top and then Preferences and scroll down). We recommend leaving it early in the morning so that if there is a problem we have some time to take a look. Our system attempts 4 times in the hour you specify and what happens most of the time is that the balances are paid on the first check and the other 3 checks are there as a backup. Let's say that your billing software server is being rebooted or your Internet has a hiccup at the time we first check for AP enrolled balances, that would result in not being able to run the job. So the extra few checks are just a safety measure. By checking every day for any balances that are due for all AP enrolled customers, it allows our system to be flexible in case you have various due dates for your customers. But if you have only one due date each month then basically your billing software tells us "no balances due today" 30 out of 31 days, but on that one day when balances are due it returns those amounts and our system gets busy hitting your payment gateway to process the payments.

AP will never show up as "pre-authorized" at your payment gateway and this is because our AP system is for all payment types whereas "pre-authorized" is payment type specific. Remember that our system is compatible with several payment gateways, some support pre-auth and some do not. So our system is built to a level of compatibility that is most easy to achieve across all payment gateways that we are integrated with.

You can tell "interactive" payments (customer initiated) from those that are attempted by way of the AP job by looking in the Transaction Diagnostic report for the day in question. If the payment was made by way of the AP job you will see an icon indicating such.

One common problem comes as a result of a returned eCheck. If there is a balance due and the customer is enrolled in AP with an eCheck and that eCheck bounces, you reverse the payment in your billing software and the result is that the balance is again due. What happens? Your billing software tells us there is a balance due (in this case past due) and tries to pay it again .... and it bounces again ... and so on and so forth. So if an eCheck bounces by way of an AP payment our best suggestion is to stop that customer's AP enrollment (search for account number in the Customers report, click the resulting record to get to the customer detail and you'll see a link there to stop AP). Customers only get automatically kicked out of AP if your payment gateway declines the payment real-time, then our system will send an email to the customer that the payment did not succeed and the customer will get kicked so that no further attempts are made until the customer corrects their payment information problem.

The Transaction Diagnostic report is your best friend as far as determining what payments were made interactively or automatically by way of our AP job.