DEV Community

Daniel Ioni
Daniel Ioni

Posted on

# 💳 How I Built an Open-Source Payment Gateway for MyZubster with Node.js and Monero

#express #monero #myz #rest

💳 How I Built an Open-Source Payment Gateway for MyZubster with Node.js and Monero

Node.js · Express · Monero · MYZ · REST API · PM2 · Nginx · Open Source

A decentralized ecosystem needs more than wallets.

When robots, IoT devices, mobile applications, marketplaces, and automated services start interacting with each other, they also need a common way to create, track, and verify payments.

That is why I started building an open-source Payment Gateway for MyZubster.

The basic idea is:

Application
     ↓
Payment Gateway
     ↓
Payment Request
     ↓
XMR / MYZ
     ↓
Verification
     ↓
Service
Enter fullscreen mode Exit fullscreen mode

The Gateway becomes the infrastructure layer connecting applications, devices, and payment workflows.

🌐 What is MyZubster?

MyZubster is an open-source ecosystem I am developing around several components:

  • 🤖 Robotics and automation
  • 🧠 AI agents
  • 📡 IoT devices
  • 💳 XMR payments
  • 🪙 MYZ token infrastructure
  • 📱 Mobile applications
  • 🌱 Smart Garden systems
  • 🛰️ Space and robotics simulations

These components should not all have to implement payment logic independently.

That is where the Gateway comes in.

🏗️ The Architecture

The first version uses a deliberately simple technology stack:

                CLIENTS
                   │
       ┌───────────┼───────────┐
       ↓           ↓           ↓
    Android      Robots       IoT
       │           │           │
       └───────────┼───────────┘
                   ↓
          ┌─────────────────┐
          │ MyZubster       │
          │ Payment Gateway │
          └────────┬────────┘
                   │
                REST API
                   │
        ┌──────────┼──────────┐
        ↓          ↓          ↓
       XMR        MYZ      Dashboard
        │          │          │
        └──────────┼──────────┘
                   ↓
              Verification
Enter fullscreen mode Exit fullscreen mode

The backend is based on:

  • Node.js
  • Express
  • PM2
  • Nginx
  • REST APIs
  • JSON persistence for the prototype
  • Monero infrastructure

The architecture is designed so that prototype components can gradually be replaced by more production-ready services.

💳 Why Build a Payment Gateway?

Imagine a robot bartender.

The robot should not need to understand every detail of the financial infrastructure.

It should simply be able to say:

"The customer wants a drink."
Enter fullscreen mode Exit fullscreen mode

The Gateway can turn that request into:

CREATE PAYMENT
       ↓
Currency: XMR
Amount: ...
       ↓
Payment ID
       ↓
Payment Request
       ↓
Verification
       ↓
PAID
       ↓
Robot Authorized
Enter fullscreen mode Exit fullscreen mode

The robot then receives an application-level event:

{
  "payment_id": "payment_123",
  "status": "paid"
}
Enter fullscreen mode Exit fullscreen mode

and can continue its workflow.

This separates payment infrastructure from robot logic.

🪙 XMR and MYZ

The Gateway is designed to support multiple currencies.

For example:

{
  "amount": 10,
  "currency": "MYZ",
  "status": "pending"
}
Enter fullscreen mode Exit fullscreen mode

or:

{
  "amount": 0.01,
  "currency": "XMR",
  "status": "pending"
}
Enter fullscreen mode Exit fullscreen mode

Applications using the Gateway do not need to know every implementation detail of the underlying payment infrastructure.

This makes it possible to reuse the same backend for:

  • robots;
  • marketplaces;
  • Cardputer devices;
  • Android applications;
  • IoT services;
  • future autonomous machines.

🔌 REST API

A major part of the project is the API layer.

For example:

Method Endpoint Function
POST /api/myz/payment/create Create MYZ payment
GET /api/myz/stats MYZ payment statistics
POST /api/myz/sync Synchronize MYZ data
POST /api/cardputer/payment/create Create XMR payment
GET /api/cardputer/payment/:id Get payment
GET /api/cardputer/payments List payments
PUT /api/cardputer/payment/status/:id Update status
GET /api/dashboard Gateway dashboard
GET /health Health check

This allows different devices and applications to communicate with the same payment infrastructure.

🧩 Creating a Payment

A client can create a payment with a simple API request:

const response = await fetch(
  '/api/myz/payment/create',
  {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      tag_id: 'TAG-TEST-001',
      amount: 10
    })
  }
);
Enter fullscreen mode Exit fullscreen mode

The Gateway creates a payment record:

{
  "id": "myz_payment_123",
  "tag_id": "TAG-TEST-001",
  "amount": 10,
  "currency": "MYZ",
  "status": "pending"
}
Enter fullscreen mode Exit fullscreen mode

From that moment, the payment has its own identity inside the application.

💰 Platform Fees

The prototype also includes support for a possible platform fee.

For example, with a 2% fee:

const fee = amount * 0.02;
const netAmount = amount - fee;
Enter fullscreen mode Exit fullscreen mode

For a 10 MYZ payment:

Payment: 10 MYZ
Fee:      0.20 MYZ
Net:      9.80 MYZ
Enter fullscreen mode Exit fullscreen mode

This makes it possible to experiment with economic models for marketplaces and autonomous services.

In a production implementation, fee handling would need proper security, accounting, and applicable regulatory considerations.

💾 Data Persistence

The first prototype uses a simple JSON file:

payments.json
Enter fullscreen mode Exit fullscreen mode

For example:

[
  {
    "id": "myz_payment_001",
    "tag_id": "TEST",
    "amount": 10,
    "currency": "MYZ",
    "fee": 0.2,
    "net_amount": 9.8,
    "status": "paid",
    "created_at": "2026-08-11T09:08:02.317Z"
  }
]
Enter fullscreen mode Exit fullscreen mode

For a prototype, this is enough to experiment with the architecture.

For production, I would move to a proper database with:

  • transactions;
  • concurrency control;
  • backups;
  • auditing;
  • data retention;
  • monitoring;
  • failure recovery.

🔐 An Important Distinction: Application Status vs Blockchain Payment

One of the most important lessons from this project is that these two things are not the same.

Writing:

{
  "status": "paid"
}
Enter fullscreen mode Exit fullscreen mode

does not automatically mean that a Monero transaction has been verified on-chain.

A real payment workflow should distinguish between:

Payment Created
      ↓
Payment Address / Request
      ↓
Transaction Detected
      ↓
Confirmation Check
      ↓
Verified
      ↓
Paid
Enter fullscreen mode Exit fullscreen mode

The database represents the application state.

The blockchain represents the transaction state.

The Gateway has to connect these two layers correctly.

This distinction becomes critical when payments control real-world actions.

📡 Cardputer and IoT

One of the applications I am experimenting with is using physical devices as payment terminals.

The workflow can look like this:

UHF Tag
   ↓
Cardputer
   ↓
Bluetooth
   ↓
Android
   ↓
MyZubster Gateway
   ↓
XMR Payment Request
   ↓
QR Code
   ↓
Monero Wallet
   ↓
Verification
Enter fullscreen mode Exit fullscreen mode

A relatively small IoT device can therefore become the physical interface for a larger payment infrastructure.

🤖 Robots + Payment Gateway

The next step is even more interesting.

A robot can use the Gateway as a service.

For example:

USER
 ↓
REQUEST SERVICE
 ↓
PAYMENT REQUEST
 ↓
XMR
 ↓
GATEWAY
 ↓
VERIFICATION
 ↓
ROBOT
 ↓
SERVICE
Enter fullscreen mode Exit fullscreen mode

The robot does not need to manage the entire blockchain infrastructure itself.

It receives a verified application event and continues its workflow.

This creates a foundation for experimenting with machine-to-machine payment workflows.

🧠 AI + Payments

The same architecture can be applied to AI agents.

An agent could theoretically:

Receive Task
     ↓
Analyze Task
     ↓
Request Service
     ↓
Create Payment
     ↓
Wait for Verification
     ↓
Continue Workflow
Enter fullscreen mode Exit fullscreen mode

This does not mean that an AI agent should automatically receive unlimited access to money.

The Gateway can instead become the control layer for:

  • spending limits;
  • authorization;
  • budgets;
  • payment policies;
  • verification;
  • auditing.

This is an important part of making autonomous workflows safer and easier to control.

🚀 Deployment

The Gateway can be managed with PM2:

pm2 start server.js --name myzubster-gateway

pm2 save

pm2 startup

pm2 status
Enter fullscreen mode Exit fullscreen mode

PM2 keeps the Node.js process running and makes it easier to monitor its state.

Nginx can sit in front of Node.js as a reverse proxy:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
Enter fullscreen mode Exit fullscreen mode

A production deployment should also use HTTPS and appropriate security controls.

🧪 Testing the Gateway

Testing starts at the API level.

For example:

curl -X POST \
  https://example.com/api/myz/payment/create \
  -H "Content-Type: application/json" \
  -d '{"tag_id":"TEST-001","amount":10}'
Enter fullscreen mode Exit fullscreen mode

The Gateway can return a unique payment identifier:

{
  "success": true,
  "payment_id": "myz_payment_123",
  "status": "pending"
}
Enter fullscreen mode Exit fullscreen mode

The verification workflow then continues from there.

📊 Dashboard

The Gateway also exposes an application-level dashboard.

It can track:

Total Payments
Pending Payments
Paid Payments
Total XMR
Total MYZ
Enter fullscreen mode Exit fullscreen mode

This becomes increasingly useful as the number of connected devices grows.

A single Gateway can coordinate payments from:

Robot
  │
Cardputer
  │
Android
  │
Marketplace
  │
IoT
  │
AI Agent
  ↓
MYZUBSTER GATEWAY
Enter fullscreen mode Exit fullscreen mode

🌍 What Does This Change in the Real World?

The goal is not simply to create another API for receiving XMR.

The interesting part is creating reusable infrastructure.

Today:

Cardputer → Payment Gateway
Enter fullscreen mode Exit fullscreen mode

Tomorrow:

Robot → Payment Gateway
Enter fullscreen mode Exit fullscreen mode

Then:

AI Agent → Payment Gateway
Enter fullscreen mode Exit fullscreen mode

And eventually:

IoT Device
     ↓
Gateway
     ↓
Payment
     ↓
Verification
     ↓
Physical Service
Enter fullscreen mode Exit fullscreen mode

This is the direction I am exploring with MyZubster.

🔓 Why Open Source?

The Gateway is designed as an open component of the ecosystem.

Other developers can:

  • study the code;
  • propose changes;
  • build new clients;
  • add API endpoints;
  • create IoT integrations;
  • experiment with new payment workflows;
  • build their own services on top of the infrastructure.

The goal is not to create a closed payment system.

It is to create a foundation that developers can inspect, extend, and experiment with.

🛣️ What's Next?

The prototype is only the beginning.

Potential next steps include:

  • 🔐 stronger authentication;
  • 🗄️ production-ready database infrastructure;
  • 📡 more complete on-chain monitoring;
  • 🧾 payment auditing;
  • 🔄 webhooks and event notifications;
  • 🤖 deeper robot integration;
  • 📱 mobile integration;
  • 💳 Cardputer and IoT terminals;
  • 🧠 AI agents;
  • 🛒 marketplace integration;
  • 📊 monitoring and observability.

The long-term goal is to evolve the Gateway from a simple API into payment infrastructure for devices, applications, and autonomous services.

Final Thoughts

The most interesting part of this project is not Node.js.

It is not Nginx.

It is not even the QR code.

The interesting part is what happens when we connect:

Open Source
     +
Monero
     +
APIs
     +
IoT
     +
Robotics
     +
AI
     +
Automation
Enter fullscreen mode Exit fullscreen mode

The result can become an infrastructure where a physical device interacts with a digital system, receives a verified payment event, and continues its workflow automatically.

The project is still evolving.

But the Payment Gateway is becoming one of the fundamental building blocks of the MyZubster ecosystem.

Build the infrastructure.

Connect the machines.

Verify the payment.

Automate the workflow.

🌱🤖💳

MyZubster #Monero #XMR #OpenSource #NodeJS #IoT #Robotics #AI #Payments #Blockchain

Top comments (0)