Client / business context
Moniass Business needed a merchant payment environment where businesses could accept and track multiple payment channels while operators managed settlements, agents, commissions, and reconciliation.
Merchant payment and settlement platform
Moniass Business Merchant Payment Platform
QR checkout, merchant dashboards, payment channels, settlement, and commission workflows.
GoNext.jsPostgreSQLRedisNATSDockerREST APIs
Product surface
Merchant payment console
Status
Risk
Ledger
QR-6620Merchant checkoutPaid
ST-2088SettlementQueued
CM-4421CommissionReady
Mobile app
Merchant checkout flow
QR checkout1
Payment state2
Settlement view3
Agent activity4
Project overview
Business context and operational problem.
In merchant payments, checkout status, provider events, settlement, commissions, and reconciliation all have to agree before the business can trust the numbers.
The challenge
Multi-channel payment systems create complex edge cases. The platform needed dependable checkout status, settlement logic, commission rules, webhook handling, and operational review workflows.
Business outcome
Operators can review checkout status, provider events, settlement readiness, commission logic, and reconciliation context from one controlled workflow.
Buyer relevance
Relevant if your business needs merchant payments, QR checkout, provider events, settlements, commissions, and reconciliation that operators can inspect.
Failure avoided
- Ambiguous payment status
- Duplicate provider events
- Settlement confusion
- Commission mismatch
- Manual reconciliation
Build scope
Product and engineering scope.
The work combined user-facing product flows with the operational controls needed to run the product responsibly.
What Malead built
- QR-based checkout workflows for merchant payments
- Merchant dashboard for payment visibility and account management
- Agent workflows and commission logic
- Settlement and reconciliation foundations
- Webhook-aware backend flows for external payment events
Key product features
- Merchant onboarding
- QR checkout
- Payment status tracking
- Agent management
- Commission reporting
- Settlement dashboard
Product modules
Anonymized product surfaces for the kind of software involved.
These visuals communicate the product category and operational shape without publishing private client screens or sensitive data.
Admin operations
Merchant payment console
Status
Risk
Ledger
QR-6620Merchant checkoutPaid
ST-2088SettlementQueued
CM-4421CommissionReady
Mobile app
Merchant checkout flow
QR checkout1
Payment state2
Settlement view3
Agent activity4
Architecture
Architecture and technical considerations.
Technical buyers should be able to inspect how roles, provider events, data, APIs, and operational controls were considered.
Architecture
Merchant payment architecture
Customer app
Admin portal
Partner APIs
API gateway
Domain services
Workflow jobs
Database
Queue
Audit logs
Monitoring
Technical architecture
- API gateway routes checkout, merchant, payment, and admin activity
- Payment services process lifecycle events and persistence
- Background workers support settlement and reconciliation tasks
- Dashboards expose merchant and operational state without exposing internals
Technical highlights
- QR checkout lifecycle
- Webhook verification and event handling
- Settlement and commission logic
- Idempotency for payment events
- Reconciliation-aware data model
Security and reliability
- Webhook verification and event replay considerations
- Role-based merchant and admin access
- Idempotency for repeated payment events
- Audit records for sensitive operational actions
Operations
Workflow control after launch.
Operational systems need review points, reliable statuses, support visibility, and accountability around sensitive actions.
Workflow
Merchant payment lifecycle
1
Generate checkout
2
Receive provider event
3
Verify webhook
4
Settle merchant
5
Record commission
6
Reconcile
Operational considerations
- Merchant payment tracking
- Agent activity and commission visibility
- Settlement review and reconciliation workflows
- Private walkthrough available for approved checkout, merchant, agent, settlement, and reconciliation screens
Lessons and improvements
- Payment systems need explicit lifecycle states, not vague success screens.
- Commission and settlement logic should be testable and observable.
- Webhook-driven systems must be built for retries, duplicate events, and auditability.
Public proof
Client-safe evidence a serious buyer can inspect.
Public proof focuses on scope, product surfaces, operating complexity, technical decisions, and private walkthrough material where approval allows.
Operational scope
Scope includes QR checkout, merchant dashboards, agent workflows, payment channels, settlement logic, commissions, and webhooks.
Technical proof
Technical proof centers on payment lifecycle handling, idempotency, webhook events, reconciliation-aware data, and settlement review.
Private walkthrough
Approved walkthroughs can cover checkout, merchant, agent, settlement, webhook, and reconciliation screens.
What can be reviewed privately
Approved screens, architecture context, operating details, and reference material can be discussed during qualified project conversations where client confidentiality allows it.
GoNext.jsPostgreSQLRedisNATSDockerREST APIs
Project consultation
Building a merchant payment or settlement platform?
Let us review the business logic, technical risks, integrations, user roles, and roadmap before development begins.
1Project brief
2Risk review
3Architecture plan
4Proposal
5Build