Every rail speaks its own language
Every bank brings its own file layout, cut-off and response format. Each one absorbed today by a separate hand-built process.
EzBilling OneMandate Management & Recurring Premium Collection
Mandate to money.
One platform for registration, presentment, collections, reconciliation and customer communication — on every payment rail. A new rail is a business decision, not an engineering programme.
Overview
Registration is not payment.
A mandate must be registered, verified and kept alive before a single rupee can be debited. Those are two different disciplines, and most estates handle them in two different places.
EzBilling One runs both, plus everything after them, on one execution core with one canonical data model.
- Category
Mandate Management & Recurring Premium Collection Platform - Covers
Registration, presentment, collections, reconciliation, communication - Rails
NACH, e-NACH, UPI Autopay, standing instructions, ECS and direct debit - Used by
Collections, operations, finance and reconciliation teams - Deployment
Cloud-ready or on-premise
The problem
Collections are outgrowing hand-built rails.
The industry default is people re-keying case by case, bots hopping between screens, and spreadsheets reconciling late.
Compliance sets the clock
Pre-debit notification, fixed presentment windows, salvage limits and grace rules are mandatory — and are absorbed today by manual effort.
Leadership flies blind
Success and bounce rates live in end-of-day extracts and spreadsheets, rather than in a live view the business can act on.
Underneath all of it, no single place to ask whether a policy's mandate is alive today.
Event-driven
Collection lifecycle events. Registration, presentment, collection and receipting each publish to an SNS topic, so finance, CRM and reporting stay in step without a nightly extract.
How it works
Mandate to money in five moves.
Register
Mandate captured and quality-checked against the signed image.
Present
Debits lodged on the right rail, inside its cut-off windows.
Track
Statuses polled and mapped to one canonical model.
Reconcile
Collections matched, receipted and posted onward.
Communicate
The customer hears the outcome on every channel.
Pre-debit gate
No contact, no debit. Pre-debit notification is mandatory before
any presentment. Manual override is possible and fully audited. Exceptions loop back
into the console as work queues rather than falling between systems.
Capability map
One blueprint, ten modules.
The core lifecycle earns the money. The operating modules keep it visible. The growth modules make the next rail cheap.
Core lifecycle
- Mandate registration — capture, quality check, submit, confirm
- Presentment — every rail on one execution core
- Collections data — outcomes posted into the ledger
Operate
- Dashboards — live success, health and exceptions
- Reports and MIS — registration, transaction, receipting
- Notifications — pre-debit, success and failure
- Admin control — windows, mappings and endpoints
Grow
- Campaigns — salvage, skip and recovery drives
- Connectors — API and secure-file partner packs
- Extensibility — a new rail by configuration
Communication management
- Templated email, SMS and WhatsApp on every outcome
- Pre-debit notice, debit result, retry outcome and mandate status
- Per-event templates managed from the console
- Scheduled dispatch with delivery logged per customer and event
- Reminders stop automatically when the customer responds
Events
- Mandate and collection events published to SNS topics
- Finance, CRM and data platforms subscribe rather than poll
- Registration, presentment, collection and receipting events
- Reliable dispatch with retry and correlation ids
The engine
One engine, every rail.
Built once, configured per rail, reused by every partner. Adding a rail does not change the engine.
Schedule
Rules per regulator, bank and vendor. Presentment windows, cut-offs, grace and salvage limits held as configuration.
Gate
Pre-debit notice, always. No contact means no debit. Manual override is available and fully audited.
Execute
Debit by API or secure file, with technical retry inside the window and status inquiry on T, T+1 and T+2.
Settle
Receipt raised on success, the customer told either way, and the outcome closed on the policy timeline.
Extensibility
New rails are configuration, not code.
Genuinely new behaviour is engineered once. Every look-alike rail after it is configuration — no build, no downtime, no project.
Describe the rail
Identity and capabilities as configuration, including what a rail deliberately cannot do.
Map the fields
Where each value sits in the rail's request and reply, placed by map rather than by code.
Hand over the keys
Credentials entered once from the console, encrypted at rest, write-only, never shown again.
Go live
Running services pick the new rail up in flight, with no build and no downtime.
The usual way — months
- Scope the specification
- Code a branch per provider
- Test cycles
- Release train
- Certify — every provider, every time
EzBilling One — days
- Configure the rows
- Enter the credentials
- Certify and go live on the engine that already runs
- One canonical status model across every rail
- Settings reload in flight
Operations
The console runs the whole desk.
Analytics
Registration and collection success, live from the same data operations act on.
Reports
Registration, transaction, receipting and MIS — filter, run and download in one click.
Document viewer
The signed mandate image inline at quality-check time, straight from the document store.
Provider setup
Every endpoint, rule, status map and key editable from the console.
Communications
Email, SMS and WhatsApp fan-out on every registration and debit outcome, all templated.
Audit trail
Every request logged end to end with correlation ids — evidence on demand.
The customer conversation
- T-5 — pre-debit notice, mandatory before any debit.
- T — debit outcome, success or failure, the same day.
- T+1 — follow-up with the retry outcome and the next step.
- Any time — mandate status, registered or rejected.
Recovery campaigns run against a rule-filtered eligible base, are approved once under maker-checker, and stay tagged to the campaign that raised them. A failed collection becomes a second chance without a manual file.
Architecture
Five layers, one system of record.
One deployment, one console, one data model, one audit trail — what the console shows is what the engine did.
Operator console
SearchRegistration QC
CollectionsCorrection queues
Analytics and reportsProvider setup
Secure API core
One authenticated APIValidation
AuditRedaction
Execution engine
SchedulersLodge and present
Poll and retryPer-rail cut-offs
Provider fabric
Configuration-driven adapters
One canonical mandate to every provider dialect
Data backbone
SQL
Every request, response and status in one place
One canonical model
Event publication to subscribers
Provider-agnostic
The platform absorbs provider differences so the business does not have to.
Scheduler-driven
Presentment, polling and retry run to each rail's windows, with no manual triggering.
Secrets stay secret
Credentials are encrypted at rest, write-only from the console, and redacted from every log and export.
Safe to change
Configuration edits are audited, applied without downtime, and reversible row by row.
What changes operationally
One screen for mandate status
One answer while the customer is still on the line, instead of a tour of systems.
No presentment file prep
The engine lodges each batch on schedule, per partner, every cycle.
Same-day reconciliation
Collections matched to receipts in the system rather than in a spreadsheet.
Onboarding by configuration
A new partner is configuration and a connector pack, not a core change.
How long does a new payment rail take you?
Tell us how your collection cycle runs today — rails, presentment windows, retry practice — and we will show you where EzBilling One fits.