Smart Pay API integration & eVoucher OpenData services

A live view of mobile-money distribution in Sri Lanka

According to the official Google Play listing, Smart Pay serves thousands of registered retail outlets across the country, with the merchant app last refreshed on 4 March 2024 and a 5.0-star rating across more than 120 reviews. That footprint translates into a unified data layer covering top-up issuance, denomination mix and operator share, all of which become actionable when surfaced through a clean API.

Sits on top of national network APIs

Sri Lanka’s four mobile operators — Dialog Axiata, SLT-Mobitel, Hutchison Telecom and Bharti Airtel Lanka — jointly launched country-wide Network APIs (OTP validation, device location, carrier billing) and continue to expand them through 2024–2025. A Smart Pay integration layer naturally complements those APIs by adding the retail eVoucher distribution dimension that the operator APIs themselves do not expose.

Bridges OpenFinance with prepaid airtime

Prepaid reload data is one of the few signals that lets fintechs, lenders and ad-tech platforms profile the ≈75% of mobile users in Sri Lanka who remain on prepaid plans. By surfacing Smart Pay merchant transactions via OpenData endpoints, you can feed credit-scoring models, telecom analytics dashboards and KYC-light onboarding flows.

1. Merchant authentication

Replays the Smart Pay login flow (mobile number + PIN + SMS OTP), keeps the session token alive and rotates device identifiers safely. Used to bind external dashboards to a merchant account without storing the raw PIN.

2. Reload issuance API

Wraps the eVoucher purchase endpoint with idempotency keys and per-operator routing logic (Dialog → op=DLG, Mobitel → op=MBT, Hutch → op=HTC, Airtel → op=AIR). Used by retail-network HQs to push reload jobs from a CRM into hundreds of outlets at once.

3. Transaction history export

Paged history endpoint covering reload reference, MSISDN destination (masked when required), denomination, commission, status and timestamp. Used to feed QuickBooks, Zoho Books or Tally without manual CSV uploads.

4. Float & commission ledger

Reads the merchant’s float wallet, settled commissions and pending payouts. Used by distributors to set automated low-float alerts and to pre-fund retailers before peak hours.

5. Reconciliation & settlement feed

Daily settlement report aligned with operator clearing files, including failed-reload reversals and FX-style discount lines. Used by finance teams to close books in under 30 minutes per branch.

6. Webhook notifications

Outbound webhooks for new transactions, reload failures, low float and PIN-lock events. Used to drive Slack/Teams alerts and to trigger refill workflows in operations tools.

Scenario 1 — Multi-outlet distributor dashboard

A distributor operating 200+ retail outlets needs a single web view of every reload pushed through Smart Pay. The integration polls /transactions?since=... per merchant token, normalises the operator codes (DLG/MBT/HTC/AIR) and writes to a PostgreSQL warehouse. Power BI and Metabase then visualise hourly turnover, top-selling denominations and outlet ranking. This maps to OpenData “read aggregated activity” semantics without ever moving customer PII out of the operator perimeter.

Scenario 2 — ERP & accounting sync

Retail chains with SAP Business One or Zoho Books need every commission line booked automatically. We schedule a nightly export of the commission ledger and reversals, transform the rows into the chart-of-accounts mapping (e.g. revenue, operator-payable, retailer-payable) and POST them through the ERP’s journal API. Reconciliation against operator settlement files closes the loop, mirroring the OpenFinance pattern of “account information service” over telco prepaid float.

Scenario 3 — Embedded reload in a partner super-app

A super-app or fintech such as a digital wallet wants to embed top-ups without negotiating four separate operator contracts. By exposing the Smart Pay reload endpoint behind a thin REST facade with Bearer auth and idempotency, the partner can issue an eVoucher in one call: POST /reload {op, msisdn, amount}. Each call is logged for audit and pay-per-call billing, which is the same model the studio uses for production traffic.

Scenario 4 — Credit scoring & risk control

Microfinance lenders use historical reload velocity as a thin-file credit signal. We expose a /insights/{merchant_id} endpoint that returns aggregated 30/60/90-day reload volume, operator mix and reversal ratio — never the raw MSISDN list. The lender’s scorecard ingests this OpenData feed alongside CRIB data to underwrite working-capital loans for retailers.

Scenario 5 — NOC alerting & SLA enforcement

A network operations centre subscribes to Smart Pay webhooks and watches for spikes in failure codes per operator. When Mobitel reload failures cross 2% in a 5-minute window, the integration auto-pages the on-call team and flips the routing logic to alternate APIs (e.g. a Reloadly or syscomm fallback) until the operator recovers.

Authentication & session

POST /api/v1/smartpay/login
Content-Type: application/json

{
  "merchant_msisdn": "94715171171",
  "pin": "******",
  "device_id": "smp-3f2-9c1",
  "app_version": "tellko.smartpay/2024.03"
}

Response 200:
{
  "merchant_id": "SMP-LK-44129",
  "access_token": "eyJhbGciOi...",
  "refresh_token": "rt_8a72...",
  "session_ttl": 3600,
  "otp_required": false
}

Issue an eVoucher reload

POST /api/v1/smartpay/reload
Authorization: Bearer <ACCESS_TOKEN>
Idempotency-Key: 9b4d2c-2025-04-23-001

{
  "operator": "DLG",        // DLG | MBT | HTC | AIR
  "target_msisdn": "94771234567",
  "amount_lkr": 500,
  "channel": "evoucher"
}

Response 201:
{
  "reload_ref": "RL-44129-77831",
  "status": "SUCCESS",
  "operator_ref": "DLG-7781923",
  "commission_lkr": 12.50,
  "completed_at": "2026-04-23T08:14:51+05:30"
}

Errors: 4001 INSUFFICIENT_FLOAT,
        4002 OPERATOR_DOWN,
        4003 INVALID_MSISDN

Statement / history export

GET /api/v1/smartpay/statement?from=2026-04-01&to=2026-04-23&op=ALL&page=1
Authorization: Bearer <ACCESS_TOKEN>

Response 200:
{
  "page": 1, "page_size": 100, "total": 1842,
  "items": [
    {
      "reload_ref": "RL-44129-77831",
      "operator": "DLG",
      "amount_lkr": 500,
      "commission_lkr": 12.50,
      "status": "SUCCESS",
      "ts": "2026-04-23T08:14:51+05:30"
    }
  ]
}

Webhook for low float / failure

POST https://your-app.example/webhooks/smartpay
X-Smartpay-Signature: t=1745390000,v1=...
Content-Type: application/json

{
  "event": "float.low",
  "merchant_id": "SMP-LK-44129",
  "operator": "MBT",
  "current_float_lkr": 1200.00,
  "threshold_lkr": 5000.00,
  "ts": "2026-04-23T08:20:00+05:30"
}

// Recommended: verify HMAC, queue, then ack 200 within 5s.

Sri Lankan regulatory context

All integrations are scoped to comply with the Personal Data Protection Act, No. 9 of 2022 (PDPA), which is overseen by the Data Protection Authority of Sri Lanka and is being rolled out in phases through 2025–2026. Where the merchant data touches financial flows we also align with Central Bank of Sri Lanka (CBSL) Mobile Payment Guidelines, the Payment and Settlement Systems Act No. 28 of 2005, and TRCSL rules covering mobile network airtime distribution.

Authorization model

We only operate on data the merchant or distributor explicitly authorises us to access — mirroring the OpenBanking “account information service provider” pattern. Consent records, scope strings (e.g. scope=transactions:read float:read reload:write), and revocation events are persisted for audit. PII fields such as customer MSISDN are masked by default and only revealed when the use case requires it.

Security baseline

TLS 1.2+ end-to-end, AES-256 at-rest encryption for cached merchant tokens, HMAC-signed webhooks, IP allow-listing per merchant ID and structured audit logs forwarded to your SIEM. Where required, NDAs and data-processing addendums are signed before any production credentials are exchanged.

Deliverables checklist

• Protocol & auth flow report (OTP login, token rotation, device binding)
• OpenAPI / Swagger specification for login, reload, statement, float and webhooks
• Runnable source code in Python and Node.js (FastAPI + Express samples)
• Postman collection and integration test suite
• Compliance addendum referencing PDPA 2022, CBSL guidelines and TRCSL rules
• Deployment notes for Docker / Kubernetes and a sample Grafana dashboard

Two engagement models

• Source-code delivery from $300 — You receive the runnable adapter, full documentation and test cases; payment is settled after you have validated the build in your environment.
• Pay-per-call hosted API — Skip ops work entirely: hit our managed endpoint and pay only for successful calls. Suited to teams with bursty traffic or pilots.

About our studio

We are an independent technical service studio specialising in App interface integration and authorised API integration. Our team has years of hands-on experience in mobile applications and fintech, with delivery focused on protocol analysis, interface refactoring, OpenData integration, third-party interface integration, automated data scripting and complete API documentation.

• Financial & banking apps — transaction records, statement query interfaces, transaction integration
• E-commerce, food delivery and retail apps — order interfaces, payment integration, data synchronisation
• Hotel, travel and mobility apps — booking interfaces, itinerary queries, payment verification
• Social, OTT media and dating apps — auth/login, messaging interfaces, profile management
• Telco / reload / eVoucher apps such as Smart Pay — merchant workflows, settlement and float APIs

Contact

Tell us your target app and the data you need exported, ingested or re-issued. We will respond with a scope confirmation, timeline and pricing within one business day.

Open the contact page

For Smart Pay merchant onboarding directly with Tellko Technologies, the listed support number on the Google Play page is 0715 171 171 (Sri Lanka).

Engagement workflow

1. Scope confirmation — agree on which Smart Pay flows are in-scope (login, reload, statement, float, webhooks).
2. Protocol analysis & API design — 2–5 business days depending on operator coverage.
3. Build & internal validation — 3–8 business days, with daily progress notes.
4. Documentation, samples and test cases — 1–2 business days.
5. Typical first delivery: 5–15 business days; third-party operator approvals may extend timelines.

FAQ

What do you need from me to start a Smart Pay integration?

How long does delivery take for Smart Pay specifically?

How is compliance handled with PDPA and CBSL rules?

Can you offer pay-per-call instead of source-code delivery?