Managing High-Volume Payments: Work the Exceptions, Not the List

Payment Automation

Managing High-Volume Payments: Work the Exceptions, Not the List

Managing high-volume payments means collecting many payments a month without checking each one by hand: each payment is created from your own system with your reference, carries its own status, and only the payments that fail or come back need your attention.

Volume changes the problem. With a small number of payments, you can look at every one. As the count grows, that stops being possible, and the real work becomes finding the payments that need a decision. This article is written for businesses and platforms that collect many payments a month, such as rent, loan repayments, memberships, or invoices. It covers creating payments from your own system, creating them in batches, and keeping each one matched to your records.

What Breaks at Volume

Few teams decide to run payments on spreadsheets. It happens gradually, and a few habits tend to show up together.

• A spreadsheet becomes the record. A list of who owes what, edited by several people, where it is not always clear which version is current.
• Payments are keyed in or uploaded by hand. The same details are entered more than once, and each entry is a chance for a typo.
• Checking the bank is the status check. Someone reads statements to see what arrived and what did not.
• A problem is one line among many. A payment that failed looks like all the others until someone happens to notice it.

These habits also depend on people. When the person who knows the spreadsheet is away, or moves on, the routine goes with them. And the effort grows with the number of payments, not with the difficulty of any single one.

None of this is a problem of moving money. It is a problem of knowing: which payments are fine, and which ones need attention. Our article on manual banking tasks you can stop doing covers the wider list of routines this replaces.

Create Payments From Your Own System

Your system already knows who owes what: the customer, the invoice or the contract, the amount. A dependable way to create payments at volume is to let your system create them through the API, instead of having someone key them in.

Each payment is tied to a reference from your system. In TIB Finance, the amount owed is recorded as a bill, and a bill can carry reference fields of your own, such as an invoice number or a contract number. The payment can carry a reference too. That reference stays with the payment from creation to result, so a result is never an anonymous line: it points back to a customer and an invoice.

Each customer is recorded once, with their preferred language, English or French, and the payment pages and payment request emails follow that language. Payments are then created against that customer, so the history of one customer stays together.

Payments that repeat can be scheduled with a frequency, such as weekly, every two weeks, or monthly. For repeating bank account debits, the customer's agreement is needed first, and our guides to pre-authorized debits and recurring payments in Canada go through what that involves. Your system can also create each cycle's payment as its own payment, if you prefer to keep that control.

Payments can be collected by bank account debit (EFT, including pre-authorized debit), by Interac, or by credit card. These sit side by side on one platform, so one process serves them all.

Batches, Briefly

When many payments are created at once, two options are worth knowing about.

• Batches on saved payment methods. Payments can be created in a batch on payment methods already saved on the customer. A batch can be set to repeat and can carry a group identifier, so the payments of one batch stay together.
• A payment file. A payment file in a standard bank payment file format can be uploaded. Each line becomes a bank account payment, and the payments of one file stay together under one group identifier.

Batches and files are ways to create payments in volume, not a replacement for the rest of this article. Each payment still has its own reference and its own status, and that is what keeps the next step possible.

One Status Per Payment

Each payment carries its own status, such as pending, in progress or completed, or an error or cancellation with the reason. A payment that went through never hides another that did not, because each has its own result. That is what lets you work the exceptions instead of the whole list: the payments that went through need nothing from you, and you look at the ones that show an error or a cancellation.

When a payment fails or comes back, the result is shown on that payment alone, next to your reference. You can tell which customer and which invoice it concerns without going through bank lines, and what happens next is your team's call.

A routine that works at volume is short: open the exceptions, read the reference, decide what to do, and record the decision in your own system. The rest of the list does not need to be opened.

Reconciliation at Scale

Reconciling by hand does not keep up as payments multiply, and it does not have to be done by hand. Each payment ties back to your records through the reference you gave it. Its status reaches your system through the API, and by webhook, which is a notification when a payment's status changes. Your system then updates your own records: the invoice shows as paid, or the contract shows a failed or canceled payment. Our guide to automated payment reconciliation goes further.

Matching applies to payments tied to a reference you provide, which is one more reason to set the reference at creation.

The Same Structure for Different Payments

The pattern does not depend on what is being collected. What changes is the reference and the rhythm.

• Rent. One payment per tenant per month, tied to a lease or a unit.
• Loan repayments. One payment per due date, created by your system and tied to the loan. A failed or canceled repayment shows which loan it concerns.
• Memberships. One payment per member per period, tied to the membership.
• Invoices. One payment per invoice, tied to the invoice number. Our guide to automating accounts receivable covers that pattern in more detail.

In each case, the question at volume is the same: which payments need me? A reference and a status on every payment help answer it, whichever payment methods your customers use.

Where to Start

Begin in the sandbox, a separate environment for safe testing, with a small set of payments. Create them from your system with your own references and see what your screens and records do with each status that comes back. Once that behaves as expected, add more payments step by step.

The connection to your system is built on the API and webhooks, and it is set up client by client. Developers can start with the developer documentation, then read our guide to testing payment integrations for the method and the payment API integration guide for the integration itself.

If you want to see the same ideas applied to a specific kind of payment, there is payment automation for property managers and payment automation for lenders. For the platform view, see our article on how software companies add payment processing.

If you are working out how this fits your system and your process, contact our team.

Common Questions

What does managing high-volume payments mean?

It means collecting many payments a month without checking each one by hand. Each payment is created from your own system with your reference and has its own status, so you work only the payments that fail or come back.

How should payments be created when there are many?

Through the API, from your own system, instead of keying them in. Each payment is tied to a reference of yours, such as an invoice number, so it can be matched to your records from creation to result.

How is each payment matched to our records?

In TIB Finance, the amount owed is recorded as a bill, and a bill can carry reference fields of your own. The payment can carry a reference too. The reference stays with the payment, so the result can be recorded against the right customer and invoice in your system.

Can payments be created in batches?

Yes. Payments can be created in a batch on payment methods already saved on the customer. A batch can be set to repeat and can carry a group identifier to keep its payments together.

Can we upload a payment file?

Yes. A payment file in a standard bank payment file format can be uploaded, and each line becomes a bank account payment.

Can payments repeat on a schedule?

Yes. Repeating payments can be scheduled with a frequency such as weekly, every two weeks, or monthly. For repeating bank account debits, the customer gives their agreement first.

How do we know which payments need attention?

Each payment has its own status, such as pending, in progress or completed, or an error or cancellation with the reason, so you can work the exceptions instead of the whole list.

What happens when a payment fails or is canceled?

The result is shown on that payment alone, next to your reference, so you can tell which customer and invoice it concerns. What to do next is up to you.

How does our system learn the result of a payment?

TIB Finance sends status updates through the API and by webhook, which is a notification when a payment's status changes, so your own records can reflect the result.

Can we test before moving to volume?

Yes. The sandbox lets you try the whole flow with test payments before any real one. Begin with a small set and watch how your system reacts to each status it receives.