Wer Lizenzschlüssel, Gutscheincodes oder Zugangscodes verkauft, braucht eine Antwort auf eine einfache Frage: Welcher Code geht an welche Bestellung – und zwar genau einmal? Ein Code Pool ist das Datenmodell, das diese Frage zuverlässig beantwortet. Dieser Artikel erklärt, wie ein Code Pool aufgebaut ist, welche Zustände ein Code durchläuft und warum die Details entscheidend sind.
Wie bei allen Themen rund um digitale Produkte gilt: Gemeint sind ausschließlich Codes, die du rechtmäßig verkaufen darfst und die mit den Richtlinien des jeweiligen Marktplatzes vereinbar sind.
Was ein Code Pool ist
Ein Code Pool ist eine Sammlung einzelner Codes, die zu einem Produkt (einer SKU) gehören. Anders als ein Bestandszähler kennt der Pool jeden Code einzeln. Jeder Eintrag enthält mindestens:
- den Code selbst (verschlüsselt gespeichert)
- die zugehörige SKU oder Produkt-ID
- den aktuellen Status
- die Order ID, sobald der Code einer Bestellung zugeordnet ist
- Zeitstempel für jede Statusänderung
- optional: Chargen-ID, Lieferant, Ablaufdatum
Der Bestand, den eBay anzeigt, ist die Anzahl der Codes im Status „available“ – abzüglich eines eventuellen Puffers.
Das Statusmodell
Ein Code durchläuft im Normalfall drei Zustände, mit einem vierten für Ausnahmen.
| Status | Bedeutung | Wer setzt ihn |
|---|---|---|
available |
Code liegt im Pool, unbenutzt, verkaufbar | Upload / Import |
reserved |
Code ist einer Bestellung zugeordnet, aber noch nicht zugestellt | Workflow bei bezahlter Bestellung |
sold |
Code wurde zugestellt, Bestellung erfüllt | Workflow nach erfolgreicher Zustellung |
blocked |
Code darf nicht verkauft werden (defekt, zurückgerufen, Duplikat, Verdacht) | Manuell oder Regel |
Warum „reserved“ nötig ist
Man könnte meinen, zwei Zustände reichen: verfügbar und verkauft. Der Zwischenschritt „reserved“ löst aber ein reales Problem. Zwischen der Auswahl eines Codes und der bestätigten Zustellung liegen mehrere Schritte, die fehlschlagen können: Die Nachricht an den Käufer wird nicht gesendet, die API antwortet nicht, der Workflow bricht ab. Ohne Reservierung wäre unklar, ob der Code nun verbraucht ist oder nicht.
Mit Reservierung ist der Zustand eindeutig: Der Code gehört zu dieser Order ID, ist aber noch nicht bestätigt zugestellt. Läuft die Zustellung durch, wird er „sold“. Schlägt sie endgültig fehl, kann der Code – nach Prüfung – wieder auf „available“ gesetzt oder auf „blocked“ genommen werden.
Wann „blocked“ sinnvoll ist
Der Status „blocked“ nimmt Codes aus dem Verkauf, ohne sie zu löschen. Typische Gründe:
- Der Lieferant meldet eine Charge als ungültig
- Ein Käufer reklamiert, dass der Code nicht funktioniert – bis zur Klärung bleibt er gesperrt
- Beim Import wurde ein Duplikat erkannt
- Eine Risikoregel hat die Bestellung storniert, der Code soll aber nicht sofort wieder verkauft werden
Ein gelöschter Code ist unsichtbar. Ein gesperrter Code bleibt nachvollziehbar.
Duplikate verhindern
Die zwei häufigsten Fehler bei digitalen Produkten sind: derselbe Code zweimal verkauft, oder derselbe Code zweimal importiert. Beides verhindert ein Code Pool auf Datenbankebene.
- Beim Import: Der Code (oder sein Hash) ist ein eindeutiger Schlüssel. Ein zweiter Import desselben Codes wird abgelehnt und protokolliert.
- Bei der Auswahl: Die Reservierung erfolgt als atomare Operation. Zwei gleichzeitige Bestellungen können nicht denselben Code erhalten, weil die Datenbank nur einen der beiden Zugriffe durchlässt.
- Pro Bestellung: Die Order ID ist ebenfalls eindeutig verknüpft. Wird dieselbe Bestellung zweimal verarbeitet (etwa durch eine doppelte Notification), findet der Workflow den bereits reservierten Code und liefert keinen zweiten aus.
Ein Google Sheet kann diese Zusicherungen nicht leisten. Für kleine Volumen mag ein Sheet als Eingabe funktionieren, der Pool selbst gehört in eine Datenbank.
Das Audit Log
Jede Statusänderung wird protokolliert: welcher Code, von welchem Status in welchen, wann, durch welchen Workflow oder welche Person, mit welcher Order ID. Das Audit Log beantwortet später Fragen wie:
- Welcher Code ging an Bestellung 12-34567-89012?
- Wurde ein bestimmter Code jemals ausgeliefert, und wann?
- Wie viele Codes einer Charge wurden gesperrt?
- Wer hat einen Code manuell freigegeben?
Bei Reklamationen oder Rückfragen des Marktplatzes ist das Log der einzige Nachweis. Es sollte unveränderlich sein – Einträge werden ergänzt, nie überschrieben.
Nachschub und Schwellwerte
Ein Pool leert sich. Ein Workflow sollte deshalb:
- bei Unterschreiten eines Schwellwerts (z. B. 5 verfügbare Codes) eine Benachrichtigung senden
- bei 0 verfügbaren Codes den eBay-Bestand auf 0 setzen oder das Angebot pausieren
- neue Codes per CSV, Sheet oder API entgegennehmen und vor dem Import auf Format und Duplikate prüfen
Grenzen
Ein Code Pool verwaltet Codes, er bewertet sie nicht. Ob ein Code gültig ist, ob der Lieferant seriös ist, ob der Weiterverkauf lizenzrechtlich erlaubt ist – das prüft kein Datenmodell. HandelPilot betreibt Code Pools mit diesem Statusmodell als Teil des Digital-Goods-Pakets, die Verantwortung für das Sortiment bleibt beim Händler.
Fazit
Ein Code Pool ist ein einfaches Modell mit vier Zuständen, dessen Wert in den Details liegt: Reservierung vor Zustellung, Sperrung statt Löschung, Duplikatschutz auf Datenbankebene und ein lückenloses Log. Wer digitale Produkte über Marktplätze verkauft, kommt an diesem Modell kaum vorbei. Ob sich der Aufbau bei deinem Volumen lohnt, kannst du mit dem Einsparpotenzial berechnen.