Abrechnung & Abonnements
Abo-Stufen, wie Upgrades verarbeitet werden und was am Ende einer Testphase passiert.
Tarife und Zugriffsstufen
Athenum verkauft vier Mitgliedschaftsstufen: Free, Lite, Pro und Pro+. Intern entsprechen sie vier Zugriffsstufen — preview, single_domain, multi_domain und full_access —, und die Stufe ist das, was das Produkt prüft, wenn es entscheidet, ob ein Feature freigeschaltet ist. Jede bezahlte Familie wird in zwei Abrechnungszeiträumen verkauft, monatlich und jährlich. Die Stufe legt konkrete Grenzen fest: die Zahl gespeicherter Layouts, Echtzeit- gegenüber verzögerten Daten, Alarme, Datenexport und wie weit Zeitreihenabfragen zurückreichen dürfen. Die aktuellen Preise stehen im Preisbereich statt hier wiederholt zu werden.
Was eine Stufe tatsächlich freischaltet
Der Zugriff ist kein einzelner Schalter. Der Tarifkatalog gibt jeder Stufe einen festen Satz benannter Fähigkeiten, und der Rest des Produkts liest diesen Satz statt des Tarifnamens. Die An/Aus-Fähigkeiten sind: API-Schlüssel anlegen, Echtzeitdaten nutzen, fortgeschrittene Indikatoren verwenden, whale-Alarme empfangen, Makro-Alarme empfangen, bevorzugter Support, Zugang zur kommerziellen API, Datenexport und Zugang zu den Pro-Signalfamilien der Prediction Markets. Daneben stehen abgestufte Grenzen: ein Kontingent gespeicherter Layouts, ein Kontingent an API-Schlüsseln, eine Obergrenze für Handelsplätze je Feature, eine Obergrenze dafür, wie weit eine Zeitreihenabfrage zurückreichen darf, eine Argus-Indikatorstufe, der Satz anfragbarer Chart-Zeitrahmen und der Satz anfragbarer Symbole.
preview, die Free-Stufe, hat jede An/Aus-Fähigkeit ausgeschaltet, ein gespeichertes Layout, keine API-Schlüssel, ein einziges Symbol und nur die Zeitrahmen 1h, 4h und 1d. single_domain (Lite) schaltet Echtzeitdaten, whale-Alarme und das Anlegen von API-Schlüsseln ein, öffnet alle Zeitrahmen und die vollständige Symbolliste und schaltet die erste Argus-Stufe frei. multi_domain (Pro) ergänzt fortgeschrittene Indikatoren, Makro-Alarme, die Pro-Signale der Prediction Markets, eine ungedeckelte Liste an Handelsplätzen und das lange lookback-Fenster. full_access (Pro+) ergänzt bevorzugten Support, die kommerzielle API, den Datenexport und die letzte Argus-Stufe. Jede bezahlte Familie wird monatlich und jährlich verkauft, und der Abrechnungszeitraum ändert Preis und Verlängerungsdatum, nie den Satz an Fähigkeiten.
Die abgestuften Grenzen greifen dort, wo Daten geholt werden, nicht nur in der Oberfläche. Eine lookback-Anfrage über der Zuteilung der Stufe wird auf diese Zuteilung gestutzt statt abgelehnt. Eine Liste von Handelsplätzen wird nach einer festen Rangfolge sortiert und auf die Obergrenze der Stufe gekürzt, eine niedrigere Stufe sieht also die höchstplatzierten Handelsplätze statt einer beliebigen Teilmenge. Eine Anfrage nach einem Zeitrahmen oder Symbol außerhalb der erlaubten Sätze der Stufe wird mit einer Antwort „Zahlung erforderlich“ abgelehnt. Domain-Wahlen tragen ein eigenes Kontingent: eine Domain bei Lite, drei bei Pro mit höchstens einer aus der fortgeschrittenen Gruppe und alle fünf bei Pro+, die automatisch ausgewählt werden.
Wo Tarifkatalog und Preistexte auseinandergehen
Zwei getrennte Listen beschreiben die Tarife. Die eine ist der Fähigkeitskatalog, den der Server durchsetzt; die andere ist die Featureliste auf der Preisseite. Keine wird aus der anderen erzeugt, und an mehreren Stellen widersprechen sie sich. Die Preisliste schreibt Lite zum Beispiel bevorzugten Support zu, im Fähigkeitskatalog ist bevorzugter Support für Lite aus und nur für Pro+ an. Die Preisliste schreibt Lite alle Börsen zu, während der Katalog Lite auf eine kleine Zahl an Handelsplätzen je Feature deckelt und die Grenze erst ab Pro aufhebt. Die Preisliste schreibt Lite die volle Historientiefe zu, während der Katalog Lite ein kurzes lookback-Fenster gibt und das lange für Pro und Pro+ reserviert.
Ein weiterer Punkt hat gar keine Entsprechung: Die Preisliste nennt Alarm-Kontingente je Stufe, der Fähigkeitskatalog bildet Alarme aber als zwei An/Aus-Fähigkeiten ab — whale-Alarme und Makro-Alarme — ohne jede Alarmzahl je Stufe im durchsetzenden Pfad. Wo die beiden Listen auseinandergehen, ist der Fähigkeitskatalog das, was das Produkt tatsächlich prüft. Ein Paar lässt sich außerdem leicht verwechseln, ohne widersprüchlich zu sein: API-Schlüssel für das eigene Konto anzulegen ist ab Lite möglich, während die kommerzielle programmatische API und Webhooks eine eigene Fähigkeit sind, die nur Pro+ trägt.
Zahlungsmethoden
Zwei Checkout-Schienen sind umgesetzt. Die Zahlung per Karte läuft über Stripe und führt auf die dort gehostete Checkout-Seite. Die Zahlung per Krypto läuft über Plisio und erzeugt eine gehostete Krypto-Rechnung; vor dem Start wird ein unterstützter Wert gewählt, aus Bitcoin, Ethereum, Solana, BNB Chain, Zcash, USDT auf Tron, USDT auf Solana und USDC auf Solana. Beide Schienen kaufen genau dieselbe Mitgliedschaft. Vor dem Checkout ist eine bestätigte Abrechnungs-E-Mail erforderlich, reine Wallet-Konten müssen also zuerst eine Adresse hinzufügen und bestätigen.
Wie ein Upgrade abläuft
Upgrades beginnen auf der Upgrade-Seite, wahlweise per Direktlink mit einem Tarif. Gewählt werden eine Tariffamilie und ein Abrechnungszeitraum, dann Karte oder Krypto. Die App erzeugt eine Checkout-Sitzung und leitet auf die gehostete Zahlungsseite des Anbieters weiter; die Rückkehr in die App erfolgt mit einem Abrechnungsstatus in der URL. Krypto-Checkouts landen auf einer eigenen Rechnungsseite mit Zieladresse, QR-Code, Betrag, ablaufendem Countdown und einem laufenden Bestätigungszähler — die Mitgliedschaft aktiviert sich automatisch, sobald sich Bestätigungen ansammeln. Besteht bereits ein aktives Abo, wird der Checkout abgelehnt, und der Kartenweg öffnet stattdessen das Stripe-Abrechnungsportal, wo sich der Tarif ändern lässt.
Innerhalb einer Krypto-Rechnung
Die Wahl von Krypto erzeugt eine Rechnung beim Zahlungsdienstleister und hält den Ablauf dann auf einer von Athenum gehosteten Seite, statt zur Seite des Dienstleisters zu führen. Die Rechnung wird mit einem Fenster von sechzig Minuten eröffnet, und die Seite zeigt einen Countdown auf diese Frist zusammen mit der Zieladresse, einem QR-Code, dem angebotenen Kryptobetrag, dem Dollargegenwert und einem Bestätigungszähler. Vor dem Erstellen muss ein unterstützter Wert gewählt werden; ohne ihn wird die Anfrage abgelehnt. Hat der Dienstleister nicht gemeldet, wie viele Bestätigungen er erwartet, zeigt der Zähler ersatzweise zwei an, statt nichts zu zeigen.
Die Seite fragt nicht von sich aus nach. Der Countdown läuft lokal, der Zahlungszustand aktualisiert sich aber nur beim Druck auf die Statusschaltfläche oder beim Neuladen der Seite; die Aktivierung selbst geschieht serverseitig, wenn der Dienstleister zurückruft. Der Statusendpunkt antwortet aus dem gespeicherten Datensatz, sobald die Rechnung einen Endzustand erreicht hat, und fragt sonst live beim Dienstleister nach. Ist der Dienstleister nicht erreichbar, liefert der Endpunkt eine Antwort „Dienst nicht verfügbar“, die den letzten bekannten snapshot dennoch mitträgt und um einen baldigen erneuten Versuch bittet, statt einen falschen Zustand zu melden.
Die Betragsprüfung geschieht beim Rückruf, nicht auf der Seite. Meldet ein abgeschlossener Rückruf einen Dollarbetrag, der vom in Rechnung gestellten abweicht, oder überhaupt keinen prüfbaren Dollarbetrag, wird er in eine fehlgeschlagene Zahlung mit dem Grund „Betragsabweichung“ übersetzt und die Mitgliedschaft nicht aktiviert. Der eigene Abweichungsstatus des Dienstleisters wird genauso behandelt. Eine abgelaufene Rechnung wird zu einer fehlgeschlagenen Zahlung mit Ablaufgrund, eine stornierte zu einer fehlgeschlagenen Zahlung mit Stornierungsgrund. Abgelaufene Rechnungen sind nicht erneut zahlbar; die Seite verweist auf einen neuen Checkout.
Die kostenlose Testphase
Eine Testphase dauert sieben Tage, lässt sich nur einmal pro Konto starten und gewährt für ihre Dauer die Stufe full_access. Sie ist kein Abo mit hinterlegter Karte: Sie verlängert sich nicht und es wird nichts abgebucht. Während sie läuft, zeigt die Mitgliedschaftskarte in den Settings die verbleibenden Tage, das Enddatum und eine Aktion „Zahlungsmethode hinzufügen“. Sind die sieben Tage vorbei, führt das Konto auf eine Abschlussseite, die den Umfang der Testphase zusammenfasst und zwei Wege anbietet — Pro+ über den Upgrade-Fluss fortsetzen oder auf der Free-Stufe über den Domain-Assistenten weitermachen. Konto, Layouts und Watchlists bleiben in beiden Fällen erhalten.
Wer für die Testphase in Frage kommt und was sie ausschließt
Die Testphase wird nicht auf der Preisseite gekauft. Sie wird beim Onboarding gewährt, und drei Bedingungen müssen alle erfüllt sein. Erstens muss die Identität eine sein, die das System als aufwendig zu erzeugen behandelt: eine Registrierung per E-Mail mit bestätigter Adresse oder ein Google-Konto mit bestätigter Adresse. Eine reine Wallet-Registrierung kommt ausdrücklich nicht in Frage. Zweitens muss ein betrieblicher kill switch für Test-Registrierungen ausgeschaltet sein; ist er an, läuft das Onboarding normal durch und gewährt schlicht keine Testphase. Drittens darf das Konto nie zuvor eine Testphase genutzt haben — eine Einmal-pro-Lebenszeit-Markierung wird in derselben Transaktion gesetzt, die das Test-Abo anlegt, zwei gleichzeitige Versuche können also nicht beide erfolgreich sein.
Für ihre sieben Tage projiziert die Testphase die Stufe full_access mit einer bewussten Ausnahme: API-Schlüssel lassen sich in einer Testphase nicht anlegen. Der Schlüsselendpunkt prüft sowohl die projizierte Stufe als auch den Tarifcode des Abos und beantwortet eine Testphase mit einer eigenen, darauf zugeschnittenen Meldung statt mit dem allgemeinen Upgrade-Hinweis. Zwei Erinnerungsmails werden gegen die Frist eingeplant, eine bei drei verbleibenden Tagen und eine bei einem verbleibenden Tag. Jede ist durch eine eigene Markierung geschützt, die vor dem Versand geschrieben wird — ein erneuter Versuch kann eine Erinnerung also verpassen, sie aber nie zweimal senden.
Die Zustände einer Zahlung und eines Abos
Jede Zahlung, die das System erfasst, trägt genau einen von fünf Zuständen: ausstehend, erfolgreich, fehlgeschlagen, erstattet oder teilweise erstattet. Zahlungen werden nach Anbieter plus der anbietereigenen Zahlungsreferenz gespeichert, und ein wiederholter Rückruf zur selben Referenz aktualisiert den bestehenden Datensatz, statt einen zweiten einzufügen — ein wiederholter Webhook kann eine Buchung in der Historie also nicht verdoppeln. Eine fehlgeschlagene Zahlung speichert zusätzlich einen Fehlercode und eine Meldung; auf der Krypto-Schiene sind das die oben beschriebenen Gründe Betragsabweichung, Ablauf, Stornierung und Verarbeitungsfehler.
Ein Abo hat einen größeren Satz an Zuständen: incomplete, incomplete_expired, trialing, active, past_due, canceled, unpaid, paused und expired. Nur drei davon gewähren Zugriff — active, trialing und past_due —, und die Übergänge zwischen ihnen sind durch eine ausdrückliche Übergangstabelle beschränkt, ein unzulässiger Sprung erzeugt also einen Fehler, statt den Datensatz still zu beschädigen. Über den Zugriff entscheidet nicht der Status allein. Ein Abo mit past_due gewährt keinen Zugriff mehr, sobald seine Kulanzfrist abgelaufen ist, und jedes Abo verliert den Zugriff, sobald sein Ablaufzeitstempel überschritten ist, ganz gleich, was der gespeicherte Status noch sagt.
Eine Krypto-Rechnung wird getrennt von beidem geführt, mit eigenen acht Zuständen: neu, ausstehend, bestätigend, abgeschlossen, abgelaufen, storniert, Abweichung und Fehler. Vier davon sind endgültig — abgeschlossen, abgelaufen, storniert und Fehler —, und sobald eine Rechnung einen davon erreicht, antwortet die App aus dem eigenen Datensatz, statt den Dienstleister erneut zu fragen. Die Abweichung ist bewusst nicht endgültig: Eine Rechnung in diesem Zustand kann weiter zu ausstehend, bestätigend, abgeschlossen oder storniert wandern, wenn der Dienstleister etwas Neues meldet.
Wenn eine Zahlung fehlschlägt
Ein Webhook über eine fehlgeschlagene Zahlung setzt das Abo auf past_due und stempelt eine Kulanzfrist sieben Tage nach dem Fehlschlag. Innerhalb dieses Fensters bleibt der Zugriff bestehen, weil past_due einer der drei zugriffsgewährenden Zustände ist und die Kulanzfrist, nicht der Status, den Zugriff beendet. Was der Kartendienstleister vor dem Eintreffen dieses Webhooks tut — wie oft er eine abgelehnte Buchung wiederholt und über welchen Zeitraum — ist beim Dienstleister konfiguriert und wird nicht von dieser Anwendung entschieden.
Krypto-Mitgliedschaften buchen nicht automatisch ab, die Verlängerung läuft daher als geplanter Job. Sieben Tage vor Periodenende sowie erneut bei drei Tagen und einem Tag erzeugt er eine offene Verlängerungsrechnung oder verwendet eine bestehende weiter und sendet sie per E-Mail; eine Rechnung, die noch in ihrem Fenster liegt oder bereits bestätigend ist, wird weiterverwendet statt ersetzt. Endet die Periode unbezahlt, wird das Abo mit einer Kulanzfrist sieben Tage nach Periodenende auf past_due gesetzt und ein Hinweis auf den Zahlungsrückstand verschickt. Verstreicht diese Frist ohne Zahlung, wird das Abo gekündigt und eine Ablaufmitteilung versendet. Eine Verlängerungsrechnung, die scheitert, während die Periode noch läuft, löst kein past_due aus.
Zwei Nebenwirkungen sind gut zu kennen. Ein übernommenes Sonderangebot gilt als verwirkt, sobald das Abo dieses Angebot verlässt, gekündigt wird oder abläuft, und ein späterer Checkout, der dasselbe Angebot verlangt, wird dann abgelehnt. Und immer wenn ein Abo in einen Zustand übergeht, der keinen Zugriff mehr gewährt, werden die zwischengespeicherten Sitzungsangaben dieses Kontos sofort geleert, statt von selbst ablaufen zu dürfen — die Änderung wirkt also bei der nächsten Anfrage und nicht erst nach einer Zwischenspeicherlaufzeit.
Eine bestehende Mitgliedschaft verwalten
Die Mitgliedschaftskarte in den Settings ist die Steuerfläche. Kartenkunden erhalten „Mitgliedschaft verwalten“, was das Stripe-Abrechnungsportal öffnet, dazu eine eigene Aktion für die gespeicherte Zahlungsmethode. Das Kündigen wird als „Zum Periodenende beenden“ angeboten: Das Abo wird zum Ende des laufenden Abrechnungszeitraums beendet statt sofort, und ein Abo, dessen Ende bereits geplant ist, zeigt stattdessen „Mitgliedschaft reaktivieren“. Tarifwechsel, die die Stufe senken oder von jährlich auf monatlich wechseln, werden auf das Periodenende gelegt statt sofort angewendet. Rechnungen werden mit Datum, Status, Betrag und einem Link zum Beleg gelistet, sobald der erste Abrechnungszyklus durchgelaufen ist. Ist eine Krypto-Rechnung noch offen, bietet die Karte „Krypto-Checkout fortsetzen“ an.
Rechnungen und Belege
Die Rechnungsliste in den Settings führt zwei Quellen zusammen. Kartenrechnungen werden aus Stripe gelesen — die letzten zwei Dutzend — und tragen jeweils eine Rechnungsnummer, einen Status, eine Währung, die Gesamtsumme, den gezahlten Betrag, einen Link zur gehosteten Rechnungsseite und einen Link zum PDF. Krypto-Rechnungen stammen aus den eigenen Aufzeichnungen von Athenum und werden mit der Transaktionsreferenz des Dienstleisters als Kennung, der Bestellnummer, dem Rechnungszustand, der Dollarsumme und einer Beschreibung gelistet, die sowohl den Zweck — neues Abo, Verlängerung oder Tarifwechsel — als auch den Tarif nennt. Beide Sätze werden zusammengeführt und mit den neuesten zuerst sortiert.
Daraus folgen zwei praktische Unterschiede. Eine Krypto-Rechnung hat kein PDF: Ihr Link führt zurück auf die Rechnungsseite in der App, worüber sich eine unbezahlte auch fortsetzen lässt. Und ein Konto ohne Stripe-Kundendatensatz bekommt seine Krypto-Rechnungen trotzdem, weil ein fehlender Stripe-Kunde als leeres Ergebnis behandelt wird und nicht als Fehler. Bei einer Krypto-Rechnung wird der gezahlte Betrag erst dann als volle Summe gemeldet, wenn die Rechnung den Zustand abgeschlossen erreicht, davor als null — eine erst teilweise beobachtete Überweisung erscheint in der Liste also nie als beglichene Zahlung.
Was bei einem Stufenwechsel mit den Daten passiert
Ein Stufenwechsel wird als Ereignis behandelt, nicht als stille Feldänderung. Bewegt sich die Stufe nach oben oder unten, verfällt die aktuelle Domain-Auswahl und es geht erneut durch die Domain-Auswahl, weil sich sowohl das Kontingent als auch der Satz wählbarer Domains geändert hat; eine Herabstufung hält diesen Grund ausdrücklich fest. full_access ist die Ausnahme — dort werden alle Domains automatisch neu gewählt, statt erneut zu fragen. Eine Kündigung lässt die Auswahl ebenfalls verfallen. Die zwischengespeicherte Onboarding-Entscheidung wird bei jedem dieser Übergänge geleert, damit die nächste Anfrage sie aus dem aktuellen Zustand neu ableitet.
Gespeicherte Layouts werden nicht gelöscht. Die Layout-Grenze wird beim Speichern eines neuen geprüft — eine Anlage über der Grenze wird mit einem Upgrade-Hinweis abgelehnt —, während der Auflistungsendpunkt alles Gespeicherte zurückgibt und nichts oberhalb der neuen Obergrenze verbirgt. Tarifwechsel sind ein reiner Kartenweg: Bei einer Krypto-Mitgliedschaft wird die Anfrage mit dem Hinweis abgelehnt, nach Ende der laufenden Periode einen neuen Checkout zu starten. Ein Tarifwechsel wird außerdem rundweg abgelehnt, solange das Ende einer Mitgliedschaft bereits geplant ist — dieser Plan muss also erst rückgängig gemacht werden, bevor sich die Mitgliedschaft ändern lässt.
Bedingungen
Die vertraglichen Bedingungen, einschließlich alles oben nicht Beschriebenen, stehen in den Nutzungsbedingungen und der Datenschutzerklärung. Bei einer Frage zu einer konkreten Buchung hilft der Support aus der App heraus weiter.