Request to Pay Over SMS and QR Codes

Sometimes you do not want to wait to be paid — you want to ask. Request to pay lets you prompt a specific person for a specific amount, delivered over SMS or a QR code, while leaving the payer fully in control of whether and when they approve. It is one of the most useful patterns in modern payments, and KibiPay supports it end to end. This post explains how it works and when to reach for it.

What request to pay is

In a normal push payment, the payer decides everything: who, how much, and when. A request to pay adds a prompt in front of that: the payee sends a request, and the payer reviews it and approves. Crucially, the money still moves as a push — the payer authorizes it — so nobody is reaching into anyone's account. It combines the convenience of a bill with the safety of a payer-controlled transfer. We contrasted these models in push vs pull payments.

Delivered over SMS

A request can arrive as a text message. The payer gets an SMS describing who is asking, for how much, and a way to approve. SMS makes request-to-pay work even when the payer is not sitting in an app — a huge advantage for reaching people quickly. It pairs naturally with phone-first accounts, described in phone-first accounts, and echoes the live SMS receipts covered in receiving a live SMS receipt.

Delivered as a QR code

A request can also be encoded as a QR code carrying the amount and the payee. The payer scans it, sees exactly what is being asked, and approves. This is ideal in person — a stall, a counter, an invoice on screen — where showing a code beats reading out details. It extends the get-paid patterns in get paid: share your handle or QR by baking a specific amount into the code.

The payer stays in control

The defining feature of request to pay is consent. A request is an invitation, not a withdrawal:

• The payer reviews the amount and the requester before anything happens.
• They can approve, decline, or ignore it.
• Only on approval does a push payment run, subject to the usual balance check.

This is why request to pay is so resistant to a whole class of scams: nothing is pulled, and the payer sees exactly what they are agreeing to.

Where it shines

1. Splitting a bill — request each friend's share.
2. Invoicing — send a request for the invoice amount.
3. Point of sale — show a QR for the exact total.
4. Reminders — nudge someone who owes you.

What happens after approval

Once approved, the payment runs like any other alias payment: KibiPay resolves the parties and the orchestrator picks a rail, as in how the orchestrator picks your rail. Both sides see the result on their statements — a send for the payer, a receive for you.

Try requesting a payment

Why request to pay resists scams

A striking property of request to pay is how little room it leaves for abuse. Because the payer must actively approve, and because the actual movement is a payer-authorized push rather than a pull, there is no standing authority for a fraudster to exploit and nothing gets taken without a conscious yes. The payer sees precisely who is asking and for how much before anything happens. Compare that with models where money can be pulled on a stored mandate, and the safety advantage is clear — the human stays in the loop at the one moment that matters.

Used well, request to pay closes the gap between waiting to be paid and chasing people manually. It lets you ask clearly, deliver the ask wherever the payer already is, and leave the decision firmly in their hands. That blend of convenience for the requester and control for the payer is why so many modern instant-payment schemes have adopted the pattern — and why it feels natural the first time you try it on KibiPay.

Open the KibiPay app, send a request to pay to a friend or a second test account over SMS or QR, and watch them approve it. New to KibiPay? Start with the two-minute walkthrough, and browse more on the blog.