Shop Project - Documentation
The Checkout Process – Initiating Peer-to-Peer Trading
This document describes the technical workflow when submitting a purchase intent. Since no central sales contract is concluded on the platform, this process serves to transform a temporary selection of articles into a private communication channel while maintaining full relational database integrity for private statistics.
The Principle of Intent & Relational Data Persistence
To keep historical transactions permanently flexible, filterable, and searchable for private user statistics, completed purchases/sales are not offloaded to text files or moved to separate tables. The system utilizes a relational 2-zone principle using the existing structures of tb_article and tb_art_manager.
1. Public Space (Isolation): Upon transaction completion, art_host_status is set to Inactive ('I') or Sold('S'). The gallery view v_article_by_category filters these rows immediately. For the public and unauthorized third parties, the article ceases to exist.
2. Private Space (Persistence): The connection to product variants (var_ID) and categories (cat_ID) remains intact. Through ACL blocking in the PHP backend, only the two participating party IDs (buyer/seller) can aggregate and search the records via the fulfillment manager (tb_art_manager) for their private history.
Cryptographic Protection Against Administrative Access (Zero-Knowledge)
To prevent platform administrators or unauthorized exporters (e.g., during database hacks) from viewing cleartext lists of sales, strict data separation applies:
• Indexable Structural Data (Plaintext): Relational links like var_ID, cat_ID, and ama_status remain as anonymous keys in plaintext within the DB. This allows high-performance calculation of global anonymous price statistics and historical product trends via SQL.
• Personal Content Data (Encrypted): Sensitive transaction details (such as the final art_price, the u_ID of the buyer/seller, and chat content) are stored encrypted using AES-256-GCM. The symmetric key used for this is derived at runtime during login from the user's password and is kept exclusively in the transient $_SESSION. An administrator sees only unreadable ciphertext ("brabel") in the database. Decryption is mathematically possible only when at least one of the two transaction partners is actively logged in.
Step-by-Step Workflow in the System
- 1. Aggregation: Reading items from the client-side session shopping cart.
- 2. Data Payload: Generation of a JSON structure containing article IDs and prices as a pure transport messenger for the chat JavaScript UI.
- 3. Chat Injection: Automatically opening the private chat room and transmitting the interactive transaction card.
- 4. Relational Reservation: Toggling the status in
tb_art_manager.ama_statusto R (Reserved) and coupling it to thepur_ID.
Control via Peer Buttons (Transaction Flags)
Within the private chat, the UI serves as a control element. Each action triggers a secure PHP/SQL update on the relational tables in the background:
• Seller: [Show Payment Info] ➔ Renders secured text modules (IBAN) directly within the client chat.
• Buyer: [Mark as Paid] ➔ Updates the status in the chat protocol.
• Seller: [Mark as Shipped] ➔ Sets tb_article.art_host_status = 'I' (Complete removal from public marketplace) and toggles tb_art_manager.ama_status = 'S' (Sold). The article is now exclusively decryptable and indexable within the private statistics of both counterparties via their session keys.