Delivery, DLR and Refunds

After a message is accepted, the platform sends it through Infozillion, records the route used for delivery and checks the delivery result. Eligible failed direct messages are refunded. Campaign delivery and refunds are handled through the campaign process.

How delivery works

flowchart TB
    Accepted[Message accepted and queued]
    Send[Send through Infozillion]
    Final{Final result available?}
    Check[Check delivery status up to nine times]
    Record[Update the recipient's message status]
    Refund[Refund an eligible failed direct message]

    Accepted --> Send --> Final
    Final -- Yes --> Record
    Final -- Not yet --> Check --> Record
    Record -->|Eligible failure| Refund

Hold "Ctrl" to enable pan & zoom

Sending happens after the initial request is accepted. Some provider responses give a final result immediately. Other messages require later delivery-status checks. The platform saves the result and refunds eligible failed direct messages.

Preventing duplicate messages

Before sending a group of messages, the platform marks it as being sent. If the same queued work is received again:

• work already sent is ignored;
• work already being sent is not sent again automatically;
• new work is marked as being sent before the provider is called.

This prevents normal queue retries from sending the same SMS twice. If sending is interrupted after the provider is called, an operator must check the provider record before resending or refunding the message.

How provider responses affect status and charges

Provider response	What the platform does
Code 9000 from an MNO when delivery reports are enabled	Marks the message SUBMITTED and starts delivery-status checks
Code 9000 from an IPTSP	Marks the message DELIVERED immediately
Code 9000 for a promotional message when delivery reports are disabled	Marks the message DELIVERED
Code 9000 for an OTP or transactional message without delivery reports, with MNO code 1000	Marks the message DELIVERED
Any other send rejection except 9099	Marks the message FAILED and refunds eligible direct-message costs
Code 9099	Marks the message DELIVERED, keeps it charged and does not check or refund it

Checking delivery status

For MNO messages that require a delivery report (DLR), the platform checks the status up to nine times on this schedule:

Attempt	Target elapsed time
1	3 minutes
2	10 minutes
3	30 minutes
4	1 hour
5	2 hours
6	6 hours
7	12 hours
8	18 hours
9	23 hours

How delivery results are classified

When the provider returns a delivery report, the platform checks the result in this order:

1. A number on the Do Not Disturb (DND) list becomes REJECTED with reason DND.
2. An invalid phone number becomes REJECTED with reason INVALID_MSISDN.
3. A number in the delivered list becomes DELIVERED.
4. A number in the undelivered list becomes FAILED with the provider's reason.
5. A missing or unknown number remains SUBMITTED and is checked again later.

If there is still no final result after the ninth check, the message becomes NOT_AVAILABLE. This means delivery could not be confirmed, and the message is not automatically refunded.

Refunds for direct messages

These refund rules apply to direct messages. Campaign refunds are handled as part of the campaign process.

A complete group fails

If a group is rejected because of a routing, configuration or sending error, the complete cost of that group is refunded. An OTP or transactional group contains one recipient, while a promotional group can contain several recipients.

One recipient fails

Each direct message with a final FAILED or REJECTED result receives its own eligible refund. A temporary balance-service problem does not remove the saved delivery result.

See Aggregator process flows, Client balance management, and the client-service Balance Operations API.