What I Am Building with MyZubster and Zorgax: An AI-Assisted Payment System

Nicola Lorenzini — Fri, 04 Sep 2026 09:07:57 +0000

What I Am Building with MyZubster and Zorgax: An AI-Assisted Payment System

My name is Nicola, and I use the name N4K48 on GitHub.

I am currently developing and exploring a personal product idea within the MyZubster ecosystem, with the assistance of Zorgax, its AI and automation layer.

The idea is to create software that helps people and small organizations manage digital payments more clearly and safely.

This is not intended to be an autonomous system that moves money without permission. It is an AI-assisted workflow where the software prepares, explains, monitors, and verifies payment operations while the user remains in control.

You can follow my public work here:

The problem I want to solve

Digital payments often involve more complexity than users expect.

A person may need to understand:

which payment method is available;
how much must be paid;
whether fees are included;
whether the payment was submitted;
whether it was actually confirmed;
why an operation failed;
whether the recipient and amount are correct;
whether an invoice has been settled;
what action should be taken next.

Payment providers expose technical states, identifiers, errors, and confirmation processes. These details are useful to developers, but they can be confusing for ordinary users and small organizations.

My product idea is to place an understandable AI assistance layer above this complexity.

The role of MyZubster

MyZubster provides the technical environment in which I am exploring the idea.

The ecosystem already contains or experiments with concepts such as:

user authentication;
payment intents;
checkout workflows;
transaction states;
purchase history;
receipts;
payment verification;
subscriptions and access plans;
conventional and cryptocurrency payment paths;
audit and evidence records.

This makes MyZubster a useful environment for testing how an intelligent payment assistant could work.

The project is still under development. Existing code and automated tests demonstrate specific technical behaviors, but they do not prove that every payment feature is already deployed or ready for unrestricted production use.

The role of Zorgax

Zorgax is the assistance and automation layer supporting the project.

Its purpose is not to become the owner of the user’s money or financial decisions. Zorgax should help users understand the payment process and prepare the next action.

Zorgax could assist by:

interpreting a payment request written in natural language;
checking whether required information is present;
explaining payment methods;
preparing a payment intent;
translating technical errors into understandable language;
monitoring transaction status;
identifying inconsistencies;
matching payments with purchases or invoices;
preparing receipts and reports;
recommending the next step.

The intended workflow is:

USER REQUEST
      ↓
ZORGAX ANALYSIS
      ↓
PAYMENT PROPOSAL
      ↓
USER REVIEW
      ↓
EXPLICIT CONFIRMATION
      ↓
AUTHORIZED PAYMENT PROVIDER
      ↓
INDEPENDENT VERIFICATION
      ↓
CLEAR RESULT

The user remains the decision-maker.

An example

Imagine a small association that needs to collect €50 for a service.

The operator could write:

Prepare a €50 payment request, explain the available methods, and tell me when it has been confirmed.

Zorgax could then:

identify the amount and purpose;
ask for any missing information;
show the available payment methods;
explain relevant fees or limitations;
prepare the payment request;
ask the operator to review it;
wait for explicit authorization;
send the request to the chosen provider;
monitor the resulting status;
prepare a receipt after verification.

The AI should never change the amount or destination silently.

Payment states must remain explicit

A payment is not necessarily complete when it has only been submitted.

The system should use clear states such as:

DRAFT
  ↓
READY
  ↓
AUTHORIZED
  ↓
SUBMITTED
  ↓
PROCESSING
  ↓
CONFIRMED
  ↓
RECONCILED

Other possible states include:

FAILED;
EXPIRED;
CANCELLED;
REFUNDED;
DISPUTED;
VERIFICATION_REQUIRED.

Zorgax should explain these states in plain language without hiding uncertainty.

If verification is unavailable, the system must say so. It should not infer success merely because no error was returned.

AI assistance, not financial authority

This boundary is fundamental to the product.

Zorgax may:

explain;
prepare;
compare;
monitor;
detect anomalies;
summarize;
recommend;
request clarification.

Zorgax must not:

send money without explicit authorization;
modify a recipient or amount silently;
publish financial information;
expose credentials or private keys;
declare an unverified transaction successful;
guarantee financial returns;
make investments for the user;
bypass security or compliance controls.

The operating principle is:

AI PREPARES
     ↓
HUMAN APPROVES
     ↓
PROVIDER EXECUTES
     ↓
SYSTEM VERIFIES

Verification before claims

One of the most important ideas behind the project is that payment results must be supported by evidence.

Depending on the payment method, verification may involve:

signed provider events;
transaction identifiers;
amount and currency matching;
recipient validation;
invoice matching;
confirmation counts;
duplicate detection;
independent status checks;
reconciliation records.

A wallet or provider response alone should not always be treated as final settlement.

For example:

PAYMENT INTENT
      ↓
AUTHORIZED SUBMISSION
      ↓
TRANSACTION IDENTIFIER
      ↓
VERIFY AMOUNT + RECIPIENT + STATUS
      ↓
CONFIRMED
      ↓
RECONCILED

If the evidence is missing or inconsistent, the correct result is VERIFICATION_REQUIRED, not CONFIRMED.

Supporting different payment methods

The long-term vision is to provide one understandable interface for multiple payment methods.

Possible integrations include:

card payments;
bank transfers;
payment links;
invoices;
subscriptions;
digital wallets;
authorized cryptocurrency payments.

These methods have different security requirements and confirmation models. They should remain separate internally, even if Zorgax presents them through one clear user experience.

The first product version should support only one carefully selected provider.

Security and privacy

Payment assistance requires strong security boundaries from the beginning.

The project should follow principles including:

no passwords in AI prompts;
no wallet seeds or private keys processed by Zorgax;
no payment credentials stored in logs;
minimum necessary data collection;
short-lived authentication tokens;
strict separation between users;
explicit authorization for consequential actions;
idempotency protection;
webhook signature verification;
complete audit history;
limited retention of sensitive data;
human review for exceptional operations.

Zorgax should receive only the minimum information required to assist with a task.

The first useful version

The first MVP could include:

user authentication;
creation of a payment intent;
AI-assisted explanation;
explicit user approval;
integration with one payment provider in test mode;
payment-status monitoring;
secure provider-event verification;
receipt generation;
basic reconciliation;
an audit log.

This MVP would answer an important question:

Does AI assistance make payment workflows easier to understand without reducing security or user control?

Current development status

The idea is currently being explored through MyZubster and Zorgax.

Some relevant building blocks already exist in the ecosystem, including authentication, payment-intent models, checkout workflows, access plans, transaction records, and automated tests.

However, the complete AI-assisted payment product is not yet finished.

The remaining work includes:

defining the first target customer;
selecting the initial payment provider;
designing the complete confirmation workflow;
establishing the payment-state contract;
implementing independent verification;
testing failure and replay scenarios;
reviewing security and compliance requirements;
running a controlled pilot.

I want to document this distinction honestly: implemented components are not the same as a finished product or a production deployment.

My individual contribution

My role is to develop the product concept and help shape its user experience.

I am focusing on the question:

How can AI make payments easier to understand while keeping every important financial decision under human control?

My individual project includes:

defining the user problem;
designing the payment-assistance workflow;
establishing human-approval boundaries;
documenting payment states;
testing the concept;
preparing public documentation;
collecting feedback;
evaluating a future independent product.

The initial experimentation is taking place with MyZubster and Zorgax, while the product may later become a separate project with its own repository and identity.

Possible business model

The product could eventually use a subscription or managed-service model.

Free

test-mode payment requests;
basic AI explanations;
limited payment history.

Professional

payment links and invoices;
receipt generation;
reconciliation;
exports;
advanced assistance.

Organization

multiple operators;
approval roles;
audit logs;
dashboards;
provider integrations;
priority support.

Managed pilot

initial configuration;
workflow customization;
provider integration;
staff training;
technical support.

The first commercial validation should come from a small paid pilot rather than from building every possible feature.

Next steps

My proposed next steps are:

select one concrete customer profile;
choose one payment provider;
design the payment-state model;
build a test-mode prototype;
verify all confirmation boundaries;
test successful and failed payments;
run a controlled pilot;
measure whether users understand payments more easily;
publish verified results;
decide whether to develop the product independently.

Follow the project

I will continue documenting my work and experiments publicly.

You can follow me here:

I am interested in feedback from developers, product designers, payment specialists, security researchers, small organizations, and potential testers.

Conclusion

The product I am creating with MyZubster and the assistance of Zorgax is an AI-assisted payment system.

Its purpose is not to replace the user.

Its purpose is to make payment workflows easier to understand, safer to manage, and clearer to verify.

ZORGAX ASSISTS
      ↓
THE USER DECIDES
      ↓
THE PROVIDER EXECUTES
      ↓
MYZUBSTER RECORDS AND VERIFIES

This is the idea I am currently developing.

Author: Nicola — N4K48

GitHub: github.com/nicolaususnicola-lgtm

This is an experimental software project under development. It is not a bank, payment institution, investment service, or guarantee of financial returns. References to current development do not imply production readiness, regulatory approval, partnership, or verified adoption.

DEV Community: Nicola Lorenzini

What I Am Building with MyZubster and Zorgax: An AI-Assisted Payment System

What I Am Building with MyZubster and Zorgax: An AI-Assisted Payment System

The problem I want to solve

The role of MyZubster

The role of Zorgax

An example

Payment states must remain explicit

AI assistance, not financial authority

Verification before claims

Supporting different payment methods

Security and privacy

The first useful version

Current development status

My individual contribution

Possible business model

Free

Professional

Organization

Managed pilot

Next steps

Follow the project

Conclusion