Payments

Payments in the CRM covers three things: seeing what came in, seeing what the collection engine tried, and doing something about either.

The Payments page

Three views, each shown only where its module is on and you can list its records:

• Payments - every payment, with its method and references.
• Direct Debit collections - collection attempts against mandates.
• Card collections - collection attempts against stored cards.

Filters: the same search box as invoices, plus a method filter and a Reversed only view on Payments, and a status filter (Pending, In progress, Collected, Failed) on the collection views.

Columns: on Payments, the date, customer, amount, method and references, with an amber Reversed tag and its date where applicable. On the collection views, the collection date, customer, amount, status and provider status. Card collections append the decline code, for example Declined - insufficient_funds, so you can tell a retry-worth-trying from a dead card.

Payment columns follow the payment Form Fields “Display (CRM)” configuration.

Actions on a payment

Opening a payment gives the collection actions, each under its existing backend permission and only where the payment has not already been collected.

Collect From Card

Starts a card collection for the payment.

Collect By Direct Debit

Starts a Direct Debit collection for the payment.

Reattempt Collection

Tries again after a failure. Offered where the payment is flagged failed or reversed.

Cancel Collection

Cancels a collection that has been created but not yet submitted. Offered where at least one underlying collection can still be cancelled.

Each reports back plainly: Card collection started, Direct Debit collection started, Collection reattempted, Collection cancelled, or the matching “could not” message.

Record Payment

Records a payment that arrived off-system - a cheque, a bank transfer, cash.

Reach it from the customer’s Payments tab, or as Add Payment on an invoice with something outstanding.

Required: the amount, the date and the payment method.

Optional: references, and which invoice to allocate it against.

What happens: this is the backend payment form, hosted in the workspace. Its allocation, auto-allocation and collection behaviour are exactly as they are in the billing platform, and a failed-payment TODO for the customer is cleared down. Only the surrounding page and where it returns you are different.

Important: arriving from an invoice defaults the amount to that invoice’s balance and allocates the payment to it. Manual reallocation of an existing payment remains a backend job.

Record Promise

Records that the customer has told you when they will pay.

Reach it from the customer’s Payments tab, or from a chase case.

Required: the amount and the date they promised.

What happens: an expected payment is created on the customer, so it appears in Expected Payments, on the customer’s Payments tab and on the Credit Control dashboard. Where it is recorded on a chase case it also creates a chase arrangement, which pauses chasing on the invoices it covers until the promise lapses.

The customer’s Payments tab carries a Promised payments panel listing every promise, whether it was recorded here, on a chase case or as an arrangement. Overdue promises are flagged, and a promise that has arrived is tagged.

Customers can also make a promise themselves, from a link in a chase email. See What your customers see.

Related pages

• Working with Payments for the full payment reference.
• Automatic Collection for how and when collections are created and submitted.
• Expected Payments for the promise record itself.