SMS Delivery States¶
When an SMS is processed, it will be in various states. Some of those states are intermediate and some are final.
The diagram below provides an overview of the various states, and how the SMS can change between them. The intermediate states are all symbolized with round boxes, and final states with rectangular boxes. The SMS starts out with the placeholder status UNKNOWN when we receive it but when we start processing it will quickly change to other states. Once a final state is reached, we will no longer send any status notifications for the SMS.
The usual path for message state are: Buffered, Enroute, Delivered. Although many providers will skip some states, such as Buffered. This state is rarely seen as the messages often goes directly to routing which instead emits the Enroute status.
Undelivered and Rejected are also fairly common states, which indicate that the SMS could not be delivered to the recipient. This may be due to problems with the SMS such as the recipient MSISDN not being in active use or perhaps country specific restrictions.
We try to deliver DSNs in a logical order, but sometimes they may arrive at your webhook in the wrong order where you receive a transient state after already having received a final state. In this case you should ignore the transient state.
|UNKNOWN||No||Initial value for before processing begins, waiting for actual status.|
|SCHEDULED||No||Used for messages where you set a sendtime in the future.|
|BUFFERED||No||The message is held in our internal queue and awaits delivery to the mobile network.|
|ENROUTE||No||Message has been sent to mobile network, and is on its way to its final destination.|
|DELIVERED||Yes||The end users mobile device has confirmed the delivery, and if message is charged the charge was successful.|
|EXPIRED||Yes||Message has exceeded its validity period without getting a delivery confirmation. No further delivery attempts.|
|DELETED||Yes||Message was canceled.|
|UNDELIVERABLE||Yes||Message is permanently undeliverable. Most likely an invalid MSISDN.|
|ACCEPTED||Yes||The mobile network has accepted the message on the end users behalf.|
|REJECTED||Yes||The mobile network has rejected the message. If this message was charged, the charge has failed.|
|SKIPPED||Yes||The message was accepted, but was deliberately ignored due to network-specific rules.|
Depending on how the SMS is received by our systems the delivery notification will take on different forms.
The status is of course also available in the SMS traffic log.
In addition to the regular SMS state, when sending overcharged SMS messages, each SMS will also have a charge status. Just like the regular status, the initial value is a placeholder, which in this case is NOCHARGE.
The REFUND_FAIL status is just a notification, and the actual status will still be CAPTURED.
The normal flow will go from AUTHORIZED to either FAILED or CAPTURED.
|NOCHARGE||Initial value before processing begins. Waiting for actual status.|
|AUTHORIZED||The transaction is authorized|
|CANCELLED||The transaction is cancelled or timed out|
|CAPTURED||The transaction is captured and the amount will be charged from the recipients phone bill|
|FAILED||The transaction failed. Usually because overcharged SMS messages are blocked on the phone number.|
|REFUNDED||A previously captured transaction has been successfully refunded to the phone owner|
|REFUND_FAIL||The refund procedure failed.|
The overcharged SMS sevice is only implemented in the REST API.