Home›Telecom›Revenue›Payment← All modules
Revenue · BSS module

Payment Module

The Payment module abstracts all payment channel complexity behind a single interface — routing payment requests from Collection to the appropriate financial institution and returning a unified result regardless of the payment method used.

Credit Card Direct Debit Walk-in Payment Card Tokenisation Payment Result Propagation Payment History
On this pageAt a glancePayment Flow — End-to-EndPayment ChannelsCard Security — TokenisationComponent ResponsibilitiesStorage & PersistenceDesign PrinciplesWhere AI helpsStandards

At a glance

Takes payments through every channel and applies them to customer accounts.

Key data

PaymentPayment method / tokenRefundAllocation

Receives from

  • eCare / web portal
  • Banks & gateways
  • Retail channels
Payment

Sends to

  • Billing
  • Collection
  • Finance

Payment Flow — End-to-End

From Collection module request through financial institution processing to result propagation

Collection Module
Sends payment request with invoice and account details
Module Input
→
1
Payment Gateway
Routes request to correct financial institution based on payment method.
Data StoreEvent Bus
→
2
Tokenisation Service
Detokenises stored card credentials. No raw card data in the platform.
External Service
→
Financial Institution
Processes payment — card authorisation, bank debit or in-store confirmation
External
→
3
Result Processing
Payment Gateway receives result. Updates data store. Publishes to event bus.
Data StoreEvent Bus
→
4
Collection & Accounting
Payment result notifies Collection and Accounting via event bus channels.
Module Output
Input
Route
Tokenise
Process
Result
Notify

Payment Channels

Three payment methods supported — each routes to a different financial institution via the Payment Gateway

Credit Card

Card authorisation via Card Authorisation Network
  • Subscriber registers card during onboarding
  • Card credentials stored as token — never raw
  • Tokenisation service resolves token to card details
  • Payment authorisation sent to Card Authorisation Network
  • Authorisation response received and processed
  • Supports card renewal via tokenisation service
Platform → Card Authorisation Network → Card Network → Result

Direct Debit

Bank account debit via financial institution bank debit network service
  • Subscriber registers bank account during onboarding
  • Payment request sent to financial institution bank debit network service
  • Financial institution debits subscriber bank account on due date
  • Debit result (success / failure) returned to Payment Gateway
  • On failure, account referred to Collection for dunning
  • Supports re-debit attempt on failure recovery
Platform → Bank Debit Network → Bank Account → Result

Walk-in Payment

Walk-in payment via financial institution in-store payment network service
  • Payment slip generated by Collection & Dunning module
  • Subscriber pays at a participating walk-in location using the payment slip
  • Walk-in location transmits payment data to financial institution
  • Financial institution in-store payment network service notifies the platform of payment
  • Payment Gateway processes the confirmation
  • Supports slip cancellation and reissue
Payment Slip → Walk-in Payment Channel → In-store Network → Result

Card Security — Tokenisation

How payment credentials are secured — no raw card data is ever stored in the platform

Credential Tokenisation

Payment credentials are tokenised by an external service. The the platform stores and passes only the token — never raw card numbers, bank account details or security codes.

Registration

Subscriber submits card or bank account during onboarding. Credentials sent to tokenisation service. A token is returned and stored in the data store against the subscriber profile.

Payment Request

When payment is needed, the Payment Gateway retrieves the stored token. It passes the token to the tokenisation service, which resolves it to the real credential for the financial institution call.

Renewal & Update

The tokenisation service handles credential renewal autonomously — requesting updated card details from card issuers when cards expire. Platform receives an updated token with no manual intervention required.

Component Responsibilities

Detailed function of each service in the Payment module

Payment Gateway

Core — Route & Process
  • Receives payment requests from Collection module via event bus
  • Determines payment channel (card, direct debit, walk-in payment channel) from payment method
  • Sends payment request to appropriate financial institution
  • Receives authorisation or debit response
  • Updates payment status in data store (success / failure)
  • Publishes payment result to event bus for Collection and Accounting
  • Maintains payment data and full payment history per billing account
  • Supports multiple billing bucket access (consumer, enterprise, partner lines)
Data StoreEvent BusExternal API

Tokenisation Service

Security — Credential Protection
  • External service responsible for card credential tokenisation
  • Converts raw payment credentials to opaque tokens during registration
  • Resolves tokens back to credentials for financial institution calls
  • Handles card renewal processing with card issuer autonomously
  • No raw credentials ever persist in platform data stores
  • Platform stores only the token — detokenisation performed by this service at payment time
External ServiceToken Store

Storage & Persistence

How and where the Payment module stores its data

Document Data Store

Payment records
  • Payment data per billing account (current cycle)
  • Payment history (previous cycles — archived)
  • Payment method token per subscriber
  • Invoice-to-payment linkage

Async Event Bus

Notifications
  • Payment request input channel (from Collection)
  • Payment success notification channel
  • Payment failure notification channel
  • Accounting update channel

Tokenisation Store

External — credential vault
  • Managed entirely by Tokenisation Service
  • No raw credentials in platform data stores
  • Token-to-credential mapping held externally
  • Supports multi-issuer credential renewal

Design Principles

Key architectural decisions behind the Payment module

Single Payment Interface

Collection & Dunning sends a unified payment request regardless of the subscriber's payment method. The Payment Gateway encapsulates all channel-specific logic — card, direct debit and walk-in payment channel flows are invisible to the caller, enabling new channels to be added without changing Collection.

Zero Raw Credential Storage

The the platform never stores raw card numbers, security codes or bank account details. All credentials are tokenised at the point of entry and stored only as opaque tokens. Detokenisation occurs at payment time within the secure tokenisation service boundary.

Async Result Propagation

Payment results — success or failure — are published to the async event bus rather than returned synchronously. Bill Collection and Accounting subscribe independently to the result channels, allowing each to react at its own pace without coupling to the payment processing latency.

AI opportunity
Where AI helps
Payment fraud

Score transactions and top-ups for fraud risk in real time.

Smart retries

Pick the best time and method to retry failed card or direct-debit payments.

More in 30 AI & ML use cases and AIOps for BSS.

Key business processPayments & Finance→
Standards & references
TMF676Payment Management API
TMF670Payment Methods API
PCI DSSCard data security standard