💳 Cardputer Zero + XMR: Contactless Monero Payments with MyZubster
UHF · XMR · IoT · Bluetooth · QR Payments · Open Source
The MyZubster ecosystem is moving another step closer to physical payments.
We've been integrating Cardputer Zero with the MyZubster Gateway to create a compact payment terminal capable of reading contactless UHF tags and initiating a Monero payment workflow.
The idea is simple:
Tap → Identify → Create Payment → Show QR → Verify → Confirm
Instead of building a completely new payment terminal, we're connecting inexpensive hardware, an Android interface and the existing MyZubster Gateway.
📷 What Is Cardputer Zero?
Cardputer Zero is a compact hardware device that can be used as part of an IoT interface.
In this project, the device acts as the physical entry point for a contactless payment workflow.
Its responsibilities are intentionally simple:
- 📡 read a UHF tag;
- 📱 communicate with the Android application;
- 🖥️ provide local feedback through the display;
- 🔗 pass the tag identifier to the payment system.
The Cardputer does not need to manage the entire payment process.
It becomes a hardware interface for the Gateway.
🔄 The Architecture
The current concept separates the system into three main layers.
┌──────────────────────────────────────────┐
│ CARDPUTER ZERO │
│ │
│ UHF Tag Reader │
│ Bluetooth │
│ Display │
└───────────────────┬──────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ ANDROID APP │
│ │
│ Receives Tag ID │
│ Creates Payment Request │
│ Displays XMR QR Code │
│ Checks Payment Status │
└───────────────────┬──────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ MYZUBSTER GATEWAY │
│ │
│ Payment Creation │
│ Payment Record │
│ XMR Address │
│ Payment Verification │
│ Status Management │
└──────────────────────────────────────────┘
This separation is important.
The hardware doesn't need to know how the blockchain payment infrastructure works.
The Android application doesn't need to implement the entire Monero backend.
The Gateway remains responsible for payment logic.
📡 Step 1 — Read a UHF Tag
The user brings a UHF tag close to the Cardputer.
The device reads the tag identifier.
For example:
User
↓
UHF Tag
↓
Cardputer Zero
↓
TAG-TEST-002
The identifier can then be transmitted to the Android application over Bluetooth.
The tag acts as a convenient physical trigger for the workflow.
It does not itself represent a Monero transaction.
📱 Step 2 — Android Receives the Tag
The Android application receives the identifier from the Cardputer.
For example:
TAG-TEST-002
The application can then associate the tag with a payment request.
A simplified request looks like:
const response = await fetch(
"https://api.myzubster.io/cardputer/payment/create",
{
method: "POST",
headers: {
"Content-Type": "application/json"
},
body: JSON.stringify({
tag_id: "TAG-TEST-002",
amount: 0.01
})
}
);
The exact production endpoint and authentication model should be configured according to the deployed Gateway environment.
🪙 Step 3 — The Gateway Creates the Payment
The MyZubster Gateway handles the backend side.
The workflow can include:
- creating a payment record;
- generating or assigning the payment destination;
- recording the requested amount;
- generating the information needed by the wallet;
- monitoring the payment;
- updating the payment status.
Conceptually:
Android
↓
POST /payment/create
↓
Gateway
↓
Payment Record
↓
XMR Payment Information
↓
Android
The important architectural decision is that payment logic remains on the Gateway rather than inside the Cardputer.
🔲 Step 4 — Display an XMR QR Code
Once the payment request is created, the Android application can display a Monero payment QR code.
The user scans it with a compatible Monero wallet.
The flow becomes:
UHF Tag
↓
Cardputer
↓
Android
↓
MyZubster Gateway
↓
XMR Payment Request
↓
QR Code
↓
Monero Wallet
This keeps the hardware simple while still allowing a physical device to initiate a privacy-focused payment workflow.
✅ Step 5 — Payment Verification
After the user sends the payment, the Gateway can monitor the transaction and update the payment record.
For example:
created
↓
pending
↓
detected
↓
confirming
↓
paid
The Android application can query the payment status.
Example:
const status = await fetch(
`/api/cardputer/payment/status/${payment_id}`
);
This means the terminal doesn't need to understand the details of Monero transaction processing.
It only needs to know:
Has the payment reached the required state?
🛠️ API Design
The Cardputer integration introduces a dedicated API surface.
| Method | Endpoint | Purpose |
|---|---|---|
| POST | /api/cardputer/payment/create |
Create a payment |
| GET | /api/cardputer/payment/status/:id |
Retrieve payment status |
| PUT | /api/cardputer/payment/status/:id |
Update payment state |
| GET | /api/cardputer/payments |
List payment records |
| GET | /health |
Gateway health check |
For a production deployment, these endpoints should also be protected with appropriate authentication, authorization, rate limiting and transport security.
🔧 Cardputer Firmware
The Cardputer can communicate with the Android application over Bluetooth.
A simplified Arduino-style implementation looks like:
#include <M5Cardputer.h>
#include <BluetoothSerial.h>
BluetoothSerial SerialBT;
void setup() {
M5Cardputer.begin();
SerialBT.begin("Cardputer-Zero");
M5Cardputer.Display.println(
"Cardputer Zero"
);
}
void loop() {
if (SerialBT.available()) {
String command =
SerialBT.readString();
if (command == "SCAN") {
String tag = readTag();
SerialBT.println(tag);
M5Cardputer.Display.println(
"TAG: " + tag
);
}
}
}
The important principle is modularity.
The firmware handles hardware.
The Android application handles the user interface.
The Gateway handles payment infrastructure.
💰 Complete Payment Flow
Putting everything together:
1. User taps UHF tag
↓
2. Cardputer reads tag
↓
3. Cardputer → Bluetooth → Android
↓
4. Android → Gateway API
↓
5. Gateway creates XMR payment
↓
6. Android displays QR code
↓
7. User pays with Monero wallet
↓
8. Gateway detects transaction
↓
9. Payment reaches required state
↓
10. Android displays confirmation
This is the core experiment.
A small physical device becomes the entry point to a complete decentralized payment workflow.
🧪 Test Mode vs Production
One important distinction needs to be made.
A successful integration test demonstrates that the components can communicate.
It does not automatically mean that the system is ready for unrestricted production payments.
A production deployment would still need testing for:
- authentication;
- secure Bluetooth communication;
- API authorization;
- network failures;
- duplicate payment requests;
- replay attacks;
- payment confirmation rules;
- transaction monitoring;
- device recovery;
- key management;
- logging;
- privacy;
- hardware reliability.
The goal of the current implementation is to establish the integration and validate the architecture.
🌍 Why This Matters for MyZubster
This project connects several parts of the ecosystem:
MYZUBSTER
│
┌──────────┼──────────┐
↓ ↓ ↓
IoT Gateway Monero
│ │ │
└────┬─────┴─────┬────┘
↓ ↓
Cardputer Payment
│
↓
User
This is particularly interesting for the robotics ecosystem.
A future robot could contain a similar payment interface.
For example:
Robot
↓
User selects service
↓
UHF / NFC / QR
↓
Gateway
↓
XMR Payment
↓
Verification
↓
Robot performs service
The payment layer therefore becomes part of the robot's service workflow.
🤖 From Payment Terminal to Robot Economy
Imagine a robot bartender.
The user approaches the robot.
The system identifies the service.
The user initiates payment.
The Gateway verifies the payment.
The robot receives authorization.
Then the robot performs the task.
User
↓
Robot
↓
Payment Request
↓
XMR
↓
Gateway
↓
Verification
↓
Authorization
↓
Physical Service
This is the larger MyZubster vision:
connecting digital payments to physical autonomous services.
📅 TAZ DAY #1 — Riccione
The next step is bringing these experiments into a physical environment.
TAZ DAY #1 is planned for Riccione, Italy, in September 2026.
The event is intended to demonstrate different parts of the MyZubster ecosystem, including robotics, IoT and Monero payment workflows.
The Cardputer integration adds another possible interaction point:
contactless hardware → XMR payment → physical service.
That is where the software architecture meets the real world.
🔓 Open Source Development
The project is being developed through open-source repositories and issue-driven development.
The development loop is:
Idea
↓
GitHub Issue
↓
Implementation
↓
Pull Request
↓
Testing
↓
Merge
↓
Integration
↓
Physical Test
This approach makes it possible for developers to work on individual components without needing to understand the entire ecosystem.
One contributor can work on firmware.
Another can work on Android.
Another can improve the Gateway.
Another can work on Monero integration.
Together, they form one system.
🚀 What's Next?
The Cardputer integration opens several possible directions:
📡 More contactless interfaces
Additional tag and device integrations could be explored.
🤖 Robot payments
The same Gateway could support payments for robotic services.
🌱 IoT services
Sensors and physical infrastructure could initiate service workflows.
🧠 AI agents
EVA and other AI components could eventually coordinate payment-related events.
💳 Physical decentralized terminals
Small devices could become interfaces between users and the MyZubster ecosystem.
Final Thoughts
The Cardputer Zero integration may look like a small hardware experiment.
But architecturally, it represents something bigger.
We now have a path connecting:
UHF → Bluetooth → Android → Gateway → Monero → Payment Verification
And that same architecture can potentially be reused for:
🤖 robots
🌱 smart gardens
📡 IoT devices
🏪 physical services
🧠 AI agents
The goal isn't to create another payment terminal.
The goal is to build open infrastructure that lets physical devices interact with decentralized services.
The next step is testing it outside the development environment.
Tap.
Pay.
Verify.
Act.
That's the direction we're exploring with MyZubster.
💳📡🪙🤖🌱
Top comments (0)