Introducing A-Payment: A Crypto-First Platform for Payments, Subscriptions, and Software Licensing

Monetizing software should not require a fragile chain of disconnected services.

For many products, especially in Web3, trading, SaaS, automation, and self-hosted infrastructure, the real challenge is not only accepting a payment. The challenge is the full commercial flow around it: authentication, checkout, billing logic, subscriptions, license delivery, license validation, admin operations, user management, renewals, trials, and product access.

This is why we are introducing ADAMANT Payment (ADM-Payment)— a new product currently released as a work in progress with a ready beta version.

ADAMANT Payment is a universal crypto-first self-hosted platform for payments, subscriptions, and software license management. It is designed as an independent product, not tied to ADAMANT Messenger or any single application. The first internal integration target is ADAMANT Tradebot WebUI subscriptions, but the platform itself is built for a much wider range of products: bots, SaaS platforms, desktop applications, Web3 services, private tools, commercial APIs, and self-hosted software.

The original idea and public product discussion are available here:

https://github.com/orgs/Adamant-im/discussions/47

The v1.0.0 release task is tracked here:

https://github.com/Adamant-im/adamant-payment/issues/1

If you are interested in using ADAMANT Payment for your own product, you can contact us here:

https://adamant.business/contact/

Why we built ADAMANT Payment

Most modern software monetization stacks were designed around traditional fiat payments first.

That works well for many businesses, but it often becomes limiting when the product is crypto-native, global, self-hosted, privacy-aware, or sold to users who prefer not to rely on traditional banking rails.

A typical setup may require several separate components:

• one service for authentication;
• another one for payments;
• another one for subscriptions;
• another one for license keys;
• custom scripts for product access;
• an admin panel built from scratch;
• webhooks, callbacks, database glue, and manual support workflows.

ADAMANT Payment is designed to bring these parts together into one coherent platform.

The goal is simple: a product owner should be able to define plans, accept crypto payments, issue licenses, manage users, and let external software validate access through an API — without rebuilding the entire monetization layer again and again.

What ADAMANT Payment does

ADAMANT Payment combines several core modules in one self-hostable solution:

• authentication;
• billing;
• crypto payments;
• trials and paid licenses;
• subscriptions;
• promo and manual licenses;
• user-facing web portal;
• admin dashboard;
• license validation API;
• product branding;
• internationalization;
• operational security features.

The platform is crypto-first by design. Payments are not treated as a late add-on. The current scope includes Bitcoin payments through self-hosted BTCPay Server, native ADAMANT payments with unique deposit addresses and on-chain watching, and a development provider for testing flows. The architecture is designed so that additional payment providers (Ethereum, ERC20, stablecoins and others) and chains can be added later without rewriting the billing core.

For users, ADAMANT Payment provides a clear web interface for sign-in, catalog browsing, checkout, and license management.

For product owners, it provides an admin dashboard to manage accounts, licenses, invoices, wallets, plans, and access rights.

For external software, it provides API-based license validation, so a bot, SaaS backend, relay, desktop app, or other product can programmatically check whether a user has active access.

Who ADAMANT Payment is for

ADAMANT Payment is not just a payment page. It is a monetization layer for software products.

It can be especially useful for teams building:

Trading bots and automation tools

Trading bots often need license-based access, subscription plans, per-market or per-exchange restrictions, and private deployments. ADM-Payment can issue scoped licenses after payment and let the bot or relay validate access through the API.

A practical example is a trading bot WebUI subscription: a user buys a license, receives access, and the bot or public relay checks the license before enabling the service.

SaaS products with crypto-native users

Some SaaS products serve users who prefer crypto payments over bank cards. ADM-Payment gives these products a way to accept crypto, manage subscriptions, and control access without depending entirely on traditional payment processors.

This is useful for global tools, developer services, analytics platforms, automation dashboards, and privacy-aware services.

Desktop applications and private tools

Not every commercial product is a cloud SaaS. Some software is installed locally or deployed privately. ADM-Payment can still act as the licensing and billing backend: the desktop app or private service can call the validation API and check whether the license is active.

Web3 services and infrastructure products

Web3 users are already comfortable with wallets, signatures, and blockchain payments. ADAMANT Payment supports crypto-oriented authentication flows, including ADM and Ethereum wallet sign-in, alongside classic email-based login.

That makes it suitable for blockchain explorers, node services, relays, indexers, DeFi tools, Web3 dashboards, and ecosystem-specific utilities.

Self-hosted commercial products

Many teams want to keep control over their infrastructure, users, payments, and business data. ADM-Payment is designed to be self-hostable, with PostgreSQL and Node.js as the foundation.

Instead of depending on a closed licensing SaaS, a product owner can deploy and adapt the platform to their own rules.

Practical use cases

Here are several scenarios where ADAMANT Payment can be effective.

1. Sell subscriptions for a trading bot

A trading bot developer can create plans such as Basic, Pro, or Enterprise. Users pay in crypto, receive licenses, and the bot validates access through the API.

Licenses can be scoped by product-specific parameters, such as exchange and trading pair. This allows precise access control instead of a simple “paid / not paid” model.

2. Launch a crypto-first SaaS

A SaaS team can use ADM-Payment as the commercial layer: users sign in, choose a plan, pay, and receive access. The SaaS backend checks license status before enabling premium features.

This can reduce the amount of custom billing code needed for the first production version.

3. Offer trials without manual approval

ADAMANT Payment supports trial logic. A product can let users claim a trial automatically, while still enforcing rules such as one trial per defined scope.

This is useful for onboarding users quickly while preventing unlimited repeated trials.

4. Manage promo and manual licenses

Not every customer comes through a standard checkout flow.

Sometimes a team needs to issue a license manually, give access to a partner, create a promo campaign, or extend access for a specific account. ADAMANT Payment includes paid, trial, promo, and manual license types, giving operators flexibility without direct database edits.

5. Build white-label monetization for multiple products

The platform is designed to be product-neutral. Branding can be configured through environment variables, and the data model uses generic product slugs instead of hardcoded ADAMANT-specific assumptions.

This makes ADM-Payment suitable not only for our own products, but also for independent deployments.

6. Add crypto payments without giving up infrastructure control

Many payment and licensing platforms are closed SaaS products. They can be convenient, but they also define the rules.

ADAMANT Payment is designed for teams that want more control: control over deployment, data, payment logic, product access, branding, and future integrations.

A few technical details

ADAMANT Payment is built as a modern monorepo using pnpm and Turborepo.

The v1.0.0 scope includes:

• API backend based on Fastify 5;
• Prisma ORM;
• PostgreSQL database;
• React 18 frontend with Vite;
• separate user web app and admin app;
• shared packages for common logic;
• JWT sessions with refresh cookies;
• ADM message-code authentication;
• Ethereum SIWE authentication;
• email and password authentication;
• Turnstile captcha;
• BTCPay Server integration for Bitcoin payments;
• native ADAMANT payment provider with unique deposit addresses and on-chain watcher;
• idempotent webhooks;
• admin API key;
• optional 2FA;
• IP and fingerprint lockout;
• audit logging;
• Localization i18n;
• GitHub Actions CI for install, Prisma generation, build, lint, and typecheck.

The architecture separates user-facing and admin-facing areas. External products interact with the platform through API endpoints, for example to validate licenses or check subscription status.

This API-first approach is important: ADAMANT Payment is not only a checkout page, but a backend service that other software can rely on.

Security as part of the architecture

Payments and licenses are sensitive by nature. If the licensing layer is weak, the product access model is weak too.

ADAMANT Payment is designed with security controls at the architecture level:

• separate user and admin areas;
• protected authentication flows;
• access control;
• secure license validation APIs;
• admin API key;
• optional ADM and ETH 2FA;
• captcha support;
• IP and fingerprint lockout;
• audit logging.

For Web3 products, wallet-based authentication is especially useful. Users can authenticate through crypto identity flows instead of being forced into email-only accounts. At the same time, email and password login remains available for more traditional users.

This gives product owners flexibility: a deployment can serve both crypto-native and mainstream audiences.

Work in progress, v1 ready

ADAMANT Payment is currently a work in progress with a ready beta version.

That means the foundation is already usable, but we are still improving the product, polishing flows, expanding documentation, and collecting real integration feedback.

The current release direction includes the v1.0.0 platform foundation, with the first production integration focused on ADAMANT Tradebot WebUI subscriptions. After that, the roadmap includes more payment providers, more chains, OpenAPI documentation, subscription renewal automation, and third-party product integrations.

We are especially interested in feedback from teams that need:

• crypto payments;
• software licenses;
• subscription access;
• trial flows;
• Web3 authentication;
• self-hosted billing;
• API-based license validation;
• custom payment providers;
• product-specific licensing rules.

Screenshots

More than a payment gateway

ADAMANT Payment is not trying to be just another payment gateway.

It is a practical monetization foundation for software products that need crypto payments, subscriptions, and license management in one place.

For a small team, it can reduce development time.

For a Web3 project, it can provide a more natural user experience.

For a self-hosted product, it can keep control in the hands of the product owner.

For a commercial bot, SaaS, or desktop application, it can become the missing layer between “user paid” and “user has access”.

That is the real problem ADAMANT Payment is built to solve.

If you are building a product that needs crypto-first monetization, subscriptions, or license management, we would be happy to discuss your use case.

Contact us here:

https://adamant.business/contact/

Introducing A-Payment: A Crypto-First Platform for Payments, Subscriptions, and Software Licensing was originally published in ADAMANT on Medium, where people are continuing the conversation by highlighting and responding to this story.