Billing & subscriptions
Subscription tiers, how upgrades are processed, and what happens when a trial ends.
Plans and access tiers
Athenum sells four membership levels: Free, Lite, Pro and Pro+. Internally these map to four access tiers — preview, single-domain, multi-domain and full-access — and the tier is what the product checks when it decides whether a feature is unlocked. Each paid family is sold in two billing periods, monthly and yearly. The tier determines concrete limits such as the number of saved layouts, real-time versus delayed data, alerting, data export and how far back time-series queries may reach. Current prices are published in the pricing section rather than repeated here.
What a tier actually unlocks
Access is not one switch. The plan catalog gives every tier a fixed set of named capabilities, and the rest of the product reads that set rather than the plan name. The on/off capabilities are: create API keys, access real-time data, use advanced indicators, receive whale alerts, receive macro alerts, priority support, access the commercial API, export data, and access the Pro prediction-market signal families. Alongside them sit graded limits: a saved-layout quota, an API-key quota, a cap on venues per feature, a cap on how far back a time-series query may reach, an Argus indicator level, the set of chart timeframes you may request, and the set of symbols you may request.
Preview, the Free tier, has every on/off capability off, one saved layout, no API keys, a single symbol, and only the 1h, 4h and 1d timeframes. Single-domain (Lite) turns on real-time data, whale alerts and API-key creation, opens all timeframes and the full symbol list, and unlocks the first Argus level. Multi-domain (Pro) adds advanced indicators, macro alerts, the Pro prediction-market signals, an uncapped venue list and the long lookback window. Full-access (Pro+) adds priority support, the commercial API, data export and the last Argus level. Each paid family is sold monthly and yearly, and the billing period changes the price and the renewal date, never the capability set.
The graded limits are enforced where data is fetched, not only in the interface. A lookback request longer than the tier allowance is clamped down to that allowance rather than rejected. A venue list is sorted by a fixed priority order and truncated to the tier's venue cap, so a lower tier sees the highest-ranked venues instead of an arbitrary subset. A request for a timeframe or symbol outside the tier's allowed sets is refused with a payment-required response. Domain picks carry their own quota: one domain on Lite, three on Pro with at most one from the advanced group, and all five on Pro+, which are selected for you automatically.
Where the plan catalog and the pricing copy disagree
Two separate lists describe the plans. One is the capability catalog the server enforces; the other is the feature list rendered on the pricing page. Neither is generated from the other, and in several places they disagree. For example, the pricing list credits Lite with priority support, but the capability catalog has priority support off for Lite and on only for Pro+. The pricing list credits Lite with all exchanges, while the catalog caps Lite at a small number of venues per feature and lifts the cap only at Pro and above. The pricing list credits Lite with full historical depth, while the catalog gives Lite a short lookback window and reserves the long one for Pro and Pro+.
A further item has no counterpart at all: the pricing list quotes per-tier alert allowances, but the capability catalog models alerting as two on/off capabilities — whale alerts and macro alerts — with no per-tier alert count anywhere in the enforcement path. Where the two lists differ, the capability catalog is what the product actually checks. One pair is also easy to conflate rather than contradictory: creating API keys for your own account is available from Lite upward, while the commercial programmatic API and webhooks are a separate capability that only Pro+ carries.
Payment methods
Two checkout rails are implemented. Pay with card runs through Stripe and sends you to Stripe’s hosted checkout page. Pay with crypto runs through Plisio and issues a hosted crypto invoice; before starting one you pick a supported asset from Bitcoin, Ethereum, Solana, BNB Chain, Zcash, USDT on Tron, USDT on Solana and USDC on Solana. Both rails buy exactly the same membership. A verified billing email is required before checkout can start, so wallet-only accounts need to add and confirm an address first.
How an upgrade works
Upgrades start on the Upgrade page, optionally deep-linked with a plan. You pick a plan family and a billing period, then card or crypto. The app creates a checkout session and redirects you to the provider’s hosted payment page; you return to the app with a billing status in the URL. Crypto checkouts land on a dedicated invoice page showing the destination address, a QR code, the amount, an expiry countdown and a live confirmation counter — the membership activates automatically as confirmations accumulate. If you already hold an active subscription, checkout is refused and the card flow opens the Stripe billing portal so you can change the plan there instead.
Inside a crypto invoice
Choosing crypto creates an invoice at the payment processor and then keeps you on an Athenum-hosted page rather than sending you to the processor's own site. The invoice is opened with a sixty-minute window, and the page shows a countdown against that deadline together with the destination address, a QR code, the quoted crypto amount, the dollar equivalent, and a confirmation counter. A supported asset has to be chosen before the invoice can be created; without one the request is refused. When the processor has not reported how many confirmations it expects, the counter falls back to displaying two rather than showing nothing.
The page does not poll on its own. The countdown ticks locally, but the payment state only refreshes when you press the status button or reload the page; activation itself happens server-side when the processor calls back. The status endpoint answers from the stored record once the invoice has reached a final state, and otherwise queries the processor live. If the processor cannot be reached, the endpoint returns a service-unavailable response that still carries the last known snapshot and asks you to retry shortly, instead of reporting a wrong state.
Amount verification happens at the callback, not on the page. If a completed callback reports a dollar amount that differs from the invoiced amount, or reports no verifiable dollar amount at all, it is translated into a failed payment carrying an amount-mismatch reason and the membership is not activated. The processor's own mismatch status is handled the same way. An expired invoice becomes a failed payment with an expiry reason and a cancelled one a failed payment with a cancellation reason. Expired invoices are not payable again; the page tells you to start a new checkout.
The free trial
A trial lasts seven days, can be started only once per account, and grants the full-access tier for its duration. It is not a card-on-file subscription: it does not recur and nothing is charged. While it runs, the membership card in Settings shows the days remaining, the end date and an “Add payment method” action. When the seven days are over, the account is routed to a closure page that recaps what the trial included and offers two paths — resume Pro+ through the upgrade flow, or continue on the free tier through the domain-selection wizard. Your account, layouts and watchlists are kept either way.
Who is eligible for the trial, and what it excludes
The trial is not bought from the pricing page. It is granted during account onboarding, and three conditions must all hold. First, the identity has to be one the system treats as costly to create: an email signup with a verified address, or a Google account with a verified address. A wallet-only signup is explicitly not eligible. Second, an operational kill switch for trial signups has to be off; when it is on, onboarding completes normally and simply grants no trial. Third, the account must never have used a trial before — a once-per-lifetime flag is stamped inside the same transaction that creates the trial subscription, so two concurrent attempts cannot both succeed.
For its seven days the trial projects the full-access tier with one deliberate exception: API keys cannot be created on a trial. The key endpoint checks both the projected tier and the subscription's plan code, and answers a trial with a distinct trial-specific message instead of the generic upgrade prompt. Two reminder emails are scheduled against the deadline, one when three days remain and one when one day remains. Each is guarded by its own stamp that is written before the message is sent, so a retry can miss a reminder but can never send it twice.
The states a payment and a subscription can have
Every payment the system records carries exactly one of five states: pending, succeeded, failed, refunded or partially refunded. Payments are stored keyed by provider plus the provider's own payment reference, and a repeated callback for the same reference updates the existing record instead of inserting a second one, so a retried webhook cannot duplicate a charge in your history. A failed payment also stores a failure code and message; on the crypto rail those are the amount-mismatch, expiry, cancellation and processing-error reasons described above.
A subscription has a larger state set: incomplete, incomplete_expired, trialing, active, past_due, canceled, unpaid, paused and expired. Only three of them grant access — active, trialing and past_due — and the moves between them are constrained by an explicit transition table, so an invalid jump raises an error instead of quietly corrupting the record. Access is not decided by the status alone. A past_due subscription stops granting access once its grace deadline has passed, and any subscription stops granting access once its expiry timestamp has passed, whatever the stored status still says.
A crypto invoice is tracked separately from both, with its own eight states: new, pending, confirming, completed, expired, cancelled, mismatch and error. Four of them are final — completed, expired, cancelled and error — and once an invoice reaches one of those the app answers from its own record rather than asking the processor again. Mismatch is deliberately not final: an invoice in that state can still move on to pending, confirming, completed or cancelled when the processor reports something new.
When a payment fails
A failed-payment webhook moves the subscription to past_due and stamps a grace deadline seven days after the failure. Access continues inside that window, because past_due is one of the three access-granting states and it is the grace deadline, not the status, that ends access. What the card processor does before that webhook arrives — how many times it retries a declined charge, and over what period — is configured at the processor and is not decided by this application.
Crypto memberships do not auto-charge, so renewal runs as a scheduled job. Seven days before the period ends, and again at three days and one day, it creates or reuses an open renewal invoice and emails it to you; an invoice still inside its window, or already confirming, is reused rather than replaced. If the period ends unpaid, the subscription is marked past_due with a grace deadline seven days after the period end and a past-due notice goes out. When that deadline passes without payment the subscription is canceled and an expiry notice is sent. A renewal invoice that fails while the period is still running does not trigger past_due.
Two side effects are worth knowing. A grandfathered promotional offer is marked forfeited when the subscription moves off that offer, is canceled, or expires, and a later checkout that asks for the same offer is then refused. And whenever a subscription transitions into a state that no longer grants access, the cached session claims for that account are flushed immediately instead of being left to expire on their own, so the change takes effect on the next request rather than after a cache lifetime.
Managing an existing membership
The membership card in Settings is the control surface. Card subscribers get “Manage membership,” which opens the Stripe billing portal, plus a separate action for the stored payment method. Cancelling is offered as “End at period end”: the subscription is marked to stop at the end of the current billing period rather than immediately, and a subscription already scheduled to end shows “Reactivate membership” instead. Plan changes that reduce your tier, or switch yearly to monthly, are scheduled for the period end rather than applied at once. Invoices are listed with date, status, amount and a link to the receipt once the first billing cycle completes. If a crypto invoice is still pending, the card offers “Continue crypto checkout.”
Invoices and receipts
The invoice list in Settings merges two sources. Card invoices are read from Stripe — the most recent two dozen — each carrying an invoice number, a status, a currency, the total, the amount paid, a link to the hosted invoice page and a link to the PDF. Crypto invoices come from Athenum's own records and are listed with the processor's transaction reference as the identifier, the order number, the invoice state, the dollar total, and a description naming both the purpose — new subscription, renewal or plan change — and the plan. The two sets are merged and sorted newest first.
Two practical differences follow. A crypto invoice has no PDF: its link points back to the invoice page inside the app, which is also how an unpaid one is resumed. And an account with no Stripe customer record still gets its crypto invoices, because a missing Stripe customer is handled as an empty result rather than as an error. On a crypto invoice the amount paid is reported as the full total only once the invoice reaches the completed state, and as zero before that, so a partially observed transfer never appears as a settled payment in the list.
What happens to your data when your tier changes
A tier change is handled as an event, not as a silent field update. When the tier moves up or down, the current domain selection is expired and you go back through the domain picker, because both the quota and the set of domains you may pick have changed; a downgrade records that reason explicitly. Full-access is the exception — it re-selects every domain automatically instead of asking again. A cancellation expires the selection too. The cached onboarding decision is cleared on each of these transitions so the next request re-derives it from the current state.
Saved layouts are not deleted. The layout limit is checked when you save a new one — a create request above the limit is refused with an upgrade message — while the listing endpoint returns everything you have saved and hides nothing above the new ceiling. Plan changes are a card-only path: on a crypto membership the request is refused with a message telling you to start a new checkout after the current period ends. A plan change is also refused outright while a membership is already scheduled to end, so that schedule has to be reversed before the membership can be changed.
Terms
Contractual terms, including anything not described above, are set out in the Terms of Service and the Privacy Policy. For a question about a specific charge, contact support from inside the app.