SMS Hardware Integration With a Retail POS System: Points, Failures and Records

The integration is not difficult; the difficult part is deciding which till events should produce a message and what should happen when the same event is processed twice. This article covers both.

It sets out which point of sale events justify a message, the three integration patterns and their trade-offs, why idempotency at the till matters, how to handle a message that must not be duplicated, and how to reconcile messages with the transactions that produced them.

Which POS events justify a message

Fewer than most implementations assume.

A point of sale system produces many events, and only some of them are worth a message. A receipt confirmation, an order-ready notification, a delivery window change and a loyalty balance alert are all events a customer may genuinely want. A basket update, a scan, a payment authorisation attempt and a stock adjustment are events that belong inside the system rather than on a customer’s handset. The distinction is whether the event changes something the customer needs to act on.

Two practical criteria narrow the list further. Whether the customer asked for it, which is a consent question addressed later in this article. And whether the message would still be useful if it arrived an hour late, since a message that is only valuable within seconds is not best delivered by SMS. Applying those two filters usually reduces the candidate list substantially, and the reduction is what keeps the message volume proportionate to what the subscription can sustain.

The other consideration is the relationship between the event and the transaction. A message that references a transaction is only useful if the reference means something to the customer, and a message that contains an order number the customer cannot see anywhere else is confusing. Keeping the message short, identifying the store, and giving the customer one clear piece of information is the pattern that survives contact with real customers.

Event	Worth a message	Why
Order ready for collection	Usually yes	The customer must act, and timing matters
Delivery window changed	Yes	Changes a plan the customer already made
Receipt confirmation	Sometimes	Depends on consent and local practice
Loyalty balance	Sometimes	Useful periodically, intrusive per transaction
Basket or scan update	No	Internal to the system, no customer action

Integration patterns: API, middleware or file drop

Three patterns, and the choice follows from the till rather than from the gateway.

A direct API integration has the point of sale system call the gateway’s interface when an event occurs. It is the simplest to reason about and the hardest to deploy widely, because it requires code in the point of sale application or a plugin, and retail systems are frequently locked down or centrally controlled. It is the right pattern when the retailer controls the software.

A middleware pattern places a small service between the till and the gateway. The till publishes events in whatever form it can, and the middleware decides which become messages, applies the pacing policy and submits them. This is the pattern that scales across a chain, because the message logic lives in one place and the points of sale do not need to change when it does. It also creates a single place where the send volume can be controlled, which is useful when a subscription has a rate limit.

A file drop pattern has the till write a file that a scheduled process reads and turns into messages. It is the least invasive and the slowest, and it is appropriate where the messages tolerate minutes of delay and the point of sale system cannot be modified. Its weakness is error handling: a malformed record in a file is easy to miss, and without a reconciliation step the failure is silent. The command interface that a middleware or file-processing service uses to submit and to read results is standardised, and the field definitions are described in 3GPP TS 27.005 and its ETSI TS 127 005 equivalent.

Idempotency at the till

The same event will be processed twice, and the design has to assume it.

Retries, reconnects, operator interventions and scheduled jobs that overlap all produce the condition in which the same business event is presented to the customer-facing system more than once. Without a mechanism to detect it, the customer receives two messages, and the second one is the one they complain about. The mechanism is an idempotency key: a value derived from the business event, such as a combination of transaction identifier and message type, that the sending system can check before dispatching.

Two properties make the key usable. It must be derived from the event rather than generated at the moment of sending, so that a retry produces the same key rather than a new one. And it must be checked at the point where the decision to send is made, rather than downstream of it, because a check that happens after the message is queued does not prevent the duplicate. Where the point of sale system cannot supply a suitable identifier, one can be derived deterministically from the transaction and the timestamp it carries.

The retained key set needs a retention period. Keeping keys indefinitely is unnecessary; keeping them for longer than the retry window plus the scheduled job interval is sufficient, and the period should be chosen deliberately rather than left at a default. A short retention on a system with a long retry window reintroduces duplicates, and this is one of the more common ways the mechanism fails in practice.

Handling a message that must not be duplicated

Some messages matter enough that a duplicate is a real cost.

A verification code, a collection code or a time-limited authorisation code falls into that category, because a duplicate can be confusing or, in the case of a code, actively unhelpful if the customer uses the wrong one. Three design measures apply to those messages. Give them their own idempotency key with a retention period longer than the code’s validity. Send them through a path with the fewest possible intermediate steps, since each step is an opportunity for a retry. And record the outcome, including the gateway’s confirmation, so that a disputed duplicate can be resolved from a record rather than from recollection.

The record is the part that is usually missing. Where the sending system records only that a message was submitted, a later question about whether the customer received two messages cannot be answered. Recording the submission and the confirmation, with the transaction reference and the destination, produces a record that can be reconciled against the point of sale’s own transaction log. The retention of those records is a policy decision with a technical implementation, and the practice for protecting and retaining them is described in NIST SP 800-92.

One further measure is worth considering for the highest-value messages: a rate limit that is specific to the message type rather than to the destination. A limit of one authorisation code per transaction, enforced at the sending system, is a simple control that catches the failure mode where a retry loop generates several codes for the same event.

Consent capture at the point of sale

The till is where consent can be captured accurately, and the message system is where it has to be respected.

Consent is a compliance question rather than an engineering one, and the rules that apply depend on the jurisdiction and the sector. What the integration can do is make the technical half reliable: record what the customer agreed to, when, at which store, and on what wording, and pass that record to the messaging system so that the send decision can be enforced automatically rather than by procedure. Capturing consent without a way to enforce it is a record rather than a control.

Three engineering supports belong in the integration. A per-customer flag with a provenance record, so that the reason for the flag is auditable. An enforcement point in the middleware where the flag is checked before the message is submitted, since a check only in the reporting layer does not prevent a send. And a withdrawal path that takes effect quickly, including where the withdrawal reaches the system through a route other than the till.

The identifiers involved should be recorded consistently, since the record is what makes the arrangement verifiable. The numbering used to reach a subscriber is defined in ITU-T E.164, and storing a normalised form rather than whatever the till captured avoids the situation in which the same customer appears under two formats and their preference record is split. Where the deployment touches regulated data, the retention period and the permission model belong to the compliance owner rather than to the integration team.

Reconciling messages with transactions

Reconciliation is what turns a sending system into an accountable one.

The reconciliation compares the transactions the point of sale recorded against the messages the system submitted and confirmed, and it produces three lists: messages sent for transactions that exist, transactions that should have produced a message but did not, and messages with no matching transaction. Each list has a different meaning. The first is the normal case. The second indicates a failure in the integration that a per-message success count would not reveal, because a message that was never submitted never appears as a failure. The third indicates a duplicate or a data error.

The check has to run on a schedule and produce an exception list rather than a report. A reconciliation that is run occasionally and read in full is a report; one that runs daily and raises only exceptions is a control. The distinction matters because the second one surfaces the same problem every day until somebody acts, and the first one is read once and filed.

The systems on either side of the integration need the ordinary operational attention, and the hardening expectations described in NIST SP 800-123 apply to both the messaging host and whatever holds the reconciliation output. Time synchronisation deserves a specific mention, since a reconciliation compares two systems’ records by time and will produce spurious exceptions if their clocks disagree; a single documented time source removes that class of false positive at no cost.

An SMS hardware integration outline for retail POS

The outline sequences an integration from the events that justify a message to the reconciliation that proves what happened. Each step produces a decision or a control, and the sequence is written to be agreed with the point of sale team before any code is written.

1. Event list agreed, filtered by whether the customer must act and whether consent exists.
2. Integration pattern chosen: direct API, middleware, or file drop.
3. Message templates defined with a transaction reference the customer can recognise.
4. Idempotency key derived from the business event, checked at the point of decision.
5. Key retention period set longer than the retry window plus any scheduled job interval.
6. Separate key and rate limit for codes and other messages that must not be duplicated.
7. Consent flag and provenance recorded, with enforcement in the middleware before submission.
8. Normalised subscriber numbering so a customer appears once in the preference record.
9. Submission and confirmation recorded with the transaction reference.
10. Daily reconciliation producing exceptions rather than a report, with a single time source.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “Which point of sale events should trigger an SMS?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Those that change something the customer needs to act on, such as an order becoming ready for collection or a delivery window changing. Filter the list by whether the customer asked for it and whether the message would still be useful if it arrived an hour late. Basket updates, scan events and payment authorisation attempts belong inside the system rather than on a customer handset.”
}
},
{
“@type”: “Question”,
“name”: “What is the best integration pattern for POS messaging?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “It follows from the till rather than from the gateway. A direct API is simplest where the retailer controls the point of sale software. Middleware scales best across a chain, because the message logic and the pacing policy live in one place and the tills do not change when they change. A file drop is the least invasive and the slowest, and it needs a reconciliation step because malformed records fail silently.”
}
},
{
“@type”: “Question”,
“name”: “How do I stop the same message being sent twice?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Use an idempotency key derived from the business event, such as the transaction identifier combined with the message type, and check it at the point where the decision to send is made rather than downstream. Retain keys for longer than the retry window plus any scheduled job interval. For codes and other messages that must not be duplicated, use a separate key with a longer retention and a per-transaction rate limit.”
}
},
{
“@type”: “Question”,
“name”: “How should consent be handled in a retail messaging integration?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Capture it at the till, where it can be recorded accurately, and enforce it in the middleware before the message is submitted. Record what the customer agreed to, when and on what wording, with a provenance record, and provide a withdrawal path that takes effect quickly. Consent rules themselves depend on the jurisdiction and sector, so the permission model belongs to the compliance owner.”
}
}
]
}