SMPP Delivery Receipts: deliver_sm Format, Statuses and How to Test Them
How SMPP delivery receipts (DLRs) are built, what each stat value means and how to test every outcome with an SMSC simulator.
Guide
Failure handling is the part of SMS software that is hardest to test against a real provider. Here is how to make it repeatable.
Real networks fail rarely and unpredictably, which is exactly what makes failure handling hard to test. A sandbox turns that around: you choose how often and how late things go wrong.
| Outcome | Receipt stat | What your code should usually do |
|---|---|---|
| Delivered | DELIVRD | Mark done |
| Not delivered | UNDELIV | Report failure, maybe try another route or channel |
| Expired | EXPIRED | Treat as failed after the validity period |
| Rejected | REJECTD | Do not retry the same content blindly |
| Pending / unknown | ACCEPTD / UNKNOWN | Wait, then time out |
The exact receipt text differs between providers, so map by status and keep the raw text in your logs.
For each client account in the Maxi panel, a scheme defines the delay before the report is sent and the share of messages ending in each status. Some useful setups:
Combined with the live queue and statistics in the panel, you can compare what the sandbox did with what your application believes happened.
Want to try this against a real SMPP endpoint? Register for the sandbox and use it free for 3 days, or tell us about your scenario.
How SMPP delivery receipts (DLRs) are built, what each stat value means and how to test every outcome with an SMSC simulator.
The cases your OTP and 2FA code must survive, and how to reproduce each one safely with a sandbox.
The SMPP v3.4 command_status codes you will meet in practice, which ones are worth retrying, and how to make your client handle them.
Get your SMPP sandbox in minutes and use it free for 3 days - or tell us what you are building and we will help you choose a plan.