Does Flint have a separate text-to-pay product?

The core mechanic is a hosted payment link. Text-to-pay is the delivery pattern: send the link by SMS or email and let the buyer finish checkout on their phone.

Is text-to-pay only for service businesses?

No. Service businesses are a common fit, but the pattern also works for donations, registrations, balances due, and other remote collection flows.

Text to Pay | Flint Pay

Home FeaturesText to Pay

Text to Pay

Flint text-to-pay workflows let you request payment by SMS or email using hosted links instead of card readers, paper invoices, or phone calls.

Use text-to-pay as a delivery pattern on top of hosted payment links instead of creating a disconnected payment flow.

Let operators send the same payment path by SMS or email depending on what gets the buyer to complete payment fastest.

Handle deposits, balances, and reminders without forcing the team into hardware-led collection.

Why Developers Reach for This

People searching text to pay usually want a payment request that closes on a phone, not a separate payments product category with its own buyer workflow.

Implement This When

The operator needs to request payment remotely while the buyer is on a phone.

The business wants a fast follow-up collection path after a service visit, estimate approval, or payment reminder.

You want one hosted payment experience that can be delivered by text or email instead of channel-specific workarounds.

Implementation Path

Start with the docs for this flow

Use the quickstart, API reference, orders model, and benchmark to move from evaluation into implementation.

Quickstart

Ship the first payment flow before you wire the whole stack.

API Reference

Open the REST surface for orders, checkout, subscriptions, and refunds.

Orders First

See the model behind Flint's order-backed payment approach.

Benchmark

Compare Flint against other developer payment workflows.

Common Implementation Patterns

After-the-job collection

Send the buyer a hosted payment path right after a service visit while the interaction is still current.

Estimate-to-deposit handoff

Text a payment request once the buyer approves the work so the deposit arrives before scheduling starts.

Reminder-driven balance follow-up

Resend the same payment flow when a balance is still open instead of restarting collection from scratch.

Mobile-first payment request

Use text-to-pay when the phone is the easiest path to completion, even if the underlying payment page is shared across other channels.

Choose a Different Primitive When

Use invoices when the payment request needs to look and behave like a formal bill with due dates and receivables follow-up.

Use hosted checkout when the buyer should enter a payment page tied to a specific configured order rather than a general collection link.

Use the service-business workflow page when the main search intent is field-service or home-service specific, not the product capability itself.

Implementation Docs

Payment Links API

The core API surface behind Flint text-to-pay workflows.

Accept First Payment Guide

Start with a hosted flow and move into reusable payment collection patterns.

Move from text-to-pay into the right workflow page

These pages help separate the broad text-to-pay feature from the more specific operator and product decisions around it.

Payment Links

Shareable hosted checkout pages for deposits, donations, event payments, and fast remote collection.

Hosted Checkout

Order-backed checkout sessions for payments that need line items, tax, discounts, redirects, and lifecycle state.

Invoices

Send itemized invoices with hosted payment, reminders, status tracking, and cleaner follow-up than manual chasing.

Payments for Field Service Software

Handle dispatch deposits, onsite collection, office invoices, and recurring service billing inside field-service platforms.

Next Step

Turn this feature into a working integration

Start with the quickstart, pick the Flint primitive that matches the workflow, then wire in the API surface and sandbox behind it.