Skip to content

Routing, Pricing and Compliance

Routing decides which sender ID, mobile operator connection and price apply to each SMS. Before accepting a request, the platform checks that the required routing and pricing setup is active. It records the original route, the route used for delivery and the charge details for later review.

How routing is configured

flowchart TB
    MNO[MNO or IPTSP group] --> Credential[MNO credential]
    MNO --> Channel[SMS channel]
    Credential --> Sender[Client and operator sender]
    Channel --> Sender
    Sender --> CLI[Allowed sender IDs / CLIs]
    CLI -->|optional| Alternate[Fallback route]
    Channel --> Rate[Client billing rate]
Hold "Ctrl" to enable pan & zoom
Routing item What it controls
MNO/IPTSP group Identifies the connection type and whether it supports long SMS messages
MNO user Stores the MNO credential identity, billing phone number when required, status and intended sending rate
Channel Groups messages by MNO/IPTSP, SMS type, masking type and status
Sender Allows a client username to use a channel, credential and one or more sender IDs (CLIs) for an operator
Fallback rule Chooses whether an exact or wildcard sender ID uses the primary or fallback route
Billing rate Stores the price per SMS part and the one-time DI price for a client, channel and operator

Only platform operators can change routing and pricing settings.

How a route is selected

For each recipient, the platform:

  1. identifies the Bangladesh mobile operator from the phone-number prefix;
  2. finds an active sender setup matching the client, operator, requested sender ID and SMS type;
  3. selects an active MNO or IPTSP credential;
  4. finds the configured price for the client, channel and operator;
  5. saves the selected price and initial route with the message.

Every recipient must have a valid route and price. If one recipient cannot be routed, the complete direct-message request is rejected and is not charged.

Sender ID and fallback-route rules

A sender setup can allow several exact sender IDs, also called CLIs. Clients can only submit those allowed values. Each allowed CLI initially has an authorization-only PRIMARY entry with no secondary sender or fallback sender ID. Operators can use a wildcard * in a fallback rule, but a client cannot submit * as its sender ID.

The platform applies these rules:

Rule Example
An authorization-only exact entry defers to a wildcard rule If ACME has its initial PRIMARY entry with no fallback configuration and * selects a secondary route, ACME uses the wildcard fallback
An explicitly configured exact rule is used before a wildcard rule If ACME has secondary-route details, its rule is selected instead of *
An invalid explicit exact rule does not switch to the wildcard rule If the configured ACME rule points to an inactive route, dispatch fails instead of using *
activeRoute=PRIMARY on an explicit rule uses the normal sender route If a configured ACME rule is set to PRIMARY, it takes precedence over * but uses the channel and MNO credential on the main sender setup
activeRoute=SECONDARY uses the configured fallback route If ACME is switched to SECONDARY, the message uses the fallback channel, MNO credential and sender ID
Both the submitted and dispatched routes are recorded If the client submits ACME but the fallback sends as ACME-BACKUP, the platform keeps the original and effective sender, credential and channel values

Updating fallbackRoute replaces the complete fallback-rule list for that sender setup. To retain an exact rule while adding *, operators must submit both rules in the update. An omitted exact rule returns to its authorization-only PRIMARY entry, while an omitted wildcard rule is removed.

Finalized reports retain the submitted route and expose the effective dispatched route. Sender filters, channel summaries and channel-failure alerts use the effective sender or channel when a fallback route was dispatched.

Operators choose when to use the fallback route. The platform does not switch automatically because of a provider error or service-health change.

Sending through MNO and IPTSP connections

Mobile network operator (MNO) and Internet Protocol Telephony Service Provider (IPTSP) connections require slightly different information:

  • An MNO connection requires a billing phone number (billMsisdn).
  • An IPTSP connection does not require a billing phone number; it uses the final sender ID instead.
  • Promotional messages are sent with provider type P; OTP and transactional messages use type T.
  • Bangla and other UCS-2 messages use provider message type 3; GSM-7 messages use type 1.
  • The provider is told whether the selected connection supports long SMS messages.

MNO and IPTSP passwords are encrypted when stored. Operator tools may display the decrypted password, so these responses must be kept private and must not be logged.

How SMS parts and prices are calculated

Long messages are split into billable SMS parts. The number of characters that fits in each part depends on the message encoding:

Encoding Typical content One-part limit Limit per part in a longer message
GSM-7 Basic English letters, numbers and common symbols 160 units 153 units
UCS-2 Bangla and other characters outside GSM-7 70 units 67 units 
recipient cost = (SMS parts × rate per part) + DI price
  • The rate is set for a specific client username, channel and operator.
  • The DI price defaults to zero and is charged once per recipient.
  • Personalized values are inserted before the platform counts SMS parts and calculates the cost.
  • A campaign keeps the rate and cost saved when it was accepted, even if an operator changes the rate later.
  • New messages use the latest configured rate.

BTRC rules for promotional messages

For promotional campaigns, the platform requires:

  • an operator-approved promotional campaignId;
  • Bangla content (lang=bn);
  • a sending time inside the configured Dhaka-time promotional window;
  • phone numbers with supported Bangladesh operator prefixes.

The approved campaign ID is included when the message is sent to the provider. The default promotional window is from 09:00 until, but not including, 24:00 in Dhaka time. Operators can update this setting when the approved BTRC window changes.

See the Routing Configuration API, router routing decision, and aggregator effective routing.