Acceptance Testing for A2P SMS Provider Changes: How to Validate Before Cutover
A guide to agreeing on reproducible tests for connectivity, responses, callbacks, and statuses before migrating A2P traffic. Technical acceptance is not the same as confirming that an SMS reached a handset.
What acceptance testing validates—and what it does not
Acceptance testing checks whether an integration and its operation behave according to the agreed requirements for a specific use case. When changing an A2P provider, it can verify that the system sends requests, interprets responses, processes callbacks, and records the required events.
Technical acceptance alone does not prove that an SMS reached the recipient’s handset, nor does it guarantee that observed performance will continue after cutover. A successful HTTP response confirms a response from that interface, not final message receipt. Likewise, a reported delivery status should be treated as information from the system that issued it, not as independent proof of receipt on the device.
- Define separately what the interface validates, what the provider reports, and what evidence exists about delivery.
- Document test limits: environment, destinations, senders, message types, observation window, and external dependencies.
Define scope and responsibilities
Before running tests, agree on what is being added or migrated. Specify the interface in use—HTTP or SMPP—the destinations and senders included, the permitted message types, and which system is responsible for each stage. For SMPP, the SMPP v3.4 specification can serve as a technical reference when agreeing on parameters and responses; confirm specific details against the version and integration profile agreed upon.
Do not assume that all providers interpret every field, status, or operational behavior in the same way. Prepare a requirements matrix specifying, for each case, the expected request, the response to be recorded, who produces it, and how to determine whether it passes or fails. Acceptance criteria and conditions for pausing or reversing the change are project decisions, not universal thresholds.
- Record the interface, applicable version or profile, and the configuration being tested.
- Define the included destinations, senders, and traffic categories; state exclusions explicitly.
- Assign responsibilities for the customer, provider, and any intermediary systems.
- Agree in advance on acceptance criteria, blocking issues, and conditions for pausing or reversing the change.
Prepare the environment and test data
Use an authorized test environment and traffic, with scope agreed by all parties. If the infrastructure cannot be fully separated from production, document which components are shared and how impact will be limited. Do not send messages to numbers or people without authorization.
Include only the data needed to run and diagnose each case. Define who can access logs, how they are protected, and how long they are retained, in accordance with applicable policies and obligations. General technical sources do not establish a universal process for isolation, consent, or retention; confirm these aspects against current rules and with the relevant owners.
- Confirm authorization, test destinations, and senders before sending traffic.
- Use test identifiers that can be distinguished from production identifiers, if the integration allows it.
- Avoid including unnecessary personal data in message content, logs, or screenshots.
- Make sure the team knows how to stop the test if traffic goes beyond the agreed scope.
Build positive and negative test cases
A useful test does more than send a valid message. It should also check how the integration behaves when it receives invalid inputs, unexpected responses, or interruptions. HTTP semantics are defined by RFC 9110, but what a response means for an SMS workflow also depends on the integration contract and design.
For every case, record the expected result and the evidence that will be used to compare it. Do not invent error codes or assume that a behavior is common to all providers: confirm applicable values and rules in the agreed technical documentation.
- Valid case: required fields are present and values follow the agreed format.
- Invalid case: a required field is omitted or a format is not accepted, as specified in the interface contract.
- Rejection: a request the provider does not accept; verify that the client preserves and classifies the response correctly.
- Timeout or interruption: check how uncertainty is recorded and what follow-up action is authorized; avoid automatic retries that could duplicate messages unless a rule has been agreed.
- Traffic limit: test only authorized volumes and conditions, with limits defined by the project.
Verify identifiers, callbacks, and traceability
Check that each submission can be linked to its response and to any subsequent events included in the integration. Agree on which identifier each system returns or generates, where it is recorded, and how it is linked to callbacks. Do not assume identifiers share the same format or scope across platforms.
Also test the callbacks that are actually configured: receipt, authenticity according to the agreed mechanism, duplicate handling, and recording of processing failures. Expected behavior should be defined by the specifications and integration agreement; there is no universal rule that can be inferred from an event name alone.
- Correlate requests, responses, and callbacks using the available, documented identifiers.
- Record the date and time, environment, test destination, result, and configuration version needed to reproduce the case.
- Check that a callback is not attributed to another submission and that repeated events are handled according to the agreed rule.
- Store technical evidence with appropriate access controls and retention, avoiding exposure of secrets or unnecessary data.
Interpret statuses and DLRs with caution
Include in the matrix the statuses agreed upon by the integration and provider, but do not treat status labels as universal. Document who originates each status, what it means in that system, and what uncertainty remains. If an event does not arrive, arrives late, or differs from the expected result, record it as a discrepancy to investigate, not as an automatic conclusion about the handset.
A DLR or status reported by a provider is not necessarily equivalent to independent verification that the recipient received the message on their device. The test should distinguish the consistency of the status report from any additional evidence of receipt, if such evidence exists and is accessible.
- Compare observed statuses with the documented definitions for that integration.
- Record missing, late, repeated, or difficult-to-correlate events.
- Do not turn a reported status into a guarantee of handset receipt.
Measure availability and latency without extrapolating
If availability, latency, or consistency will be evaluated, agree on the observation window, measurement points, test population, and calculation method for each metric. Separate interface response time from the timing of subsequent statuses: they measure different stages.
There are no universal figures for latency, availability, sample size, or traffic limits that serve as acceptance criteria for every project. A small sample limited to certain destinations also cannot be used to generalize future performance. Define thresholds with the parties according to intended use and the applicable agreement, and describe what is excluded from measurement.
- Specify the start and end points for each measurement.
- Record the observation window, number and scope of tests, without presenting the sample as representative if it is not.
- Distinguish results by interface, destination, and event type when the dataset allows.
- Compare results only with criteria approved before observing them.
Close acceptance with evidence and a reproducible decision
Consolidate the results in a record that another person can review and reproduce. For each case, include relevant configuration, non-sensitive test data, expected result, observed result, evidence reference, owner, and associated issue. Keep observations separate from interpretations.
The final decision should state what was approved, what remains conditional, and who authorized it. If a test fails or cannot be run, document the limitation and agree on the next step before cutover. Explicitly set the pause or rollback procedure with the owners; no universal technical condition can replace that decision.
- Keep the test-case matrix and results log in a controlled location.
- Classify issues according to agreed impact, and assign an owner and follow-up date.
- Document test coverage limits and unverified dependencies.
- Record approval, outstanding conditions, and the agreed procedure for stopping or rolling back.
Frequently asked questions
Does a successful HTTP response confirm that the SMS was delivered?
No. It confirms a successful response from the interface under the applicable HTTP semantics. By itself, it does not prove that the message reached the handset.
Does a DLR confirm that the recipient received the message on their device?
Do not assume so. A DLR is a status reported by the system that issued it; it is not necessarily independent verification of receipt on the handset.
What latency or availability thresholds should I use to approve a provider?
There are no universal figures suitable for every case. Agree with the parties on the observation window, measurement points, scope, and thresholds according to intended use and the applicable agreement.
What should I test before cutover?
At a minimum, agree on cases for valid and invalid inputs, responses, timeouts, authorized limits, identifier correlation, callbacks, and statuses included in the integration. Add acceptance criteria and conditions for pausing or rolling back.
Does acceptance testing guarantee performance after migration?
No. It describes behavior observed in a specific environment, scope, and window. It does not guarantee future results or support generalization beyond the evidence obtained.
Sources consulted
- SMPP Protocol Specification v3.4SMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- 3GPP specifications by series3GPP
- E.164: The international public telecommunication numbering planInternational Telecommunication Union
- GSMA networks resourcesGSMA