How to Compare A2P SMS Providers Using an Evidence Model

Why price and a stated DLR are not enough

Comparing A2P SMS providers solely by price, stated coverage, or an aggregated delivery percentage introduces operational risk. These indicators can conceal differences between countries, mobile networks, sender identities, traffic types, and operating conditions.

A route may accept a submission through the API and return a correct initial response without that describing the final outcome reported by the network. Likewise, a final delivery status reported by a provider should not be presented as independent confirmation that the recipient saw the message on their device.

The sourcing decision must separate cost from evidence. An offer is only comparable when its actual destination coverage, accepted traffic, supported sender identity, status reporting, and applicable restrictions are known.

• Do not treat initial API acceptance as proof of delivery.
• Do not consolidate results from different countries or networks into a single percentage.
• Do not assume a Sender ID is supported or displayed across all destinations.
• Do not accept a coverage claim without the associated operating conditions.

The evaluation model: statement, documentation, and observation

A useful model distinguishes three levels of information. The first is the provider statement: coverage, message types, capacity, sender identity, and available statuses. It is useful for prequalification, but it is not sufficient evidence for production.

The second level is documentary evidence: service terms, destination-specific restrictions, API or SMPP specifications, status catalogues, Sender ID policy, applicable limits, and error mapping. This documentation makes it possible to turn a commercial promise into verifiable requirements.

The third level is independent observation. It includes controlled testing, internal submission records, and, where feasible and authorized, observation of receipt or display on test devices. This observation does not prove that a recipient read the message; it only records what was observed on the test device under those conditions. It must be tied to a specific destination, network, content, sender identity, and time window.

• Statement: what the provider claims it can do.
• Documentation: how it defines, limits, and communicates the service.
• Observation: what happened in an identifiable and reproducible test.
• Decision: which use is authorized, under which limits, and until when the evidence remains valid.

Four dimensions that must be evaluated separately

Comparison becomes more reliable when it is divided into four dimensions. Each answers a different question and requires different evidence.

First, legality and restrictions: determine which legitimate traffic the route accepts, what requirements exist for senders, templates, preregistration, or local registrations, and which conditions apply in the destination country. Sender ID support and its requirements are not universal; some markets require preregistration, while others do not display the Sender ID to the recipient. Applicable requirements may also vary by sender type, sending entity, content, registration, and contractual relationship. Confirm local conditions with regulatory sources, operators, or competent advice.

Second, connectivity and operations: validate the available connection method, mandatory fields, identifier handling, asynchronous statuses, message lookup, and error documentation. In SMPP, network or SMSC errors may be specific to each network or implementation, so the provider must explain its mapping.

Third, capacity and continuity: distinguish submission acceptance, time spent in queue, and final outcome. A platform may record these dimensions separately; none of them alone demonstrates that capacity will be representative across all destinations or production scenarios.

Fourth, observable quality: measure segmented results, status sequence, latency, and the behavior of content and sender identity. As an evaluation methodology, segment by country, destination network where available, and sender identity where relevant. The evaluation must reflect what has been observed, rather than extending a limited sample into a general guarantee.

• Legality and restrictions: use case, applicable consent or other lawful basis, origin, and local requirements.
• Connectivity and operations: HTTP or SMPP, callbacks, status lookup, correlation, and errors.
• Capacity and continuity: acceptance, queueing, availability, and incidents.
• Observable quality: statuses, timing, segments, network behavior, and independent observation where performed.

Minimum information to request before testing a route

Before starting tests, request a destination-level prequalification sheet. As an internal standardization practice, record the destination in E.164 format and associate it, where possible, with the country and mobile network reported by the platform, network, or test instrumentation. This information is not always available and may not represent the effective operator in portability scenarios. The provider interface or workflow may require transformations or a different format, so its technical requirement must be confirmed. This standardization prevents non-comparable results from being mixed.

Ask the provider to describe which legitimate traffic types it accepts, for example OTP, transactional, or consented marketing. It must also state the permitted sender identities, Sender ID restrictions, preregistration requirements, applicable templates, and any market-specific conditions.

Request the message status catalogue, the meaning of each status, the delivery channel for asynchronous events or lookup mechanism, available identifiers, and error-code mapping. If the provider reports operational limits, these must be associated with the destination and traffic type to which they apply.

• Destination country and test numbers internally normalized in E.164.
• Accepted traffic type and excluded use cases.
• Permitted sender identity and Sender ID conditions.
• Applicable regulatory requirements, registrations, or templates.
• DLR statuses, the meaning of each status, and lookup or callback method.
• Provider identifier, correlation identifier, and error mapping.
• Operating conditions and the information validity date.

How to design controlled tests without turning a sample into a guarantee

A test must answer a limited question. For example: whether a particular sender is accepted for legitimate OTP traffic to a specific network, whether correlatable final statuses are received, or whether a multipart message retains expected behavior. Do not attempt to prove the overall quality of a route with a single test campaign.

Define the destination set, observation period, use cases, sender identities, authorized content, and test devices in advance. Keep constant the elements you are not evaluating. If content, sender, and destination all change at the same time, you will not be able to attribute the outcome.

Include single-part and multipart messages, and record the encoding used. In SMPP, data_coding identifies the encoding scheme. Segmentation and effective limits also depend on elements such as UDH or SAR, the alphabet used, the provider interface, the SMSC implementation, and the network. Therefore, a short-content test does not by itself validate segmented messages or messages using another encoding.

For OTP, set an explicit evaluation time window and prepare an operational contingency. Delivery receipts are asynchronous, and delivery may be delayed if the device is unavailable. A late DLR should not automatically be interpreted as a sufficient signal for a time-sensitive use case.

• Formulate one specific hypothesis per test.
• Segment by country, network, use case, and sender identity.
• Test single-part and multipart messages, with encoding recorded.
• Use legitimate, authorized content that represents the use case.
• Define an observation window before sending.
• Do not extrapolate the sample to untested destinations, networks, or volumes.

What to record in every test

Traceability depends on being able to reconstruct the history of every message. Retain both the identifier assigned by the provider and an internal correlation identifier. In SMPP, a reference assigned by the ESME may be used, and the delivery receipt may include the identifier that the SMSC assigned to the original message. The actual use and return of these references or fields depend on the SMSC or provider implementation.

Record timestamps for submission acceptance, status changes, final status, and observed receipt where it has been performed. The delivery receipt format described in SMPP includes submit date and done date, although the specific format may vary by SMSC or provider. Done date indicates when the message reached a final status. These timestamps make it possible to separate technical acceptance, message progression, and available independent evidence.

The record must preserve context. Without the destination, the network reported by the platform, network, or test instrumentation where available, the sender, the content or content fingerprint, the encoding, the number of segments, and the use case, it is not possible to interpret a status correctly or compare later tests. Evidence of consent or another lawful basis must be retained in accordance with applicable regulations, purpose, and jurisdiction.

• Internal correlation ID.
• Provider or SMSC message ID.
• Destination number internally normalized in E.164.
• Destination country and network reported by the platform, network, or test instrumentation where available.
• Use case and evidence of applicable consent or other lawful basis, retained in accordance with applicable regulations, purpose, and jurisdiction.
• Tested content or a fingerprint that can identify it without exposing unnecessary data.
• Sender ID or sender identity.
• Encoding and number of segments sent and observed where that data is exposed, if relevant to the test performed; do not turn a single-part test into evidence for segmented messages or messages using another encoding. (The SMPP specification makes explicit the relationship between data_coding, payload limits, and network/SMSC-dependent behavior.)

How to interpret DLRs, latency, and availability

DLRs are valuable operational signals, but their meaning depends on the interface and provider. SMPP defines, among other statuses, final states such as DELIVRD, EXPIRED, UNDELIV, and REJECTD, and also includes DELETED and UNKNOWN. The specific receipt format may be specific to the SMSC provider. The evaluation sheet must document how each status and code is translated into an operational cause.

Do not confuse different statuses. For example, in a provider-specific terminology, an acceptance status may represent acceptance by an upstream provider, while a delivery status may depend on confirmation available from the carrier and, where available, from the destination device. This is not a universal definition of SMPP or all DLRs: terminology and semantics are specific to each provider and must be verified in its documentation. Even where confirmation from the carrier or device is documented, it is not equivalent to independent device observation performed by the evaluation team, nor does it prove that the recipient read the message. No status should replace independent observation when it is needed to validate a test hypothesis.

Measure latency by stages: submission time, acceptance, last status received, final status, and observed receipt where applicable. Reporting a single average can conceal delays that matter for an OTP flow. For consented marketing, timing criteria may differ, but they must also be defined before the test.

Availability must be observed together with incidents and recovery. Record rejections, connection failures, lost or delayed events, semantic changes, and differences between lookup and callbacks. A route that appears available but does not provide sufficient traceability may not be suitable for a use case requiring auditability.

• Classify each metric by message lifecycle stage.
• Retain the sequence of status changes, not only the last status.
• Request documented mapping for provider-specific errors and statuses.
• Analyze results by destination segment, not only in aggregate.
• Distinguish evidence of a reported status from observed receipt.

Provider evaluation sheet and decision criteria

The evaluation sheet must turn comparison into a reviewable decision. For each question, state which evidence is accepted, who validates it internally, when it was obtained, and when it expires. An unverified claim must remain marked as a statement, not as an approved capability.

Define an outcome by use case and destination: approved, approved with restrictions, pending evidence, or rejected. Avoid a generic “approved” status for the entire provider. The same counterparty may be suitable for a transactional flow in one destination while not being validated for Sender ID, consented marketing, or OTP traffic in another.

Evidence must be reviewed periodically. Callback parameters and event property sets may evolve, and operating restrictions can also change. Design integrations that tolerate additional parameters, and maintain an expiry date for documentation and tests.

• Question: which destination, traffic type, and sender identity are being evaluated?
• Acceptable evidence: current documentation, test records, and correlated statuses.
• Outcome: approved, restricted, pending, or rejected.
• Conditions: usage limits, sender, content, or registration requirements.
• Control: review date and internal owner.
• Follow-up: open incidents, detected changes, and necessary regression testing.