Messages your US customers are expecting, delivered when they matter

Transactional SMS is not a category defined by content; it is defined by trigger. The message exists because something happened: a user asked for a login code, an order was placed, an appointment was booked, a payment cleared, a password reset was requested. The customer is waiting for the information the message carries.

Typical examples include one-time passwords for login and multi-factor authentication, password reset codes, order confirmations, dispatch and delivery updates, appointment confirmations and reminders, payment confirmations and fraud or security alerts. None of these need persuasion; they need to arrive. That single distinction, expected and event driven, separates transactional from marketing, and it is why the two categories should be planned separately. Our comparison guide walks through the differences, including why calling a promotional message transactional is a common source of trouble.

If no event in your system produced the message, it is probably marketing wearing a transactional costume, and it should be classified that way.

For transactional traffic the realistic expectation is speed plus verifiability. Messages submitted to a US number typically reach the network in seconds, but the word "typically" is doing real work: registration status, carrier filtering and number type all influence whether a message is accepted, and none of that is visible at submission time.

The honest way to run transactional messaging is to monitor delivery receipts rather than assume. A callback or receipt URL configured in the portal receives notifications when a message reaches its final state, and our published state and error codes let your systems act on failures: re-issue a code, retry a receipt, alert an operator. If you cannot prove a message was delivered, you cannot prove the customer was notified, and for a password reset that difference is a support ticket.

Receipts are also the audit trail that separates an operational metric from a story about what might have happened.

A common assumption is that transactional messages escape US registration because they are not marketing. They do not. Application-to-person traffic is defined by who sends it, an application on behalf of a business, not by what the message says, so transactional SMS from a 10-digit number requires 10DLC brand and campaign registration, and toll-free transactional traffic requires verification before A2P use.

Practically, this means registration must be planned as part of the launch, not added when you notice filtered traffic. Brand vetting can complete in hours to days, campaign vetting and carrier sync can take longer, so plan for days rather than hours. Our 10DLC page covers the process and the trust score that influences how carriers treat your traffic.

Toll-free transactional traffic goes through the same gate: unverified toll-free numbers have been blocked for A2P in the US and Canada since January 2024, so the sender decision cannot be deferred.

Mixing the two categories is the single most common cause of self-inflicted delivery problems. If a marketing opt-out suppresses transactional messages, a customer who replied STOP stops receiving their order updates, one-time passwords and reminders, which is exactly backwards. The categories have different consent rationale, different registrations (though the same sender platform) and different failure tolerance.

Good practice is to register separate campaigns for transactional and marketing traffic, keep marketing consent and transactional trigger separate in your data model, and treat STOP as applying to promotional messages while continuing to send the messages a customer's own actions imply. That is a practice area, not a hard rule you can copy from a blog post; the detail is in our comparison guide and compliance page.

The same separation belongs in your data model: one subscriber record with distinct consent and trigger states keeps a marketing opt-out from ever silencing an auth code. Build it that way and the category question mostly disappears.

Transactional messaging does not need a campaign builder; it needs an interface your code can call on every order, login and booking. WorldText is specialist SMS infrastructure: a documented HTTP API and SMPP on request, per-account credentials, delivery receipts, encoding control and registration support for US senders.

This is the layer that keeps transactional traffic out of a marketing calendar: the message goes out the moment the event happens, not when a scheduler runs. US destinations are priced at 8 credits per single-part message with multipart messages charged as multiple messages, and the same account covers your other markets. Build the flow once and it applies everywhere you send.

And a flow built for one market is not market specific: the same interface and credentials cover the UK and the rest of our footprint, so the integration is written once and used wherever you send. The plumbing is the same; only the sender registrations differ.