Packages, Entitlements & Add-ons: der Plan ist kein Aufkleber

Ein Package ist nicht bloß ein Label auf einer Organisation. Es entscheidet, welche Module verfügbar sind, welche Features aktiv sind, welche Quotas gelten und was passiert, wenn ein Tenant an ein Limit stößt. Läge diese Logik in verstreuten If-Abfragen, bräuchte jede Preisänderung eine kleine Zeremonie und ein Deploy.

Package-Motor

ReVend legt Pläne, Module, Features und Limits als Daten ab. Runtime-Helper lesen das aktive Package des Tenants und entscheiden, ob Routes, Aktionen und quotagebundene Mutationen erlaubt sind. Die öffentliche Preisseite liest aus demselben Katalog, sodass kommerzieller Text und App-Verhalten nicht heimlich von zwei verschiedenen Wettersystemen gepflegt werden.

Vier Stufen und eine Sandbox

Der Katalog liefert vier Planstufen: free für Bieter, die nur Auction nutzen, starter für den Core-Betrieb plus Auction-Browsen und -Bieten, professional mit zusätzlich Market, dem Escrow-Seller-Flow, API, Webhooks und Auction-Publishing, und enterprise mit erweiterten Auction-Controls und individuellen Konditionen. Ein separates Sandbox-Flag auf einer Organisation senkt das API-Rate-Limit, ohne die Stufe zu ändern, sodass sich eine Integration gegen echte Endpoints bauen lässt, ohne echtes Volumen. Stufen sind Zeilen, keine Code-Verzweigungen; eine fünfte wäre ein Insert.

Entitlements

Entitlements decken Modulzugang, Unterfeatures und numerische Limits wie User, Storage und API-Volumen ab. Storage etwa liegt bei 0 GB auf free, 5 GB auf starter, 25 GB auf professional und unbegrenzt auf enterprise, sofern kein Platform-Admin eine eigene Quota pro Tenant setzt. Downgrades löschen keine Tenantdaten; sie blockieren neue Aktionen über dem Limit und erklären, was sich geändert hat. Der Tenant sieht das alles auf /settings/billing: das Package, welche Module drin und draußen sind, die laufende Nutzung gegen die Limits und — wenn ein gegatetes Modul ihn über ?upgrade=... hierher geschickt hat — welches Modul oder Feature den Besuch ausgelöst hat. Erklärung, nicht Kasse.

Luft ohne Planwechsel

Zwischen „über dem Limit“ und „neuer Vertrag unterschrieben“ liegt meistens ein Gespräch, und für diese Lücke hat die Plattform zwei Werkzeuge. Eine Kulanzfrist hält einen Tenant arbeitsfähig, während eine Billing- oder Package-Diskussion läuft; ein temporärer Limit-Override hebt ein konkretes Limit bis zu einem gewählten Zeitpunkt an, mit einer Notiz, die sagt, warum. Beides wird im Organisationsdetail im Admin gesetzt, und beides ist so gemeint, dass der Support später nicht rätselt. „Temporärer Asset-Limit-Override während der Go-live-Importbereinigung, gültig bis zum Fünfzehnten, Package-Review terminiert“ ist eine gute Notiz. „Brauchen mehr“ nicht.

Steuerung im Admin

Platform Owner und Staff verwalten die Matrix unter /admin/platform/plans; Platform Viewer sehen sie read-only. Packages lassen sich anlegen, bearbeiten, duplizieren und archivieren, mit einem Public-Flag, das entscheidet, ob die Preisseite sie zeigt, und einem Featured-Flag für die Karte, die hervorgehoben wird. Die Modulmatrix schaltet Module pro Package; die Featurematrix schaltet editierbare Features, öffnet für Limit-Features einen Limit-Dialog (ein Wert oder unbegrenzt) und entscheidet, ob ein Feature auf der Preiskarte und im Vergleich erscheint. Standard-Features sind vor direktem Umschalten geschützt. Änderungen sind audit-relevant, weil ein einziger Schalter einen Tenant von „läuft normal“ nach „warum ist Market weg?“ befördern kann. Preisflexibilität nützt nur, wenn sie Spuren hinterlässt.