SMSPayBD

A payment reconciliation platform connecting merchant checkout, an Android SMS agent, and operational dashboards to match mobile-wallet payments and notify merchant systems.

Connecting merchant checkout, trusted SMS evidence, reconciliation, and signed payment notifications.

SMSPayBD is a payment-reconciliation platform for merchants collecting money through mobile-wallet channels. I built the project around the operational gap between a customer making a payment and a merchant system having reliable evidence that the corresponding order can move forward.

The product combines a merchant dashboard, hosted checkout, a backend API, background jobs, and an Android SMS agent. The important part is the connection between these pieces: an incoming message becomes structured evidence, that evidence is matched to a payment intent, and the merchant receives a signed status event.

A screenshot or a transaction ID alone is a weak operational workflow. Incoming SMS can be duplicated, delayed, malformed, or difficult to associate with a particular order. A payment system also needs to distinguish an unmatched message from a confirmed payment and give support staff a way to resolve exceptions.

The engineering challenge was to make that lifecycle explicit while keeping each merchant organization isolated from other tenants.

1. Merchant creates intent.
2. Customer opens checkout.
3. External payment.
4. Android forwards SMS.
5. Reconcile payment.
6. Signed merchant webhook.

The flow above describes the product journey. The following sections explain the implementation and the boundaries of this case study.

The codebase separates the web dashboard, API, worker, and Android application. PostgreSQL stores the business records, Prisma provides the data-access layer, and Redis/BullMQ support asynchronous work. This separation gives a payment request, the evidence received for it, and the notification sent afterward distinct responsibilities.

Tenant ownership is an explicit domain boundary. Organizations own their users, customers, intents, SMS events, devices, and webhook resources. Sandbox and Live are environments within a merchant tenant. Provider-level access and merchant-level access therefore answer different questions.

The documented device policy also has two layers: the provider permits payment methods for an organization, and the Android device enables a local subset. The effective methods are the intersection of those choices.

Payment evidence and notification boundaries

The diagram separates the original request, incoming evidence, reconciliation decision, and merchant notification.

Technology stack

An Android phone introduces real operational dependencies: connectivity, device availability, SMS delivery, and provider-message formats. Background workers also need monitoring; a healthy dashboard does not prove that a webhook queue is moving.

The repository documents a verified staging/controlled-pilot stage. Broad rollout still has readiness work around worker alignment, end-to-end browser tests, replay protection, rate limiting, backups and restore checks, monitoring, and live-device validation. The public marketing page describes a wider provider roadmap; this case study does not treat every advertised provider as a verified parser implementation.

The most valuable lesson was to model the uncertain parts of a payment workflow explicitly. Payment evidence, a matching decision, and merchant notification are related events, but they should not be collapsed into a single optimistic success flag.

Open the application