SMS Request-to-Pay: Text a Tap-to-Pay Link
Not everyone has your payment app installed, but almost everyone can receive a text. SMS request-to-pay uses that near-universal reach: you send someone a link over SMS, they tap it, and a pre-filled payment screen opens. It is the lowest-friction way to ask for money from someone who is not yet inside your product.
How the flow works
The requester enters who they want to charge and how much. KibiPay generates a payment link tied to the requester's alias and the amount, then sends it by SMS to the payer's number. The link is a deep link: tapping it opens the payer's wallet — or a hosted checkout if they have no app — with the recipient and amount already filled in. The payer confirms, and the routing engine picks the rail.
- Reaches people who have not installed anything yet.
- Carries the amount and reference so the payer does not retype anything.
- Falls back to a hosted page when no app is present.
Why SMS is the right channel
Email gets buried and app invites get ignored, but a text about money owed gets read. For informal requests — splitting a bill, collecting for a group gift, invoicing a one-off client — SMS meets people where they already are. The channel's ubiquity is exactly why mobile money grew up on it.
| Scenario | Why SMS fits |
|---|---|
| Splitting a dinner bill | Everyone at the table has a phone |
| One-off invoice | No account setup required of the payer |
| Reminders | High open rate on a due-payment nudge |
Consent and compliance
Texting a link is still messaging, so the same A2P 10DLC discipline applies. Requests should go to numbers that expect them, opt-out handling must be honored, and the message content should clearly identify the sender and purpose. A request-to-pay text is transactional, but it still needs to respect the recipient's consent and carrier rules.
Guarding against abuse
Any system that lets one person text another a payment link can be misused to phish or harass. Sensible guards include rate limits on how many requests a sender can issue, clear branding so the payer knows it is a KibiPay link, and a confirmation screen that shows the resolved requester name before money moves. The payer is always in control at the moment of payment.
Where the link leads
Because the link references an alias, not a raw account, the payment stays rail-flexible right up to confirmation. The payer might settle over mobile money, a bank rail, or a wallet depending on what they have. For how that resolution step works under the hood, see our overview of aliases and proxy lookups.
Measuring what works
Request-to-pay lives or dies on conversion, so it is worth instrumenting. How many links are opened, how many opens become confirmed payments, and how long the gap is between send and settle all tell you whether the flow is doing its job. A link that is opened but abandoned points at friction on the payment screen; a link never opened points at message content or timing. Treating each request as a funnel — sent, delivered, opened, paid — turns a fuzzy feature into something you can improve deliberately. It also surfaces abuse early: a sender whose links are opened but almost never paid may be blasting numbers that never agreed to hear from them, and that pattern is exactly what carrier compliance programs want you to catch.
A text, a tap, a confirm — SMS request-to-pay turns the phone in everyone's pocket into a checkout, and it is one of the quieter conveniences KibiPay ships for getting paid.