How can a payment platform offer request to pay?
Request to pay runs on account-to-account rails, sent as a payment request the payer approves in their banking app. Operators add it through payment rails connected to the platform and present it next to cards in a branded checkout or payment link.
In detail
Request to pay runs on account-to-account rails, sent as a payment request the payer approves in their banking app. Operators add it through payment rails connected to the platform and present it next to cards in a branded checkout or payment link.
What the customer sees
Request to pay sends a payment request to the customer's banking app, with the amount and the payee. The customer approves, and the money moves by instant transfer. There is no card, no chargeback and settlement arrives in seconds. It suits invoices, deliveries, in-store payments by QR code and any case where the merchant knows the customer.
What the platform adds
- Connection to the request-to-pay scheme or provider in each market, since schemes differ by country.
- A way to issue the request: from the checkout, from a payment link, from an invoice or from an API call.
- Status handling: pending, approved, declined, expired, with the merchant notified in real time.
- Reconciliation of the incoming transfer against the request, so the order is marked paid without manual matching.
Where it works today
Request to pay is live on several instant payment rails, with different names and reach. Operators usually add it market by market, starting where merchants ask for it: utilities, marketplaces paying out, and retailers in countries where bank payments already beat cards. Presenting it next to cards in the same checkout, with the same reporting, is what makes it a method rather than a project.