ADAMANT Payment v1.0 — universal crypto-first platform for payments, subscriptions and license management

[adamant-al]

ADAMANT Payment (adamant-payment) is a new infrastructure piece for the ADAMANT ecosystem and for any product that needs crypto-native monetization without stitching together multiple third-party services.

It replaces the legacy adamant-client-auth approach with a modern, product-neutral platform: authentication, billing, crypto payments, subscriptions, license management, user portal, and admin console in one self-hostable solution.

The first integration target is ADAMANT Tradebot WebUI subscription (scenario B): users buy a subscription or trial on adamant-payment, receive a scoped license token, and the bot connects outbound to the public WebUI relay. The platform is not tied to Tradebot — it is designed as a standalone product for bots, SaaS, desktop apps, and Web3 services.

Tracking

Release task: Adamant-im/adamant-payment#1

Headline

Universal crypto-first platform for payments, subscriptions and software license management.

Key strengths of adamant-payment

Crypto-first by design

The platform is built for cryptocurrency payments from the start, not as a secondary add-on. It is a natural fit for Web3 projects, trading bots, SaaS products, and software sold to a global audience. Payments in Bitcoin, ADAMANT, and other cryptocurrencies.

All-in-one platform

Auth, billing, crypto payments, subscriptions, license management, user portal, and admin panel are combined in one solution. No need to glue multiple third-party services together or build complex integration logic from scratch.

Built-in licensing for software products

adamant-payment can automatically issue licenses after payment, manage expiration dates, subscriptions, plans, and product access. External applications can validate licenses through the API (relay, bots, desktop apps).

Flexible sign-in: email or crypto-only

Users can sign in with a traditional email account or through cryptographic authentication using ADM or ETH wallet sign-in (SIWE). Especially useful for Web3 users; the platform can work without mandatory email-based identity.

Included frontend and admin panel

The solution ships with a user-facing interface and an admin dashboard. Customers manage payments, licenses, and subscriptions; product owners manage users, orders, plans, and access rights.

Universal and product-independent

adamant-payment is not tied to ADAMANT Messenger or any specific application. White-label branding via BRAND_* env vars. Generic product slugs in the data model.

API-first architecture

REST API under /v1/... for external software, bots, SaaS products, and desktop applications. Products can check license status, subscription validity, and user access programmatically.

Self-host friendly and data-controlled

Deploy on your own infrastructure (PostgreSQL, Node.js). Full control over users, payment logic, licenses, and business data.

No dependence on closed platforms

Unlike Stripe, Paddle, Lemon Squeezy, or traditional licensing SaaS, adamant-payment can be adapted to your own rules, crypto payment flows, pricing models, and products.

Ready foundation for commercial SaaS

Covers the core monetization flow: user registration → payment → access delivery → subscription renewal → administration → product integration.

Security built into the architecture

Designed for payments, licenses, and access rights at the architectural level: separation of user and admin areas, access control, protected authentication, secure license validation APIs. Admin panel supports ADM 2FA and ETH 2FA, captcha, IP + fingerprint lockout, and audit logging.

v1.0 scope

Area	What is included
Auth	ADM message code, Ethereum (SIWE), email + password; JWT + refresh cookies; Turnstile captcha
Billing	Catalog, trial (14 days, once per exchange + pair globally), paid / promo / manual licenses; hot-reload config/ for plans and promo codes
Payments	BTCPay Server (BTC), ADM-native (unique deposit address + on-chain watcher), dev provider; idempotent webhooks
Admin	Stats, accounts, licenses, invoices, ADM/BTC wallets; API key + optional 2FA; i18n (en/ru)
Web	Sign-in, catalog, checkout, license management; i18n; branding
Stack	pnpm + Turborepo — Fastify 5, Prisma, PostgreSQL, React 18 (Vite)
CI	GitHub Actions — install, Prisma generate, build, lint, typecheck

Requirements and expectations

Product requirements

1. Product neutrality — no hardcoded tradebot or ADAMANT branding in DB enums; configurable per deployment.
2. License scope — one license per exchange + pair; trial once per scope globally; validation API for relay and external products.
3. Payment correctness — idempotent webhooks and ADM watchers; unique externalId / txid; paid license issued or extended on settlement.
4. Multi-identity auth — ADM, ETH, and email must coexist; JWT sessions for browser apps.
5. Operator security — admin on separate origin in production; API key, optional 2FA, captcha, lockout, audit trail.
6. Internationalization — English and Russian at launch; extensible i18n in packages/shared.
7. Self-host — documented .env, Docker Compose for Postgres, no mandatory cloud SaaS dependencies.

Integration requirements (ecosystem)

1. Tradebot WebUI (scenario B) — relay validates licenses via adamant-payment API; bot uses outbound connection model.
2. Tradebot API — branch refactor/new-webui-api consumes license validation.
3. Tradebot WebUI — branch refactor/new-stack provides public WebUI + relay.
4. Extensibility — new PaymentProvider implementations (e.g. additional chains) without rewriting billing core.

Release requirements

1. Publish v1.0.0 of adamant-payment and tag GitHub Release.
2. CI green on dev and release PR to main.
3. Documentation complete: auth, billing, payments, admin security, branding, database, BTCPay setup.
4. Smoke tests: auth flows, trial claim, checkout → license, admin panels, license validation endpoint.

Post-v1 roadmap (open for discussion)

• Subscription renewal automation (BTCPay creates invoices only; renewal logic lives in adamant-payment)
• Additional payment providers and chains
• OpenAPI documentation for public API
• Third-party product integrations beyond Tradebot

Feedback welcome

We are preparing the v1.0.0 release and welcome feedback on:

• Integration scenarios for your product (bot, SaaS, desktop app)
• Payment providers and chains you need
• Licensing models (per-seat, per-exchange, time-based, feature flags)
• Self-host deployment experience
• Security and compliance expectations

If you plan to integrate with adamant-payment, please share your use case in this thread.

[al-onyxprotocol]

I would like to add a bit more context on why adamant-payment is important and what kind of feedback would be especially valuable at this stage.

The main idea behind this project is not just to build “another billing panel”, but to create a reusable monetization layer for crypto-native and self-hosted products. Many software projects eventually need the same set of components: user authentication, payments, invoices, subscriptions, licenses, admin tools, product access control, and an API for external services. Usually, this means integrating several third-party platforms, writing custom glue logic, and accepting limitations around payment methods, user identity, data ownership, or deployment model.

adamant-payment is designed to solve this as a single, product-neutral platform.

For ADAMANT Tradebot WebUI, the first practical use case is straightforward: a user buys or claims access, receives a scoped license, and the bot or relay validates this license through the public API. But the architecture should not be limited to Tradebot. The same model can be used by trading bots, SaaS products, desktop applications, Web3 tools, API-based services, private dashboards, or any product that needs paid access without depending entirely on Stripe-like platforms.

A key point here is crypto-native identity. Users should not be forced into email-only accounts if the product itself is built around wallets, blockchain accounts, or pseudonymous access. Supporting ADM and ETH wallet sign-in, together with traditional email login, gives product owners more flexibility. Some projects may want a familiar email-based flow; others may prefer a wallet-first experience. Both should be possible.

Another important part is licensing. In many crypto and bot-related products, payment alone is not enough. The product needs to know what exactly the user has access to: which exchange, which pair, which feature set, which plan, which expiration date, and whether the license came from a trial, paid purchase, promo code, or manual admin action. Having this model built into the platform from the beginning makes integrations cleaner and safer.

Security is also a major reason to keep this as a dedicated platform rather than a small ad-hoc billing script. Payment processing, license issuing, admin actions, API keys, user accounts, and access validation are all sensitive areas. Separating user and admin surfaces, supporting 2FA for admins, adding captcha and lockout protections, and keeping an audit trail are not “nice to have” features here — they are part of the core architecture.

For self-hosted products, data control is equally important. Some teams do not want to route all users, payments, license data, and business logic through closed SaaS platforms. adamant-payment should allow them to run the whole monetization layer on their own infrastructure, adapt it to their rules, and extend payment providers or license models when needed.

The most useful feedback now would be practical integration feedback:

1. Would this licensing model work for your product?
2. Do you need licenses by user, device, exchange, pair, feature, API key, domain, or another scope?
3. Which payment methods or blockchains would be important after BTC and ADM?
4. Should subscription renewals be fully automated in v1.x, or is manual/admin-assisted renewal acceptable for the first release?
5. What API endpoints would external products need most urgently?
6. What admin features are required for real-world operation: refunds, manual extensions, invoice notes, user blocking, usage limits, license transfer, team accounts?
7. What deployment format is preferable: Docker Compose only, standalone Node.js service, Helm chart, or something else?

I think the strongest direction is to keep adamant-payment simple enough for the first production release, but strict in the areas where mistakes are expensive: payment correctness, idempotency, license validation, security, and clean product-neutral architecture.

If the v1.0 foundation is done well, this can become a reusable commercial infrastructure component not only for ADAMANT-related tools, but also for external crypto-first products that need self-hosted billing, payments, subscriptions, and software licensing in one place.

[metalisk]

Great idea, I want to see it live action