Invoices & balances due
Text the payment link the moment the invoice goes out, and again as the reminder. The link opens the same hosted form either way, and the payment reconciles to the invoice.
Send a secure payment link by SMS and the customer pays on a hosted page in two taps, card, wallet, or ACH, no app, no login, no card data in the message. Text to pay runs on the same underwritten, high-risk-ready account as the rest of your processing, so the fastest way to get an invoice paid is also one that doesn't freeze.
Answer first
Every invoice-based business knows the gap between sending the bill and getting the money, and most of that gap is attention, not unwillingness. The emailed invoice sits unread; the mailed one sits unopened; the portal login gets postponed. A text message doesn't have that problem. SMS messages get opened at rates email never touches, and they get opened now, while the customer is holding the device the payment happens on.
Text to pay closes the gap by putting a secure payment link in that message. The customer taps, sees your business name and the amount on a hosted payment page, and pays with a card, a digital wallet, or a bank transfer. Nothing sensitive travels by SMS, the message carries a link, the hosted page carries the security, and the whole flow runs on a merchant account that's been underwritten for your category rather than a generic tool that boards fast and freezes faster.
Where it fits
Text the payment link the moment the invoice goes out, and again as the reminder. The link opens the same hosted form either way, and the payment reconciles to the invoice.
Collect a deposit while the customer is still on the phone deciding, service businesses, contractors, events, travel. A texted link converts intent before it cools.
Techs and crews finish the job and the office texts the bill, no card reader in the truck, no keyed entry over a bad connection.
Sales conversations that end with "send me the link" get exactly that, a branded page with the agreed amount, by text, within the minute.
A stored, tokenized method lets repeat charges run without re-entry, and a text confirms each one, fewer surprises, fewer disputes.
The hosted page offers both rails: cards for speed, flat-fee ACH for the large invoices where a percentage would sting.
Why text
| Emailed invoice | Mailed invoice | Text to pay | |
|---|---|---|---|
| Gets seen | Often, eventually | Days later | Almost immediately |
| Steps to pay | Open, click, form | Write & mail a check | Tap, confirm |
| Card data handling | Hosted page | None (check) | Hosted page, never in the SMS |
| Best for | Documentation & records | Customers who insist | Actually getting paid |
The point isn't to replace the emailed invoice, it's to stop waiting on it. Send both: the email carries the document, the text carries the payment. See invoice & pay-by-link processing
Built on the hosted form
Text to pay isn't a separate product, it's our hosted payment pages and payment links delivered over the channel with the highest open rate. The page carries your branding and descriptor, tokenizes the card, supports one-time and recurring charges, and keeps card entry off your systems entirely. If you already use our payment links, you already have everything text to pay needs; the SMS is just the delivery.
How it works
Text to pay runs on a merchant account. Ours is underwritten for your category before boarding, elevated-risk verticals included, with the rate and any reserve in writing.
Set the amount, tie it to an invoice or a deposit, choose card, ACH, or both, in the portal or by API.
The customer gets a short message with a secure link. No app, no account, no login on their side.
The payment lands on your account, shows in the merchant portal in real time, and syncs to your books.
Compliance
Two rules keep a text-to-pay program healthy. First, consent: text payment requests to customers who expect them, an invoice they're waiting for, a deposit they agreed to on the call, and honor opt-outs, which is both good law (TCPA) and good business. Second, never put payment data in the message: the SMS carries a link and a description, the hosted page carries the payment. That split is what keeps your PCI scope minimal and the customer's card data off every phone involved.
The rest is the same discipline as any card-not-present channel: a recognizable business name on the page and on the statement descriptor so the charge isn't disputed as unrecognized, receipts issued automatically, and fraud screening on the transaction itself. All of that ships with the account, because a texted link is only as good as the processing behind it.
FAQ
Text to pay (also called pay by text or SMS payments) is a payment method where a business sends the customer a secure payment link by text message; the customer taps the link, sees the amount and the business name, and pays on a hosted payment page with a card, a digital wallet, or a bank transfer (ACH). There's no app to install and no portal login, the payment form opens in the phone's browser. Because card data is entered on the processor's hosted page rather than in the message, the SMS itself never carries anything sensitive.
Yes, when it's built the right way. The text message contains only a link, never card data. The customer enters their details on a hosted, PCI DSS-aligned payment page, so sensitive data never touches your phone system or your servers, and your own PCI scope stays at the simplest level of self-assessment for most merchants. Tokenization means a repeat customer can be charged against a stored token rather than a re-entered card number.
Three steps. First, get approved: text to pay runs on a merchant account, and ours is underwritten for your category before boarding, including the elevated-risk verticals generic tools freeze. Second, create the payment request, an amount tied to an invoice, a deposit, or a one-off charge, in the merchant portal or by API. Third, send the link by SMS from the platform or paste it into the messaging tool you already use. Payments land in the same portal, on the same account, as the rest of your processing.
Because texts get seen. SMS open rates run far above email, and the payment is two taps from the notification: open the link, confirm the payment. For invoice-based businesses the practical effect is on days-sales-outstanding, a texted link tied to an invoice turns "I'll get to it" into a payment while the customer is holding their phone. The same link can also be embedded in the emailed invoice, so text and email reinforce each other rather than compete.
Yes. The hosted page behind the link can offer both card and bank-transfer (ACH) options on the same payment, cards for speed and points, ACH for large invoices where a flat or capped fee beats a percentage. That combination matters for B2B: the text gets the invoice seen, and the ACH option gets the big ticket paid on the cheap rail.
Direction. With text to pay, the customer enters their own payment details on a hosted page you sent them, self-service. With a virtual terminal, your team keys the card on the customer's behalf during a phone call or from a mail order (MOTO). Many businesses run both on the same account: text the link first, and key the card only when the customer prefers to read it out. Self-service entry on a hosted page also tends to carry lower fraud and dispute exposure than keyed entry.
If your invoices wait on attention rather than willingness, a texted payment link is the shortest path between the two, on an account underwritten to stay live.