Building a Reliable Payment Tracker with Daya's API and AWS

One thing I have learned from working around payment systems is that collecting money is usually the easy part.

The harder problem is knowing, with confidence, that the money arrived and that your system accounted for it correctly.

At first glance, the flow seems straightforward:

1. Generate payment details.
2. Give those details to a customer.
3. Wait for payment.
4. Update your records.

In reality, payment systems operate in a world of retries, network failures, duplicate events, and downstream services that occasionally decide today is not their day.

That was the problem I wanted to explore when I built this payment tracker.

Instead of focusing only on payment collection, I wanted to build something that could safely handle the full lifecycle of a payment event, from payment creation to reconciliation, while remaining reliable when parts of the system fail.

For payment collection, I used Daya. For reliability and operational infrastructure, I used AWS.

Daya provides the payment infrastructure: funding accounts, bank-transfer collection, crypto-address collection, and deposit webhook events. AWS provides the backbone that lets the application process those events reliably: webhook endpoints, queues, workers, durable storage, secrets management, monitoring, and alerts.

The result is a simple payment tracker that can:

• Create NGN bank-transfer payment details.
• Create crypto deposit addresses.
• Receive and verify signed Daya webhooks.
• Queue payment events before processing them.
• Process Daya deposit events asynchronously.
• Reconcile those events into application payment records.
• Run entirely on AWS serverless infrastructure.

More importantly, it demonstrates a pattern that shows up in many real-world fintech systems: collect payment events quickly, process them safely, and ensure every payment is accounted for.

Live Demo

I deployed the application publicly so you can explore the flow yourself:

Live Application: http://bit.ly/3Qzpd7G

Source Code: https://github.com/Emidowojo/Daya-Payments-Tracker

The public deployment runs in a safe demonstration mode and showcases the payment lifecycle, webhook handling, event processing, and reconciliation workflow described throughout this article.

The Problem

Imagine a customer pays into your application.

What happens next?

Many first implementations look something like this:

Webhook arrives
↓
Process payment immediately
↓
Update database
↓
Return success

It works until something goes wrong.

What if:

• Your database is temporarily unavailable?
• A downstream API times out?
• The webhook gets delivered twice?
• Processing takes longer than the provider expects?

Now you're dealing with failed reconciliations, duplicate records, and support tickets.

The goal of this project was to avoid those problems from the beginning.

The Architecture

The architecture separates payment collection from payment processing.

Browser Payment Tracker
        |
        v
Lambda Function URL  <--------  Daya Webhook
        |
        v
Amazon SQS Queue
        |
        v
Worker Lambda
        |
        v
DynamoDB

Secrets Manager -> API Lambda and Worker Lambda

SQS Dead-Letter Queue -> CloudWatch Alarm

The core idea is simple:

The webhook endpoint should acknowledge events quickly.

Actual reconciliation happens later.

In this architecture, Daya is the source of payment events. AWS is the reliability layer that helps the application process those events safely.

Why Daya?

I chose Daya because this project needed a payment layer that could support both local currency and stablecoin collection through an API.

Daya Funding Accounts make that possible.

A funding account represents payment details a business can give to a customer to receive funds. Depending on the rail, that could be an NGN virtual account for bank-transfer collection or a crypto deposit address for stablecoin deposits.

For this project, Daya provides the collection infrastructure and deposit events that make reconciliation possible. The application then uses AWS to process those events safely and turn them into durable payment records.

For this implementation, I used:

The flow begins by creating payment details through Daya.

Customers receive those payment details and make deposits through their preferred payment rail.

Once funds arrive, Daya emits a webhook event.

That event becomes the starting point for the application's reconciliation workflow.

Relevant Documentation

• Funding Accounts
• Create Funding Account
• Webhook Events
• Webhook Verification

Creating Payment Details

The application supports both bank-transfer collection and crypto collection.

For bank transfers:

Create Funding Account
↓
NGN_VIRTUAL_ACCOUNT
↓
Receive account number
↓
Display to customer

For crypto deposits:

Create Funding Account
↓
CRYPTO_ADDRESS
↓
Receive deposit address
↓
Display to customer

At this stage, no money has moved yet.

The application is simply preparing a destination where funds can be received.

Receiving Webhooks

When a customer completes a payment, Daya sends a webhook event.

One mistake I see often is treating webhooks as workflows.

They are not.

Webhooks are notifications.

If there is one lesson I would carry into any payment integration, it is this:

Never make the webhook handler do too much.

The webhook endpoint should:

1. Verify authenticity.
2. Persist the event.
3. Return success.

Everything else can happen later.

For this project, the webhook handler follows this flow:

Receive webhook
↓
Verify X-Daya-Signature
↓
Push event to SQS
↓
Return HTTP 200

That's it.

No reconciliation.

No heavy database operations.

No external calls.

Just verification and persistence.

A simplified version of the webhook handler looks like this:

app.post("/webhooks/daya", async (request, response) => {
  const signature = request.header("X-Daya-Signature");
  const rawBody = JSON.stringify(request.body);

  const isValid = verifyDayaSignature(rawBody, signature, webhookSecret);

  if (!isValid) {
    return response.status(401).json({ error: "Invalid webhook signature" });
  }

  await queue.send({
    id: request.body.id,
    type: request.body.type,
    payload: request.body,
  });

  return response.status(200).json({ received: true });
});

In the real application, the queue is backed by Amazon SQS in AWS and by a local queue during development.

Why Queue the Webhook?

Once a webhook has been verified, the event is pushed into Amazon SQS.

This provides several benefits.

Faster Responses

Webhook providers expect a quick response.

The API no longer waits for reconciliation logic to finish.

Retryability

If processing fails, SQS can retry automatically.

Failure Isolation

A temporary database issue should not cause webhook delivery failures.

Traffic Buffering

Large bursts of payment activity can be absorbed without overwhelming workers.

Dead-Letter Queues

Failed events can be isolated and investigated later.

The queue acts as a safety layer between incoming payment events and business logic.

Processing Payments Safely

A worker Lambda consumes events from SQS.

This is where the application reconciliation happens.

SQS Event
↓
Validate payload
↓
Check idempotency
↓
Store payment record
↓
Mark event processed

The worker becomes responsible for turning Daya payment notifications into durable application records.

This separation makes the system significantly easier to reason about.

Handling Duplicate Events

Payment systems should assume every event can arrive more than once.

Not because something is broken.

Because retries are a feature of reliable systems.

To avoid duplicate processing, the worker stores processed webhook IDs.

Before handling an event, it checks whether that ID already exists.

Webhook Event
↓
Has event been processed?
 ├─ Yes → Skip
 └─ No → Process

This property is known as idempotency.

Without it, duplicate webhook deliveries could create duplicate payment records.

With it, the same event can safely be delivered multiple times.

That is the difference between:

"We received a webhook"

and

"We safely reconciled a payment."

Storing Payment State

DynamoDB serves as the application's reconciliation store, not as a replacement for Daya's payment records.

The application stores:

• Funding accounts
• Payment records
• Processed webhook IDs

Having a dedicated record of processed events makes idempotent processing straightforward.

It also provides a clear audit trail when troubleshooting payment issues.

Managing Secrets

Payment systems inevitably require credentials.

For this build, I used AWS Secrets Manager to store:

• Daya API keys
• Daya webhook secrets

Neither the application code nor deployment artifacts contain sensitive values.

Both the API Lambda and worker Lambda retrieve secrets at runtime.

Monitoring and Operations

Reliable systems need visibility.

CloudWatch provides:

• Application logs
• Worker logs
• Error tracking
• Dead-letter queue alarms

If events begin accumulating in the dead-letter queue, CloudWatch can raise an alert so operators know reconciliation requires attention.

This is one of those operational details that rarely appears in architecture diagrams but becomes invaluable in production.

Deployment

The project is deployed using AWS CDK and a serverless architecture built around Lambda, SQS, DynamoDB, Secrets Manager, and CloudWatch.

The deployment process provisions:

• Application endpoints
• Webhook endpoints
• Event queues
• Dead-letter queues
• DynamoDB tables
• Secrets storage
• Monitoring resources

One of the goals of the project was to demonstrate that reliable payment processing does not require managing servers. By combining event-driven AWS services, the operational burden remains low while reliability remains high.

What About Containers?

Because I am also active in the AWS Containers community, I included an ECS Fargate deployment path in the project as well.

Functionally, both deployments achieve the same outcome.

The difference is operational.

The serverless version is cheaper and simpler to maintain.

The ECS version provides a stronger container-focused architecture and may fit teams already standardizing on containers.

For educational projects, I would start with serverless and treat the container deployment as an advanced follow-up.

Lessons Learned

Building this project reinforced a few lessons that apply far beyond this payment tracker.

1. Webhook Handlers Should Be Boring

When I first started working with event-driven systems, I was tempted to do all the work inside the webhook handler.

That approach works until something downstream becomes unavailable.

The more responsibility a webhook endpoint has, the more opportunities it has to fail.

In this project, the webhook handler has one job:

1. Verify the request.
2. Persist the event.
3. Return success.

Everything else happens asynchronously.

Keeping the handler simple makes the system more reliable and easier to troubleshoot.

2. Queues Are an Investment in Reliability

It's easy to look at SQS and think it adds complexity.

In reality, it removes complexity from the parts of the system that matter most.

The queue absorbs traffic spikes, handles retries, and creates a buffer between incoming payment events and business logic.

Without the queue, every temporary downstream failure becomes a payment-processing problem.

With the queue, failures become manageable.

3. Idempotency Is Not Optional

One of the most important lessons in payment systems is that duplicate events are normal.

Providers retry webhooks.

Networks fail.

Clients reconnect.

The question is not whether duplicates will happen.

The question is whether your system can handle them safely.

Designing for idempotency from the start is much easier than trying to retrofit it later.

4. Reliability Is an Architecture Decision

Reliable systems are rarely the result of a single service or framework.

Reliability comes from the choices made between components.

The queue, the worker, the dead-letter queue, the monitoring, and the idempotency checks all contribute to a system that can recover gracefully when things go wrong.

5. Observability Matters More Than Expected

One thing that became clear while building this project is that debugging payment systems without visibility is frustrating.

Logs, metrics, and alerts are not features users see, but they are often the difference between quickly resolving an issue and spending hours trying to understand what happened.

CloudWatch ended up being just as important as the business logic itself because it provided confidence that payment events were flowing through the system correctly.

Before Production

Before adapting this pattern for a real customer-facing product, I would recommend adding:

• Authentication and authorization
• Custom domains and TLS management
• Structured tracing
• CI/CD pipelines
• Alarm notifications
• Production reconciliation queries
• Rate limiting
• Audit logging
• Separation of testing and production environments

The architecture is intentionally simple, but the reliability patterns scale well beyond this example.

Final Thoughts

Building payment systems taught me that reliability rarely comes from a single API call.

It comes from the decisions made around that call.

How events are received.

How failures are handled.

How retries are processed.

How operators gain confidence that the system reflects reality.

Daya makes it possible to create payment destinations and receive deposit events.

AWS helps the application process those events reliably and reconcile them into its own records.

Together, they provide a practical blueprint for building payment systems that users and operators can trust.