Building AYONIQ PAY
I have been thinking about payment systems for quite some time.
In Bangladesh, sending and receiving money digitally has become a normal part of running a business. Customers pay through bKash, Nagad, Rocket, bank transfers and other services every day. But from a developer's or merchant's point of view, the payment itself is often only one part of the problem.
The harder part starts after the payment is made.
Was the money actually received? Which customer made the payment? Which order does the transaction belong to? Has the payment already been processed? What happens when hundreds of transactions arrive throughout the day?
These are the kinds of problems that led me to start building AYONIQ Pay.
AYONIQ Pay is a payment automation system designed to help businesses detect, verify, reconcile and manage payment transactions with less manual work.
The goal is not simply to create another payment page. I want to build the infrastructure around payments that makes the entire process easier to manage.
Why I started building it
A lot of software projects start with a specific problem that becomes difficult to ignore.
For me, payment verification was one of those problems.
Imagine a small online business receiving dozens or hundreds of payments every day. A customer places an order, sends money through a mobile financial service, and then sends a transaction ID or screenshot to the merchant.
Someone has to check the payment.
Someone has to match it with the order.
Someone has to update the order status.
And if this is happening repeatedly throughout the day, a surprisingly large amount of time goes into something that should ideally happen automatically.
Large companies can build complicated payment infrastructure around these processes. Smaller businesses and independent developers often do not have that luxury.
That made me interested in a simpler question:
What if payment verification could happen automatically?
That question eventually became AYONIQ Pay.
The problem
The payment ecosystem in Bangladesh is different from many markets where card-based payment APIs are the default.
Businesses commonly work with services such as bKash, Nagad, Rocket and bank-based payments. Depending on the business and its setup, the merchant may receive transaction information through different channels.
This creates several practical problems.
The first is manual verification.
A merchant may need to open an app, check a transaction, compare the amount, find the customer and then manually confirm the order.
The second is transaction matching.
Receiving money is not enough. The system needs to understand which order, invoice or payment request the transaction belongs to.
The third is duplicate processing.
A transaction should not accidentally be counted twice just because the same notification or event was received more than once.
Then there is reconciliation.
At the end of the day, a business needs to know what was received, what was successful, what failed, what is still pending and whether the internal records match the actual transactions.
These problems are not particularly exciting from the outside.
But when you are running a real system, they matter a lot.
How AYONIQ PAY works
The core idea behind AYONIQ PAY is relatively simple.
A payment event comes into the system.
AYONIQ PAY processes the event, extracts the relevant information, identifies the transaction and then tries to match it with an existing payment request, order or invoice.
If everything matches, the payment can be marked as verified automatically.
A simplified flow looks like this:
Payment → Detection → Processing → Matching → Verification → Reconciliation
The important part is that the system should not blindly trust every incoming event.
It needs to understand what happened.
For example, suppose a merchant creates a payment request for ৳1,250.
A customer completes the payment.
The transaction information reaches AYONIQ Pay.
The system can then check things such as:
- transaction reference
- amount
- payment channel
- sender or relevant account information
- merchant
- time
- transaction status
- whether the transaction was already processed
If the required conditions are satisfied, the system can update the payment automatically.
That removes a large amount of repetitive work from the merchant.
From payment links to automation
One thing I do not want AYONIQ PAY to become is just another payment-link generator.
A payment link is useful, but it is only the beginning.
The interesting part is everything that happens after someone makes a payment.
A proper payment automation system should be able to answer questions such as:
What was paid?
Who paid it?
What was it for?
When was it paid?
Has it already been verified?
Was it reconciled with the business record?
That is why I think of AYONIQ PAY more as a payment operations layer than simply a payment interface.
The interface should make things easy for the merchant, while the backend handles the complicated parts.
Architecture
I am designing AYONIQ PAY as a modular system so that different parts can evolve independently.
The main components include a merchant-facing dashboard, an API backend, transaction processing services, device integration and a database layer.
The backend is being built with NestJS and TypeScript.
The dashboard is built around a modern web application architecture, while the backend exposes APIs for payment creation, verification, transaction management and integrations.
At a high level, the system looks something like this:
Merchant Dashboard → API → Payment Engine → Transaction Processing → Verification → Database
There is also a device layer for receiving transaction information where required.
One of the interesting engineering challenges here is making the system reliable when the same transaction information arrives more than once.
A payment event should be processed exactly once from the application's perspective, even if the underlying notification is duplicated.
That means idempotency, unique transaction identifiers, event tracking and careful database constraints are important parts of the architecture.
Security
Payment systems cannot be treated like ordinary CRUD applications.
Even a small mistake can result in incorrect payment status, duplicated transactions or unauthorized access to sensitive merchant information.
Security therefore has to be part of the architecture from the beginning.
For AYONIQ PAY, I am focusing on several areas.
Authentication and authorization are required for every protected operation.
API keys are separated from ordinary user authentication where appropriate.
Sensitive credentials and secrets should never be hard-coded into the application.
Incoming device communication needs to be authenticated rather than simply accepted because it came from a known endpoint.
Transaction processing also needs protection against replay and duplicate events.
For important operations, I want the system to maintain an audit trail so that it is possible to understand what happened and when it happened.
Another important principle is fail closed.
If the system cannot confidently verify something, it should not simply mark the payment as successful.
It is better to have a payment waiting for review than to incorrectly confirm a transaction.
Building for real-world conditions
One thing I have learned while working on this project is that designing a payment system on paper is much easier than building one that can survive real-world conditions.
Networks fail.
Devices disconnect.
Notifications arrive late.
The same event can appear more than once.
A merchant may change a configuration.
A transaction can look valid but still require manual review.
The system has to account for these situations.
This is why I am spending a lot of time on things that are not immediately visible in the UI.
Device health, transaction states, retries, logs, audit records, idempotency and failure handling are all important.
A beautiful dashboard is useful.
But a payment system needs to remain trustworthy when something goes wrong.
What I am building next
AYONIQ PAY is still evolving.
There are several areas I want to improve as the project develops.
The first is a more complete merchant dashboard where businesses can manage transactions, payment requests, customers, settlements and reports from one place.
I also want to improve the transaction engine so that matching and verification become more flexible without making the system unpredictable.
Another area is developer experience.
A payment infrastructure project is only useful if developers can integrate it without spending days trying to understand how everything works.
That means clear API documentation, predictable responses, SDKs and useful examples are important parts of the roadmap.
I also want to build better monitoring around connected devices and transaction processing.
If a device stops communicating, the merchant should know.
If transactions suddenly stop arriving, the system should be able to surface that problem instead of silently waiting.
Over time, I would also like AYONIQ Pay to support more payment providers and more integration patterns.
Why I am building this in Bangladesh
There is a bigger reason behind the project as well.
A lot of modern software infrastructure is designed with markets like the US or Europe in mind.
The assumptions are often different.
The payment methods are different.
The business workflows are different.
The developer requirements are different.
Bangladesh has its own technology ecosystem, and I think there is value in building infrastructure that understands those local realities instead of trying to force every problem into an existing template.
AYONIQ PAY is one small attempt at doing that.
I do not expect the first version to solve everything.
The goal is to start with a real problem, build something useful, learn from actual usage and keep improving the architecture.
Conclusion
AYONIQ PAY started with a simple idea:
Payment verification should not require someone to manually check every transaction.
From that idea, the project has grown into something much bigger.
It is becoming an exploration of payment automation, transaction processing, reconciliation, developer infrastructure and reliable financial software.
There is still a lot to build.
There are also many things I will probably get wrong along the way.
That is part of building something from scratch.
For now, I am focused on making AYONIQ Pay reliable, understandable and genuinely useful for businesses and developers in Bangladesh.
The long-term goal is simple: make payment operations feel less like a manual task and more like infrastructure that quietly works in the background.
And this is only the beginning.