submit_sm_resp beyond the standard SMPP set. This is the whole list.
What each is deliberately not
0x402 is not ESME_RTHROTTLED. Throttled tells a client to back off and retry, which is exactly
wrong for a condition only a top-up or an invoice can clear. A client that retries a credit refusal
burns its own capacity achieving nothing.
Prepaid and postpaid refuse identically.
0x402 over SMPP, 402 with insufficientCredit over
HTTP, whichever mode the account is in. A customer’s integration does not need to know which they are
on.0x14 is a well-behaved backpressure signal. An ESME that respects it backs off and retries. This
is the one refusal here that a client should retry.
0x40F carries one code and two distinct WARN lines — blank product versus unknown name. The
client only ever sees the number, so the log is where those are told apart.
Vendor-side classification
Codes a vendor returns are classified bystatus.retry.worker and status.retry.router — see
Vendor settings.
ESME_RSUBMITFAIL (0x45, decimal 69) is treated as permanent. It is genuinely ambiguous across
SMSCs — some mean transient overload — so it is a per-vendor opt-back-in rather than a global
reclassification.
Where a refusal is recorded
Nothing refused at ingress is charged. The REST path charges before it publishes, so a queue-full
refusal there refunds; the SMPP path refuses before accepting, so there is nothing to refund.
See Refusals for reading them back.