Shop Projekt - Dokumentation

language

Der Kaufprozess – Initiierung des Peer-to-Peer-Handels

Dieses Dokument beschreibt den technischen Ablauf beim Absenden eines Kaufintents. Da kein zentraler Kaufvertrag auf der Plattform geschlossen wird, dient dieser Prozess der Transformation einer temporären Artikelauswahl in einen privaten Kommunikationskanal unter Beibehaltung voller relationaler Datenbank-Integrität für private Statistiken.

🗺️ Stufe 0 | 📚 Aktuell | 📟 2026 07 05 | 📍 Kaufprozess

Das Prinzip der Absichtserklärung & Relationale Datenhaltung

Um historische Transaktionen dauerhaft flexibel abrufbar, filterbar und für private Benutzerstatistiken durchsuchbar zu halten, werden abgeschlossene Käufe/Verkäufe nicht in Textdateien ausgelagert oder in separate Tabellen verschoben. Das System nutzt ein relationales 2-Zonen-Prinzip über die bestehenden Strukturen von tb_article und tb_art_manager.

1. Öffentlicher Raum (Isolation): Nach Transaktionsabschluss wird art_host_status auf Inaktiv ('I') oder Verkauft ('S') gesetzt. Die Galerie-View v_article_by_category filtert diese Zeilen sofort aus. Für die Öffentlichkeit und unbefugte Dritte ist der Artikel nicht mehr existent.
2. Privater Raum (Persistence): Die Verbindung zu Produktvarianten (var_ID) und Kategorien (cat_ID) bleibt intakt. Über die ACL-Abriegelung im PHP-Backend können ausschließlich die beiden beteiligten Partei-IDs (Käufer/Verkäufer) die Datensätze über den Fulfillment-Manager (tb_art_manager) für ihre private Historie aggregieren und durchsuchen.

Kryptografische Absicherung gegen administrative Zugriffe (Zero-Knowledge)

Um zu verhindern, dass Plattform-Administratoren oder unbefugte Exporteure (z.B. bei Datenbank-Hacks) Klartitellisten von Verkäufen einsehen können, gilt eine strikte Datentrennung:

• Indizierbare Strukturdaten (Klartext): Relationale Verknüpfungen wie var_ID, cat_ID und der ama_status verbleiben als anonyme Keys im Klartext in der DB. Dadurch sind globale anonyme Preisstatistiken und historische Produkt-Trends performant über SQL berechenbar.
• Personenbezogene Inhaltsdaten (Verschlüsselt): Sensible Transaktionsdaten (wie der finale art_price, die u_ID des Käufers/Verkäufers sowie Chat-Inhalte) werden mittels AES-256-GCM verschlüsselt gespeichert. Der dafür genutzte symmetrische Schlüssel wird zur Laufzeit beim Login aus dem User-Passwort abgeleitet und ausschließlich in der transienten $_SESSION vorgehalten. Ein Administrator sieht in der Datenbank ausschließlich unleserliche Chiffretexte ("Brabel"). Eine Entschlüsselung ist mathematisch nur möglich, wenn mindestens einer der beiden Transaktionspartner aktiv eingeloggt ist.

Schritt-für-Schritt-Ablauf im System

  • 1. Aggregation: Auslesen der Artikel aus dem Client-seitigen Session-Warenkorb.
  • 2. Daten-Payload: Erzeugung einer JSON-Struktur mit Artikel-IDs und Preisen als reiner Transport-Bote für das JavaScript-UI des Chats.
  • 3. Chat-Injektion: Automatisches Eröffnen des privaten Chat-Raums und Übermittlung der interaktiven Transaktionskarte.
  • 4. Relationale Reservierung: Umschreiben des Status in tb_art_manager.ama_status auf R (Reserviert) und Koppelung an die pur_ID.

Steuerung durch Peer-Schaltflächen (Transaction Flags)

Innerhalb des privaten Chats dient das UI als Steuerelement. Jede Aktion triggert im Hintergrund ein sicheres PHP/SQL-Update auf die relationalen Tabellen:

• Verkäufer: [Zahlungsinfo einblenden] ➔ Rendert gesicherte Textbausteine (IBAN) direkt im Client-Chat.
• Käufer: [Als bezahlt markieren] ➔ Aktualisiert den Status im Chat-Protokoll.
• Verkäufer: [Als versendet markieren] ➔ Setzt tb_article.art_host_status = 'I' (Vollständige Entfernung aus dem öffentlichen Marketplace) und schaltet tb_art_manager.ama_status = 'S' (Sold). Der Artikel ist nun exklusiv in den privaten Statistiken der beiden Kontrahenten über ihre Session-Schlüssel entschlüsselbar und indizierbar.