Bill Payments and Recharge

Standard auto-pay implementations require users to set a fixed debit date — typically a calendar date they choose manually. The problem is that biller due dates vary by month and billing cycle, so a fixed date that works in January may result in a late payment in February. SmartPay's scheduling engine reads the due date from the biller integration directly and calculates the correct debit date automatically — accounting for processing lead times and non-business days. The user sets up auto-pay once, and the schedule adjusts each billing cycle without manual intervention.

When a user selects a bill for payment, the platform makes a real-time credit limit check through the MBE middleware layer to LazyPay's credit system. The user sees their current available credit line alongside the standard payment options — not a pre-cached eligibility indicator that may not reflect their current credit position. If the user selects BNPL, the payment is processed through LazyPay and settled with the biller. The reconciliation pipeline handles the three-way settlement match between the platform, LazyPay, and the biller automatically.

The catalogue covers utility providers — electricity, water, gas — telecom operators for postpaid bills and prepaid recharge, credit card issuers across major banks, insurance premium payments, and broadband and DTH providers. New billers are integrated through the middleware layer without requiring changes to the application layer, so the catalogue can be extended as new biller relationships are established without a platform release.

When a recharge request is submitted, the platform sends the instruction to the provider's API and waits for an execution confirmation before updating the user's transaction status. The confirmation displayed to the user reflects the actual recharge execution status from the provider — not the payment submission status, which is an earlier and less meaningful event. This eliminates the ambiguous pending states that result from confirmation being tied to payment rather than execution.

The reconciliation engine ingests confirmation data from each biller and settlement data from LazyPay on their respective schedules. Each completed transaction is matched against both the biller confirmation and the payment record in the platform database. A successful three-way match closes the transaction. Unmatched records — from timing differences, partial confirmations, or provider errors — surface as exceptions with the transaction data needed to investigate and resolve them, rather than requiring manual log comparison.

The scheduling engine detects the failed submission and retries against a defined schedule before the due date window closes. If the biller API remains unavailable beyond the retry window, the user is notified with enough lead time to complete the payment manually before the due date. The auto-debit failure and retry events are logged in the transaction record and visible in the user's payment history — so there is a clear audit trail of what was attempted and when.

A full bill payment platform — covering 1000+ biller integrations, SmartPay auto-debit, LazyPay BNPL, prepaid recharge, and settlement reconciliation — typically runs twelve to sixteen weeks from architecture sign-off to production. The range depends on the number of biller integrations in scope at launch, the complexity of the BNPL provider's API, and whether the platform is greenfield or built on an existing payment infrastructure. We assess scope during the discovery phase before committing to a timeline.

The system is handed over production-ready, tested across biller integrations and BNPL flows, and documented at the service and API level. Your team can operate and extend it independently. We do not build on proprietary frameworks that require ongoing GeekyAnts involvement to run. If a formal support arrangement post-launch makes sense for your team, that is a separate conversation.