Text-to-pay in the service drive: what it is, and what it is not

A pay-by-link or text-to-pay flow in a service department is a handoff. Your software issues a single-use link tied to 1 repair order and 1 amount, sends it by text or email, and the customer pays on a page hosted by the payment processor. A receipt comes back, the software writes it against the repair order, and the customer collects the car without queuing at a desk.

Calling it a payment product is where implementations go wrong. Nothing in the flow moves money except the processor. What the software contributes is the boundary around the transaction — which repair order, which amount, for how long, once — and the record afterwards.

Five parts, four owners, and the two you build

Where the card details actually go

Onto the processor's page, and nowhere else. The customer's browser talks to the processor directly; your system learns that a payment succeeded, for how much, against which reference. It never sees the card number, and no design should make it possible — not in a form field you proxy, not in a log line, not in a support screenshot, not in a nightly database backup.

Three jobs the link must never be given

1. Holding card data. If any component you own can read a card number, the design has failed and no amount of encryption redeems it. Redirect or use the processor's hosted fields; do not proxy.
2. Standing in for the authorisation record. A completed payment proves money moved, not that the customer agreed to the work — a different artefact, captured earlier, covered in what has to exist before a technician picks up a spanner. Shops that conflate the 2 discover it during a dispute, not before.
3. Bypassing reconciliation. A payment that lands in the processor's dashboard but not against the repair order creates a receivable nobody can close, and the shop finds out at month end. The write-back is not optional plumbing.

The write-back is the part that gets skipped

Sending links is easy; getting the result back onto the right record is where the build actually lives. The write-back needs a stable key, and in most shop systems the obvious candidate is unreliable — the repair order number is not a primary key once it is reused across stores or reissued after a split.

• One timestamp definition, written down. "Paid at" can mean authorised, captured or settled, and those can be days apart — the same discipline that makes time to line mean 1 thing to 2 people.
• Partial and split payments. A customer paying half now needs a second link against the same order, not a new order, and the balance has to be visible to whoever hands over the keys.
• Refunds and reversals. They arrive days later and must land on the same record, or the invoice tells 1 story and the bank tells another.

Where a card terminal is still the right answer

When the customer is standing in front of you, a terminal is faster and settles cleanly. Text-to-pay earns its place in the gaps: the after-hours collection, the customer who wants the invoice paid before a spouse arrives to fetch the car, the fleet contact who is not in the building. Some customers will simply not pay on a phone, and a link abandoned halfway looks exactly like an online booking abandoned halfway — instrument it, or you will not know.

Collecting payment earlier does not create shop capacity. It moves 4 minutes off the advisor's desk, which is worth having, and nothing more.

That distinction matters when the flow is being sold internally as a fix for a busy department. It removes a queue at the desk; it does not add technician hours, which is a capacity question the calendar answers badly, and it does not shorten the wait for an approval that blocks a bay. Building the link, the expiry rules, the write-back and the reconciliation report is internal tools and operations work. This page sits in service booking and customer communication, part of our automotive work.

• service payments
• pay by link
• repair orders
• dealership service