Mit WebBlocks Commerce verkaufen

Commerce ergänzt Ihr CMS um drei zusammenhängende Bereiche:

• Produkte: Titel, Beschreibungen, Preise, Währungen, Bestand und eine Produktsteuerklasse.
• Einen Einkaufsablauf für Besucher: einen nativen Commerce Buy Button, einen Warenkorb mit Mengensteuerung und ein separates Kassenformular für Kontakt- und Lieferangaben.
• Bestellungen und Zahlungen: gespeicherte Positionen, Kunden- und Lieferinformationen, Steuerbeträge und Zahlungsversuche. PayPal und SumUp wickeln Zahlungen auf ihren eigenen gehosteten Seiten ab; Besucher geben Kartendaten nicht in einen CMS-Inhaltsblock ein.

Für Produktgeschichten, Fotos, häufige Fragen und Navigation verwenden Sie weiterhin normale CMS-Seiten. Der Commerce-Block verbindet diese redaktionelle Seite mit einem tatsächlichen Produkt. Ein geänderter Absatz auf der Verkaufsseite ändert weder Preis noch Bestand; diese pflegen Sie unter Commerce → Products.

Das eignet sich als Einstieg für einen kleinen Katalog oder einzelne Produkte auf vorhandenen Seiten. Eine Versandkostenberechnung, Gutscheine, ein Lager- und Versandworkflow oder eine Erstattungsschaltfläche im Bestellbildschirm sind nicht enthalten. Eine erfasste Lieferadresse organisiert keinen Versand. Wiederkehrende Mitgliedschaften verwenden das separate Memberships-Plugin mit eigener Einrichtung; für die einmaligen Bestellungen dieser Anleitung benötigen Sie es nicht.

Für Endpunktnamen, Entwickleranbindung und den detaillierten Zahlungsablauf halten Sie die technische Commerce-Referenz bereit. Diese Anleitung beschreibt die Arbeit im Panel.

Verwenden Sie eine Testinstallation oder einen noch nicht für Kunden geöffneten Shop. Ein Wechsel des aktiven Gateways betrifft den Commerce-Checkout der gesamten Installation. Schalten Sie einen laufenden Shop daher nicht in den Testmodus, während Kunden einkaufen.

Sie benötigen:

• Eine funktionierende WebBlocks-CMS-Installation und ein Super admin-Konto für Installation und Zahlungseinstellungen.
• Eine zur ausgewählten Katalogversion passende CMS-Version. Commerce 0.16.0 verlangt CMS ^1.100.0; der Katalog nennt außerdem Laravel 13. Vergleichen Sie die Kompatibilität vor der Installation mit Ihrem System.
• Die PHP-Erweiterung intl sowohl für die Website als auch für die Kommandozeile. Bitten Sie Ihre Hosting-Administration um Aktivierung, falls Commerce eine Warnung zur Währungsformatierung anzeigt.
• Eine Website im CMS sowie die Berechtigung, dort eine Seite zu bearbeiten und als Vorschau zu öffnen.
• Später ein geeignetes PayPal- oder SumUp-Händlerkonto, passende Testzugangsdaten und eine öffentlich erreichbare HTTPS-Website für Anbieter-Callbacks.

Ein Site Admin kann Produkte verwalten und Bestellungen innerhalb zugewiesener Websites einsehen. Plugin-Installation, Commerce-Einstellungen und Zahlungszugangsdaten bleiben Aufgabe des Super admin. Fehlt ein Bildschirm, lassen Sie Rolle und Website-Zuweisung prüfen; ein zweites Konto gehört nicht zur Einrichtung.

Das Plugin wird im WebBlocks-Plugin-Katalog kostenlos angeboten. Das Konto beim Zahlungsanbieter ist ein separater Dienst; die Commerce-Installation erstellt oder verbindet kein solches Konto.

1. Melden Sie sich im CMS an und öffnen Sie System → Plugins.
2. Wählen Sie Browse Plugin Catalog und öffnen Sie WebBlocks Commerce.
3. Lesen Sie Kompatibilitätsergebnis und Versionshinweise. Wählen Sie Install from Catalog, wenn eine kompatible Version angeboten wird.
4. Kehren Sie zum Detailbildschirm des installierten Plugins zurück. Ein neues Paket beginnt im Zustand disabled, damit Sie es prüfen können.
5. Wählen Sie Enable Plugin. Bestätigen Sie die Aktivierung und prüfen Sie das Ergebnis der Zustandsprüfung.

Aktuelle CMS-Versionen wenden Datenbankänderungen von Plugins bei Installation, Aktualisierung und Aktivierung automatisch an. Migrations Up to Date bedeutet, dass keine manuelle Migration erforderlich ist. Schlägt die Datenbankvorbereitung fehl, beheben Sie zuerst die gemeldete Ursache; wiederholtes Aktivieren ersetzt keine fehlende Datenbankberechtigung.

Das Bild zeigt die abgeschlossene Installation. Stellt Ihre Administration stattdessen eine vertrauenswürdige Versions-ZIP bereit, verwenden Sie hier Plugin ZIP → Upload Plugin ZIP, prüfen das Paket und aktivieren es. Für beide Installationswege im Panel benötigen Shopbetreiber weder ein Plugin-Quellrepository noch einen Composer-Build-Befehl.

Nach der Aktivierung erscheint Commerce → Products, Orders, Settings in der Seitenleiste. Öffnen Sie Settings. Die Plugin-Zustandsprüfung bestätigt, dass das Paket ausgeführt werden kann; die Zahlungsbereitschaft wird separat in Commerce Settings geprüft.

1. Öffnen Sie Commerce → Settings → General.
2. Setzen Sie Gateway auf Test order (no payment).
3. Wählen Sie für dieses Beispiel EUR als Default Currency.
4. Lassen Sie PayPal Mode und SumUp Mode für spätere Tests auf Sandbox.
5. Wählen Sie Save Commerce Settings und kehren Sie zu Overview zurück.

Die Standardwährung ist der Ausgangswert für neue Produkte. Sie rechnet bestehende Produktpreise nicht um. Jedes Produkt behält seine eigene Währung; alle Positionen eines Warenkorbs müssen dieselbe Währung verwenden.

Für diese Übung sind Schema: Ready und Gateway: Ready entscheidend. PayPal und SumUp dürfen Needs config anzeigen, solange sie inaktiv sind. Für eine Testbestellung ohne Zahlung müssen Sie keine Anbieterzugangsdaten eingeben.

Die Übersicht kann das Testgateway als fake bezeichnen. Das ist der interne Name von Test order (no payment). Es erfasst eine unbezahlte Bestellung, reserviert Bestand und kontaktiert keinen Zahlungsanbieter. Es simuliert keine erfolgreiche Zahlung und setzt die Bestellung nicht auf Paid.

Öffnen Sie Commerce → Products → New Product. Tragen Sie die folgenden Werte ein und ersetzen Sie Northstar Studio durch Ihre eigene Website:

Price Amount verwendet ganze Untereinheiten statt eines dezimalen Verkaufspreises. Geben Sie für €18.00 den Wert 1800 ein, nicht 18 oder 18.00. Manche Währungen haben eine andere Anzahl von Untereinheiten; nicht jede verwendet Cent. Prüfen Sie den formatierten Preis nach dem Speichern.

Lassen Sie Inventory nur leer, wenn Sie bewusst keinen Bestand verfolgen möchten. Leer bedeutet unbegrenzte Verfügbarkeit, nicht ausverkauft. Wählen Sie für diese Anleitung eine konkrete Website. Install-wide ist ein separater Geltungsbereich für Super admin und entspricht nicht der Auswahl Ihrer aktuellen Website.

Wählen Sie Save Product und prüfen Sie im Detailbildschirm Active, €18.00, Inventory 24 und Product Available. Dort finden Sie auch eine Public Buy URL. Kopieren Sie für einen direkten Produktlink die URL Ihrer Installation, nicht die localhost-Adresse aus einem Bildschirmbild.

Sind weitere Sprachen auf der Website aktiviert, bietet das Produktformular übersetzte Titel und Beschreibungen an. Leere Übersetzungen fallen auf den Basisinhalt zurück. Die Übersetzung der CMS-Verkaufsseite und die des Commerce-Produkts sind getrennte Aufgaben; prüfen Sie beides bei einer neuen Shopsprache.

Erstellen Sie einen CMS-Seitenentwurf für das Notizbuch oder bereiten Sie eine gestaffelte Aktualisierung einer veröffentlichten Verkaufsseite vor. Wählen Sie dieselbe Website wie beim Produkt. Ergänzen Sie eine Überschrift, eine hilfreiche Beschreibung und gegebenenfalls ein Produktfoto über die normale Media Library und einen Image-Block.

Verbinden Sie die Seite anschließend mit Commerce:

1. Öffnen Sie den Slot Main und wählen Sie an der gewünschten Stelle Add Block.
2. Wählen Sie Commerce Buy Button.
3. Wählen Sie in Block Fields unter Product das Studio notebook.
4. Setzen Sie Button Label auf Add to Cart.
5. Wählen Sie die Ausrichtung Start und aktivieren Sie Show price beside the button.
6. Wählen Sie Save Block und öffnen Sie Preview für die gespeicherte Seite.

Der native Block fügt das ausgewählte Produkt dem Commerce-Warenkorb hinzu. Sie benötigen weder einen Trusted-HTML-Block noch ein eingefügtes Zahlungsformular oder Anbieterskript im Seiteninhalt.

Mit der Entwurfsvorschau testen Sie die Seite vor der Veröffentlichung. Der Vorschauhinweis macht Warenkorbaktionen nicht zu einem wirkungslosen Probelauf. Ein Klick verändert weiterhin den Warenkorb Ihrer Sitzung; ein abgeschlossener Checkout erstellt weiterhin eine Bestellung. Deshalb haben Sie zuerst das Gateway ohne Zahlung gewählt.

Für einen dauerhaften Warenkorblink im Website-Kopf fügen Sie einen Navigationseintrag mit Ziel /plugins/webblocks-commerce/cart, Beschriftung Cart und Symbol shopping-cart hinzu. Commerce kann die Warenkorbmenge an dieser Symbolaktion anzeigen. Die Anleitung für Navigationsmenüs erklärt das Hinzufügen und Sortieren.

Wählen Sie in der Seitenvorschau Add to Cart. Commerce öffnet den Warenkorb mit einem Notizbuch. Betätigen Sie einmal +, um die Menge auf zwei zu erhöhen.

Prüfen Sie Produktname, Menge und formatierten Preis. Mit den EUR-Preisen und steuerinklusiven Beispieldaten dieser Anleitung ergeben zwei Notizbücher zu €18.00 insgesamt €36.00. Sie können Mengen auch verringern oder eine Position entfernen. Erneutes Hinzufügen desselben Produkts addiert die Mengen; Produkte mit anderer Währung werden abgewiesen.

Wählen Sie Go to checkout. Kontakt- und Lieferdaten stehen auf diesem separaten Bildschirm. Geben Sie eigene Testdaten ein, etwa Example customer und customer@example.test, statt echter Kundeninformationen.

Erforderlich sind vollständiger Name, E-Mail, Straße und Hausnummer, Postleitzahl, Ort und ein zweistelliger Ländercode wie DE. Telefon und zweite Adresszeile sind optional. Prüfen Sie den Gesamtbetrag und wählen Sie Place test order.

Das Formular erfasst derzeit auch Lieferdaten für einen Workshop-Pass oder andere nicht versendete Artikel. Das ist kein Versanddienst: Commerce berechnet in dieser Version keinen Liefertarif und bucht keinen Transport. Der Versandtext in der Zusammenfassung belegt weder eine eingerichtete Gebühr noch einen Versandworkflow.

Bei Erfolg erscheint Test Order Received mit dem Hinweis, dass keine Zahlung eingezogen wurde. Pending ist der erwartete Status. Bewahren Sie die Bestellnummer für den nächsten Schritt auf; den privaten Bestellstatuslink müssen Sie nicht teilen.

Öffnen Sie Commerce → Orders, suchen Sie die Bestellnummer aus dem Ergebnisbildschirm und öffnen Sie sie. Prüfen Sie:

• Status: Pending, da es sich um eine unbezahlte Testbestellung handelt.
• Items: Studio notebook, Menge 2, je €18.00, insgesamt €36.00.
• Customer und Delivery: die eingegebenen fiktiven Angaben.
• Gateway: fake, der Modus ohne Zahlung.
• Payment Attempts: den gespeicherten Versuch und seinen Zustand.
• Steueraufschlüsselung: Nettosumme, Mehrwertsteuer und Bruttosumme des Checkouts.

Öffnen Sie das Notizbuchprodukt erneut. Inventory sollte jetzt 22 betragen: Zu Beginn des Checkouts wurden zwei Einheiten reserviert. Allein das Hinzufügen zum Warenkorb reserviert nichts. Sowohl offene Bestellungen echter Anbieter als auch Testbestellungen ohne Zahlung können Bestand reservieren.

Der Bestellbildschirm ist schreibgeschützt. Sie können eine Testbestellung dort nicht durch eine Statusänderung in eine bezahlte Bestellung verwandeln. Auch eine erfolgreiche Browserrückkehr von PayPal oder SumUp ist kein Zahlungsnachweis. Bei echten Anbietern ändert sich der Zahlungsstatus erst, nachdem Commerce Callback und Zahlungsdetails überprüft hat.

Preise und Steuerbeträge werden beim Checkout in der Bestellung gespeichert. Spätere Produktpreisänderungen gelten für künftige Checkouts und überschreiben keine bestehenden Bestellbeträge.

Währung: Der Anbieter muss sowohl die Standardwährung als auch die Währungen vorhandener, nicht archivierter Produkte unterstützen. Ein Gatewaywechsel kann wegen einer nicht unterstützten Produktwährung abgelehnt werden. Korrigieren Sie die Produktwährung oder archivieren Sie das Produkt bewusst; ein geänderter Standard ist keine Währungsumrechnung.

Steuer: Die Produktsteuerklasse wird mit serverseitig konfigurierten Sätzen für das Steuerland des Shops kombiniert. Das Plugin bestimmt nicht für jede Lieferadresse automatisch eine neue Steuerzuständigkeit. Lassen Sie die Steuerkonfiguration vor der Bestellannahme durch Ihre Hosting-Administration bestätigen.

Die relevanten Servereinstellungen heißen WEBBLOCKS_COMMERCE_TAX_ENABLED, WEBBLOCKS_COMMERCE_PRICES_INCLUDE_TAX und WEBBLOCKS_COMMERCE_TAX_COUNTRY. Bei Preisen inklusive Steuer wird die Mehrwertsteuer aus dem Produktpreis herausgerechnet, bei Preisen ohne Steuer hinzugerechnet. Der Test verwendet einen konfigurierten Standardsatz von 19% und EUR-Preise inklusive Steuer: €36.00 enthalten €5.75 Mehrwertsteuer und €30.25 netto. Das illustriert diese Beispieldaten und ist kein Steuersatz für jeden Shop.

Bestand: Verfolgte Einheiten werden beim Checkout reserviert und bei Fehlschlag, Stornierung, Ablauf oder Erstattung im unterstützten Bestelllebenszyklus freigegeben. Unverfolgte Produkte werden nicht heruntergezählt. Vor einer Bestellung prüft der Warenkorb Preis und Verfügbarkeit erneut; ein gespeicherter Warenkorb garantiert keinen festen Preis und keinen reservierten Bestand.

Bitten Sie die Hosting-Administration, die Bereinigung abgebrochener Bestellungen zu planen. Das Plugin bietet:

Beispielsweise kann der Befehl alle fünfzehn Minuten über den Laravel-Scheduler der Hostanwendung laufen. Wählen Sie eine zum Shop und Zahlungsablauf passende Frist. Der Befehl lässt alle offenen Bestellungen jenseits dieser Frist ablaufen, nicht nur Testbestellungen. Das gibt Bestand aus abgebrochenen Checkouts frei. Längeres Warten macht Testbestellungen nicht bezahlt.

Verwenden Sie hierfür eine öffentlich erreichbare HTTPS-Testwebsite. Ein Anbieter kann seinen Server-Callback nicht an die lokale Bildschirmadresse 127.0.0.1 senden.

1. Öffnen Sie im PayPal Developer Dashboard Apps & Credentials und holen Sie die sandbox-Client-ID und das Client-Secret Ihrer App. Verwenden Sie die für diesen Shop vorgesehenen App- und Händlerkonten.
2. Wählen Sie unter Commerce → Settings → General PayPal, setzen Sie PayPal Mode auf Sandbox, wählen Sie eine unterstützte Standardwährung und speichern Sie.
3. Öffnen Sie den Reiter PayPal und geben Sie Client ID sowie Client Secret ein.
4. Kopieren Sie die von Ihrer Installation erzeugte Webhook URL. Registrieren Sie diesen HTTPS-Endpunkt bei PayPal für dieselbe App und denselben Modus, einschließlich des hier verwendeten Ereignisses CHECKOUT.ORDER.APPROVED. Übertragen Sie die resultierende Webhook ID zurück nach Commerce.
5. Speichern Sie und prüfen Sie in Overview und im PayPal-Reiter die Checkout- und Webhook-Bereitschaft.
6. Beginnen Sie eine neue Bestellung und genehmigen Sie sie mit einem passenden Sandbox-Käuferkonto. Prüfen Sie, dass die Bestellung nach dem verifizierten Callback Paid wird; verlassen Sie sich nicht allein auf die Browserrückkehr.

Der öffentliche Endpunkt hat den Pfad /plugins/webblocks-commerce/webhooks/paypal. Kopieren Sie ihn aus dem Panel, damit Hostname und Protokoll zur tatsächlichen Installation passen. Client-ID, Secret und Webhook-ID müssen aus derselben PayPal-App und Umgebung stammen.

PayPals REST-Einrichtung erklärt App-Zugangsdaten und Sandbox-Konten; die Webhooks-Referenz beschreibt Abonnements. Für den Panel-Ablauf müssen Sie diese APIs nicht selbst implementieren.

In General wählen Sie ein aktives Bestellgateway. Zugangsdaten für beide Anbieter erzeugen im Checkout keine Anbieterauswahl für Besucher.

1. Bereiten Sie ein SumUp-Testhändlerkonto mit passendem API-Schlüssel und Händlercode vor. Bei Unklarheiten hilft die SumUp-Verbindungsanleitung.
2. Wählen Sie unter Commerce → Settings → General SumUp, setzen Sie SumUp Mode auf Sandbox, wählen Sie eine kompatible Standardwährung und speichern Sie.
3. Öffnen Sie den Reiter SumUp, geben Sie API Key und Merchant Code ein und speichern Sie.
4. Prüfen Sie Bereitschaft und erzeugte Webhook-URL. Der öffentliche HTTPS-Pfad /plugins/webblocks-commerce/webhooks/sumup muss erreichbar sein.
5. Starten Sie einen neuen Checkout aus dem Warenkorb. Commerce erstellt den gehosteten Checkout und leitet den Kunden zur SumUp-Zahlungsseite. Schließen Sie dort den Test ab, kehren Sie zur Website zurück und prüfen Sie die gespeicherte Bestellung.
6. Bestätigen Sie, dass die Bestellung erst Paid wird, nachdem Commerce das Zahlungsergebnis beim Anbieter abgerufen und geprüft hat.

Commerce liefert die SumUp-Callback-URL beim Erstellen jedes Checkouts mit. Eine separate SumUp Webhook ID wird nicht verlangt. Sandbox als Modus verwandelt keinen Live-Händlerschlüssel in einen Testschlüssel: Konto, Händlercode und Schlüssel müssen zur vorgesehenen Umgebung gehören.

SumUps Überblick über Onlinezahlungen erläutert gehostete Zahlungen, die Checkouts-API-Referenz den Checkout und Backend-Callback. Das CMS nutzt diesen Ablauf für Sie; Kartendaten bleiben auf der gehosteten SumUp-Oberfläche.

Zugangsdatenfelder sind nur beschreibbar. Nach dem Speichern ist das Formular wieder leer und zeigt an, ob ein Wert konfiguriert ist. Ein leeres Feld bedeutet daher nicht unbedingt, dass Zugangsdaten verloren gingen. Leer lassen behält den gespeicherten Wert; verwenden Sie Clear saved value nur zum bewussten Entfernen.

In Commerce Settings gespeicherte Werte werden verschlüsselt abgelegt. Alternativ kann die Administration die entsprechenden Server-Umgebungswerte verwalten. Diese haben Vorrang und erscheinen als Managed by environment; das überschriebene Feld ist im Panel schreibgeschützt. Der Reiter System nennt unterstützte Umgebungsvariablen, ohne ihre Werte offenzulegen.

Scheint ein gespeicherter Ersatz wirkungslos, prüfen Sie vor erneuter Eingabe das Herkunftslabel des Feldes. Stimmen Sie Umgebungsänderungen mit der Hosting-Administration ab. Schreiben Sie Schlüssel oder Geheimnisse niemals in Seiten, HTML-Blöcke, Bildschirmbilder oder Supportnachrichten.

Zahlungseinstellungen gelten installationsweit. Websitebezogene Produkte und Site-Admin-Rechte erzeugen keine eigene Händlerkonfiguration pro Website.

Schließen Sie zuerst die Übung ohne Zahlung ab und führen Sie danach einen separaten vollständigen Test mit dem Sandbox-Ablauf des gewählten Anbieters durch. Die Bilder dieser Anleitung zeigen nur die Übung ohne Zahlung; sie belegen weder Ihr Händlerkonto noch funktionierende öffentliche Callbacks.

Bestätigen Sie vor Öffnung der Verkaufsseite:

• Anbieter, Modus, Händlerzugangsdaten und Webhook-Einrichtung passen zusammen.
• Website und Callback-URLs verwenden den richtigen öffentlichen HTTPS-Hostnamen und bleiben erreichbar.
• Jedes zu verkaufende Produkt ist Active, der richtigen Website zugewiesen, korrekt bepreist und in einer unterstützten Währung.
• Steuerkonfiguration und tatsächlicher Liefer- und Versandprozess entsprechen den Versprechen der Seite.
• Eine Sandbox-Zahlung wird nach Anbieterprüfung unter Commerce → Orders zu Paid. Testen Sie auch Abbruch und relevante Fehlerfälle.
• Die Bereinigung offener Bestellungen ist geplant und ihre Ablauffrist geprüft.
• Seite, Navigation, Kontaktangaben und aktivierte Sprachversionen wurden als Vorschau geprüft.

Beim bewussten Wechsel zu echten Zahlungen verwenden Sie die live-Zugangsdaten des echten Händlers, den passenden Live-Modus und die korrekte Live-Webhook-Konfiguration. Sandbox- und Live-Daten oder Webhook-IDs sind nicht austauschbar. Prüfen Sie Gateway und Bereitschaft erneut und folgen Sie Ihrem normalen Prüf- und Veröffentlichungsablauf.

Eine Seitenveröffentlichung richtet kein Händlerkonto ein. Auch der Gatewaywechsel ist von der Veröffentlichung getrennt und wirkt sofort auf den Checkout.

Verwenden Sie Draft während der Produktvorbereitung und Active, sobald es gekauft werden kann. Archivieren Sie Produkte, wenn neue Käufe enden sollen, und prüfen Sie weiterhin darauf verweisende Verkaufsseiten und Links. Historische Bestellpositionen behalten gespeicherte Namen und Beträge.

Lesen Sie vor Plugin-Updates Versionshinweise und Kompatibilitätsangaben, sichern Sie die Installation nach Ihrem normalen Verfahren und wiederholen Sie danach einen Warenkorb-/Checkout-Test. Aktuelle CMS-Versionen wenden Plugin-Datenbankänderungen bei Updates und Aktivierung an.

Eine Deaktivierung von Commerce setzt dessen Routen, Menüs, Einstellungen und Beiträge außer Kraft. Berücksichtigen Sie in einem laufenden Shop vorher Besucher, vorhandene Commerce-Blöcke und Anbieter-Callbacks. Die Deinstallation eines deaktivierten hochgeladenen Pakets behält die Plugin-Datenbanktabellen; sie bereinigt keine Bestelldaten.

Der Hauptablauf steht nun: Produkt → CMS-Seite → Warenkorb → Checkout → Bestellprüfung. Für Automatisierung und erweiterte Diagnose nutzen Sie die Commerce-Referenz, für alltägliche Seiten-, Medien- und Teamabläufe alle Anleitungen.