Request to Pay for businesses: ask for payment without automatically taking it

Request to Pay is a secure messaging service that lets a business send a payment request to a customer without automatically pulling money from the customer's account. The payer can respond through a supported service, giving the business a structured alternative to chasing invoices by email or relying entirely on fixed automatic collections.

Request to Pay is a messaging layer, not a new bank account

Pay.UK describes Request to Pay as an overlay messaging service that sits alongside existing payment infrastructure. Businesses can issue bill-payment requests and communicate with payers through a secure channel.

The request itself is not the settlement rail. The customer still authorises a payment using the supported payment method or banking process. This distinction matters for reconciliation: finance needs to track both request status and the actual receipt of funds.

The payer retains more control than under automatic collection

Unlike Direct Debit, where a valid mandate lets the biller collect on the agreed date, Request to Pay allows the payer to respond to the request. Supported responses can include paying, asking for more time or communicating about the bill depending on the service implementation.

This can suit customers with variable income or bills where the amount changes significantly. It gives the business structured interaction without automatically assuming the customer's account should be debited.

Use accurate bill data and references

The value of Request to Pay increases when the request contains the correct invoice, amount, due date and customer reference. The customer should be able to understand exactly what is being requested before authorising payment.

Generate requests from the billing system where possible rather than manually retyping amounts. A wrong request can create customer distrust and reconciliation work even if no money is taken automatically.

Connect the request identifier to the eventual payment

Pay.UK highlights reduced reconciliation cost as one of the potential business benefits. To achieve that, the merchant needs the request and final payment reference to flow into accounts receivable.

Do not mark the invoice paid because the customer accepted or viewed a request. Clear the receivable only when the payment status confirms settlement. Keep outstanding, declined or deferred requests visible for credit control.

Use Request to Pay where payer flexibility matters

The service can complement rather than replace Direct Debit. Fixed utilities or subscriptions may still suit automatic collection, while irregular bills, professional services or customers needing more control can suit a request model.

Compare customer adoption and payment speed. A theoretically flexible tool provides little value if customers ignore the requests and still pay by manual transfer. Pilot with a defined customer segment and measure results.

Secure messaging can reduce some invoice-fraud exposure, but identity still matters

A trusted Request to Pay channel can be safer than emailing new bank details, because the request comes through an enrolled service. The business still needs strong access controls over who can create requests and which customer account is selected.

If a customer queries a request, verify the invoice before asking them to pay. Do not use urgency or repeated messages to pressure a customer into accepting a request they do not recognise. Fraud controls work in both directions.

Define what each payer response means operationally. A request marked "needs more time" should create a credit-control task rather than disappear from the collections queue. A declined request should prompt the business to check whether the invoice is disputed, already paid or simply not recognised by the customer.

Use Request to Pay alongside an accurate customer master. If the mobile number or service identifier belongs to a former employee, the request can fail or reach the wrong person even though the invoice is valid. Treat payer-contact data as financial data and review it when customers change finance staff.

For B2B invoices, compare adoption with ordinary bank-transfer reminders. A structured request can improve reconciliation, but some corporate customers will still require purchase-order matching and internal approval before they can pay. The collection method cannot bypass the buyer's own accounts-payable controls.

Measure payer behaviour after launch. Track how many requests are opened, paid immediately, deferred, disputed or ignored. That data helps the business decide whether Request to Pay genuinely improves collection compared with email reminders or Direct Debit. A new payment tool should earn its place through lower collection cost or faster cash.

For recurring billers, define when a missed Request to Pay becomes arrears. A customer can have more interaction choices than under automatic debit, but the underlying contract still needs a clear due date and escalation policy. Flexibility should not make the accounts-receivable ledger ambiguous.