Non-custodial Payment and Access Orchestrator

Subscriptions without the billing code

You don't have to code the custom logic of subscription for every project of yours all other again, even if it may be mostly copy-paste. Instead your application will request:

GET /subscriptions/{id}

and receive the current state. The platform handles the lifecycle.

Subscription
    │
    ├── created
    ├── trial
    ├── active
    ├── renewal
    ├── due period
    ├── payment #1 (failed)
    ├── payment #2 (abandoned)
    ├── payment #3 (success)
    .....
    ├── postpayment grace period (?)
    ├── payment #3 (success)
    ├── active
    ....
    ├── renewal
    ├── postpayment grace period (?)
    ├── no payment attempts
    ├── past due
    └── cancelled

Entitlements, not just subscriptions or quotas

A subscription determines what a customer has paid for. An entitlement, on the other hand, grants him actual rights and capabilities.

The service keeps these concerns separate. Access can be granted by a subscription, a one-time purchase, a trial, a grace period, an administrator grant, purchased credits, or other sources — and multiple entitlements can coexist.

This makes billing and access independent, composable, and auditable. Your product doesn't have to ask: "Is this user subscribed?".
Instead it will: "What is this user entitled to right now?"

Accept cryptocurrencies directly

          Customer
              │
              │
           checkout
            page
              │
              ▼
        Cryptocurrency
              │
              │
           crypto
           payment
              │
              ▼
              │
          Blockchain
              │
              │
              ▼
        Your own wallet
              │
              ⟳
              │
          the └──⟳────↻ service
            verifies the payment

USDT, Solana and others

Into your non-custodial wallets. We don't need your private keys.

And even Monero?

Yes. We verify that the right amount of XMR has arrived into your wallet, provided that the recipient shares the necessary data points. A specially dedicated view-only wallet should be created in order to protect your privacy.

Or so is for the individual users as well:

    Plan A-1:
        usage: 7 days
        payment: 3 days

    User #53:
        usage: 10 days
        payment: 5 days

    User #479:
        usage: 7 days
        payment: 7 days

    User #29:
        usage: 3 days
        payment: 1 day

    Plan A-2:
        payment: first
        usage: 30 days

Customly deferred payments

This could be useful for negotiated arrangements or trusted customers.

Suppose, a user is your neighbour. He's trustworthy and a nice chap overall. Gift him a carrot Move him on a post-payment plan then. Why not?

After some time, the same guy has begun to ask for more, to delay already deferred payments and even to flirt with your girlfriend? The chap has gradually slapped into the abyss, that is. A stick awaits him. Deprive him of the deferred payments.

Both scenarious can be handled via the dashboard.