Zoneless is a self-hosted stablecoin payments stack with a Stripe-shaped API

The API is shaped like Stripe on purpose, not by accident

The compatibility claim is the central design decision, and the README states it plainly. Zoneless uses familiar resources such as Checkout Sessions, Payment Links, Customers, Products, Subscriptions, Accounts, Transfers and Payouts. It also follows Stripe's object shapes, webhook patterns and idempotency model.

The SDK example shows how direct the resemblance is:

import { Zoneless } from '@zoneless/node';
const client = new Zoneless('sk_live_z_YOUR_API_KEY', 'https://api.zoneless.com');

const session = await client.checkout.sessions.create({
  success_url: 'https://yoursite.com/success',
  cancel_url: 'https://yoursite.com/cancel',
  line_items: [
    {
      price_data: {
        currency: 'usdc',
        unit_amount: 1000,
        product_data: { name: 'My first product' },
      },
      quantity: 1,
    },
  ],
  mode: 'payment',
});

The client construction takes a key with a Stripe-shaped prefix and a base URL, and the checkout call takes success_url, cancel_url, line_items with price_data and currency and unit_amount, and a mode. If you have written a Stripe integration, the shape of this code is not a surprise, which is the entire point of the compatibility work.

The currency is usdc and the unit_amount is in the smallest unit, 1000 being ten dollars' worth, so the amount conventions follow the same integer-based model.

The reason to care about the shape rather than the exact routes is that a compatibility layer lets you evaluate a processor without rewriting the integration. The README's guide list includes one specifically titled Run Stripe and Zoneless side by side, and another for moving an existing Stripe Connect payout flow, which is what a migration in practice looks like.

The scope of the API is stated as covering checkout, subscriptions and marketplace payouts, with the full resource and endpoint list in the API reference on docs.zoneless.com.

Marketplace features: connected accounts, onboarding, verification and payouts

The features section reads like a Stripe Connect clone, which is the clearest signal of what the project is aimed at.

Seller onboarding happens through a hosted flow where sellers enter their details and connect a wallet. Identity verification is built in as a platform feature, with rules you set and a queue of sellers to review, so a marketplace can gate who gets paid out without building a compliance workflow. Each seller gets what the README calls an Express-style dashboard for viewing earnings, payouts and account details, so sellers can see their own numbers without you writing a separate portal.

The platform dashboard covers payments, customers, products, subscriptions, connected accounts and balances from one place, and the Payments section covers payments, subscription charges, payouts, refunds and other balance activity. Subscriptions covers recurring payments, invoices and subscription status. Checkout creates products and payment links and lets customers pay with USDC through hosted checkout.

The order of the feature list is instructive because it follows a marketplace's actual operational sequence: you set up the platform, you make things sellable, money comes in, you manage recurring money, you bring sellers in, you check who they are, and you give them a place to look. A payments stack that omits any of those steps is a checkout API with extra steps, and this one has all of them.

The stablecoin choice is what sits underneath. Payments settle in USDC and the topics list includes solana, which tells you which chain the settlement runs on. For a marketplace paying sellers globally, the pitch in the repository description is that you accept payments, manage subscriptions and pay sellers globally in USDC from infrastructure you control, with no middlemen and no fees.

The project also states that it was built for PromptBase, an AI marketplace with more than 500,000 users, and that it runs its seller payout infrastructure in production. That is a provenance claim rather than a benchmark, and it is the kind of claim that matters more than a benchmark would, because it means the payout path has been exercised at some scale.

Running it: one compose file and a setup page

The quick start is three commands and a browser:

git clone https://github.com/zonelessdev/zoneless.git
cd zoneless
docker compose up -d

Then you open localhost/setup to create your platform account and API key. That last step is the onboarding model in miniature: an instance comes up with no platform, and the first visitor to the setup route becomes its owner. The self-hosting guide is where configuration, credentials and deployment options live.

The compose file is worth reading because it shows the shape of the deployment and, more usefully, some decisions that are unusual. MongoDB runs as mongo:7 with a named volume and a replication set: the command is --replSet rs0 with --bind_ip_all, and there is a healthcheck that calls mongosh to check rs.status().ok, and initiates the replica set if it fails. A replica set in local development is unusual, and the reason is that MongoDB transactions require one, so the whole stack is run in a configuration that supports them rather than a standalone mongod that would fail at the first multi-document transaction.

There is also a mongo-express service, and the comment is explicit that it is for local development only and not included in production deployments. It publishes on host port 8082 with default credentials admin and admin123, which is fine for a laptop and would be a problem anywhere else. It waits for the MongoDB healthcheck before starting.

The API service is built from docker/Dockerfile.api, publishes API_PORT with a default of 3333, and takes its environment from .env or the compose defaults. The .env.example file is where the configuration surface is documented, and it is unusually well commented. Each variable says what it does and what happens if you leave it empty.

Several of those defaults matter more than they look. DASHBOARD_PORT is the port the dashboard is served on and is also used to generate links. DASHBOARD_URL, CHECKOUT_URL and PAYMENT_LINK_URL are optional overrides for separate origins, and the file explains the fallback behaviour: if CHECKOUT_URL is unset, checkout is served from the dashboard URL at /c/:id, and if PAYMENT_LINK_URL is unset, payment links fall back to CHECKOUT_URL or the dashboard URL at /b/:id. That is a sensible design for a self-hosted product where each operator has a different domain situation.

Single-tenant by default, with an operator mode for managed hosting

Two flags in the configuration file decide who can use your instance, and both are worth understanding before you expose it.

SINGLE_TENANT is documented as single-tenant mode, where only one platform can be created, and it is the default, set to true. Setting it to false allows multiple platforms. So out of the box, the setup page creates exactly one platform and that is the end of it, which is the right default for a self-hosted install.

OPERATOR_API_KEY switches on operator mode for managed hosting. The comment says to set a long random secret to enable it, gives the generation command openssl rand -hex 32, and states that when it is set, public setup is disabled and platforms are provisioned via the /v1/operator API. It also implies multi-tenant mode and ignores SINGLE_TENANT.

So the same binary serves two quite different deployments. A single shop runs it with default settings and creates its platform at the setup URL. A company that wants to resell the stack runs it in operator mode and provisions platforms programmatically, which is what makes it a hosted offering rather than a self-hosted tool.

APP_SECRET is the third security-relevant variable and it has a nice property. It is the secret key for signing JWTs and encrypting data, and the generation command is openssl rand -hex 64. If left empty, one is auto-generated and stored in the database. That default is a genuinely good choice for a self-hosted product, because the common failure mode of an unset shared secret is every instance running with the same one, and generating and storing one per instance removes that risk. It does mean the secret lives in the database rather than in configuration, which is worth knowing if you rotate it.

The repository also carries a TELEMETRY.md file at the root, which is the place to look for what the stack reports about itself, and a SECURITY.md for disclosure.

An Nx monorepo with Angular, Express and MongoDB

The project structure section describes the layout, and it explains how the pieces relate.

zoneless/
├── apps/
│   ├── api/              # Express.js API backend
│   ├── web/              # Angular dashboard, checkout and onboarding
│   ├── docs/             # Public product docs and API reference
│   └── cli/              # Cli for humans and agents
├── libs/
│   ├── shared-types/     # Shared TypeScript interfaces
│   └── shared-schemas/   # Shared Zod schemas
├── sdks/
│   └── node/             # @zoneless/node
├── docker-compose.yml    # Full-stack Docker setup
└── nx.json

The backend is Express.js, the frontend is Angular at version 20.3, and the CLI is described as being for humans and agents. The shared libraries are TypeScript interfaces and Zod schemas, and having Zod schemas shared between the API and the frontend means the validation rules on an incoming request object are the same rules the forms are generated from.

Nx is the build orchestrator, and the package.json scripts show the shape of the workflow. There is a dev script that brings up MongoDB and mongo-express and then runs the api and web serve targets with streaming output, and separate start scripts for api, web, docs and db. The build scripts produce api, cli, node-sdk, web and docs targets, and the docs build runs an additional docs:generate-md step. Lint runs across all projects, format is Prettier over TypeScript, HTML, SCSS, JSON and Markdown, and test runs the test target across all projects.

For local development the README gives the individual commands:

npm install
docker compose up -d        # MongoDB
npx nx serve api            # API on :3333
npx nx serve web            # Dashboard on :4203
npx nx serve docs           # Docs on :4205

The three ports are worth noting because the dashboard, the API and the documentation site all run at once during development, and the docs site on its own port is what generates the public API reference.

The primary language is TypeScript, the licence is Apache-2.0, the default branch is main, and the last push was on 2026-09-30. The only tagged release is v0.1.0, the initial release, from 2026-03-23, and the package.json version still reads 0.1.0.

Where Zoneless is the wrong choice

Three limits, and the first is about what a self-hosted payments stack asks of you.

The first is that the compliance work does not go away, it moves to you. Stripe's fee buys you not just an API but a card issuer, a chargeback process, a KYC pipeline, an SCA implementation and a set of relationships with regulators. A stack you host gives you the API and none of that. Zoneless has identity verification for sellers and a concept of balances, which are real features, but they are features for moving money under a stablecoin model rather than a substitute for a payment institution's obligations. Whether that trade is acceptable depends on whether the money you are moving is yours.

The second is maturity. There is one tagged release, v0.1.0 from 2026-03-23, and the package version still reads 0.1.0, while the last push was on 2026-09-30. The PromptBase provenance claim says the seller payout infrastructure runs in production, and that is real evidence, but production at one company under one founder is not the same as a maintained open source project with a community of adopters, and a version 0.1.0 with no subsequent tagged release tells you the maintainers have not yet published a release process that you can pin against.

The third is that the Stripe compatibility is a compatibility layer over a different payment model, not an equivalence. Stripe's customer objects, its balance semantics, its dispute and refund states and its Connect payout mechanics are the result of years of working with card networks and with regulators. A stablecoin stack has no card network, has different reversal mechanics, and settles on a different rail with different failure modes. The API shape being familiar makes migration easier; it does not make the operational behaviour the same, and the guides about running Stripe and Zoneless side by side are telling you that both can be present at once, which is what a careful team would do.

The alternative approach is to use a stablecoin payment processor that hosts the stack for you, which gives up the infrastructure control and the absence of middleman fees but removes the self-hosting burden. The difference in approach is that Zoneless moves the trust boundary from the processor to your own operations: you own the key management, the uptime, the database backups, the webhook delivery and the seller dispute handling. For a team that already runs payments infrastructure and has a legal position on stablecoin settlement, that is a reasonable trade. For a team that wants to accept USDC without building a payments operation, it is not.

Editorial conclusion

Adopt Zoneless if you are building a marketplace or selling digital goods in USDC and want to run the payments stack yourself rather than hand it to a processor, since the API follows Stripe's object shapes closely enough that the SDK should feel familiar. Do not adopt it as a drop-in Stripe replacement, because the README describes it as a stack you use alongside or instead of your current setup, and it has exactly one tagged release, v0.1.0, from 2026-03-23. Verify first that your settlement needs match what a self-hosted stack can carry, including the operator mode and single-tenant flags in .env.example, that the seller onboarding and identity verification flow in the dashboard matches what your marketplace requires, that the Stripe webhook and idempotency semantics carry over to your integration, and that you are prepared to run the API, dashboard and MongoDB yourself rather than relying on a hosted processor's compliance work.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. zonelessdev/zoneless on GitHub