WooCommerce Entwickler in Mannheim

WooCommerce-Entwicklung für Händler in Mannheim, von der Quadratestadt über den Industriehafen bis ins Umland der Metropolregion Rhein-Neckar. Wir bauen und reparieren Online-Shops, die deutsche Zahlungs- und Versandgewohnheiten ernst nehmen und Woo-Updates überstehen, statt bei jedem Release zu brechen.

#WooCommerce-Entwicklung in Mannheim

Mannheim ist als einzige deutsche Großstadt nicht in Stadtteile mit Straßennamen, sondern in ein Schachbrett aus Quadraten gegliedert. Diese Logik passt zu der Rolle, die die Stadt heute spielt: ein Mischverband aus großen Industriestandorten und einer engmaschigen Mittelstandslandschaft. Roche Diagnostics betreibt hier den Deutschland-Hauptsitz, Daimler Truck Holding hat seinen Konzernsitz nach der Abspaltung 2021 nach Mannheim verlegt, Bilfinger SE steuert seine Industriedienstleistungen von hier aus, und John Deere baut in der Stadt Traktoren. Direkt im Industriehafen Mannheim, der zusammen mit Ludwigshafen den zweitgrößten Binnenhafen Europas bildet, sitzt ein dichtes Geflecht aus Logistik-, Chemie- und Zuliefererbetrieben. Wenige Kilometer weiter über die BASF in Ludwigshafen und SAP in Walldorf entsteht der wirtschaftliche Schwerpunkt der gesamten Metropolregion Rhein-Neckar.

Diese Mischung prägt, welche Online-Shops in Mannheim gebaut werden: technisch anspruchsvolle B2B-Kataloge für Industriezulieferer, D2C-Shops aus Manufakturen und Markenfamilien, kombinierte Online- und Filialgeschäfte aus der Innenstadt rund um die Planken sowie die wachsende Zahl von Ausgründungen rund um die Universität Mannheim, deren Wirtschafts- und Sozialwissenschaften international zu den am höchsten gerankten in Kontinentaleuropa zählen. Für all diese Händler gilt dasselbe: Der Shop muss in den deutschen Markt passen. Käufer in Baden-Württemberg erwarten Kauf auf Rechnung, PayPal und SEPA-Lastschrift, ein rechtssicheres Impressum, eine korrekte Widerrufsbelehrung und einen Checkout, der die DSGVO nicht erst im Cookie-Banner ernst nimmt, sondern in der Architektur.

#Was wir für Mannheimer Shops bauen

• Checkout-Flows, die die deutsche Bezahlrealität abbilden: Kauf auf Rechnung als Standarderwartung, PayPal und PayPal Pay Later, Klarna, SEPA-Lastschrift, giropay und Kartenzahlung über Stripe oder Mollie, jeweils mit sauberer 3DS- und PSD2-Logik
• Versandkonfiguration für die typischen deutschen Carrier: DHL, DPD und Hermes, mit Zonen, Gewichts- und Sperrgutregeln, Packstation-Adressen, Großempfänger-Codes für die Industriebezieher im Hafen und Echtzeit-Sendungsverfolgung
• Anbindung an Warenwirtschaft und Buchhaltung im Mittelstand: DATEV-konforme Rechnungsexporte, Schnittstellen zu JTL-Wawi, plentymarkets, Xentral oder Afterbuy und Produktdaten-Sync aus ERP-Systemen mit Konfliktlösung und Bestandsabgleich
• B2B-Funktionen für Industrie- und Maschinenbauzulieferer rund um den Mannheimer Hafen: kundenspezifische Netto-Preise und Staffelpreise, Mindestbestellmengen, Angebotsanfrage-Workflows, Freigabeprozesse, Multi-Warehouse-Bestand und getrennte Geschäftskundenportale
• Abo- und Mitgliedschaftslogik mit wiederkehrender Abrechnung, vorbereitet auf die ab 20. November 2026 greifende EU-Verbraucherkreditrichtlinie, die das 200-Euro-Limit für Buy-Now-Pay-Later beendet und für jede Ratenzahlung eine Bonitätsprüfung verlangt
• Mehrsprachige und mehrwährungsfähige Shops, wenn Mannheimer Hersteller in den DACH-Raum, nach Frankreich oder weiter nach Osteuropa exportieren, mit WPML, lokalisiertem Checkout und korrekter OSS-Steuerzuordnung

#Der Markt in Mannheim, und was er für den Shop bedeutet

Wer in Mannheim einen Online-Shop betreibt, hat selten ein reines Werbeproblem. Häufiger ist es ein Vertrauens- und Konformitätsproblem. Deutsche Käufer brechen ab, wenn der Bezahlteil unvollständig wirkt: kein Kauf auf Rechnung, kein sichtbares Trusted-Shops- oder eKomi-Siegel, eine Widerrufsbelehrung, die im Footer versteckt ist. PayPal hat in Deutschland eine sehr hohe Nutzung, und der Rechnungskauf bleibt eine der meistgenutzten Bezahlarten überhaupt. Ein Shop, der beide Wege nicht sauber anbietet, verliert Umsatz, bevor das Marketing überhaupt greift. Dazu kommt mit Klarna und giropay eine Käuferschicht, die direkte Bankzahlungen aus dem Online-Banking erwartet, gerade bei höheren Warenkörben.

Bei B2B-Händlern aus dem Industriehafen-Umfeld sieht das Bild anders aus. Hier zählt nicht der hübsche Warenkorb, sondern dass der Shop Netto-Preise, projektbezogene Freigaben, Großempfänger-Adressen und die Anbindung an die interne Warenwirtschaft korrekt abbildet. Ein Einkäufer bei einem Maschinenbauzulieferer will eine Bestellung auslösen, die ohne manuelle Nacharbeit in DATEV läuft und in der Lagerverwaltung auf dem richtigen Standort verbucht wird, auch wenn die Ware aus einem Außenlager am Rhein versendet wird. Diese beiden Welten, schneller D2C-Checkout und integrationsschwerer B2B-Prozess, brauchen unterschiedliche technische Entscheidungen, auch wenn beide auf WooCommerce laufen.

Ein dritter Punkt ist die Kongress- und Veranstaltungswirtschaft: Mit dem Rosengarten als Kongresszentrum, dem Maimarkt im Frühjahr und großen Messeformaten in Mannheim sowie der direkt angrenzenden Heidelberger Wissenschaftslandschaft entstehen regelmäßig saisonale Lastspitzen für Ticket-, Merchandise- und Cateringshops. Wer aus einem gewachsenen, organisch erweiterten Shop kommt, hat oft eine Sammlung halb passender Plugins angehäuft, die sich gegenseitig blockieren. In solchen Fällen ist die erste Aufgabe nicht Neubau, sondern Aufräumen: Plugin-Last reduzieren, Datenmodell begradigen und die Bezahl- und Versandlogik wieder auf einen wartbaren Stand bringen, bevor die nächste Messe-Saison anrollt.

#Technischer Aufbau

Unsere typische Basis: WooCommerce auf aktuellem PHP, Objekt-Caching über Redis, eine schnelle Produktsuche, ein CDN vor dem Shop und ein bewusst schlankes Theme statt eines überladenen Page-Builders. Als Hosting setzen viele unserer Mannheimer Kunden auf deutsche Anbieter wie Hetzner aus Gunzenhausen, IONOS aus Karlsruhe oder mittwald aus Espelkamp, weil das die DSGVO-Argumentation gegenüber Auftraggebern aus dem industriellen Mittelstand vereinfacht. Zahlungen laufen über die jeweils passenden Gateways mit 3D Secure 2. Hintergrundprozesse wie Bestell-E-Mails, ERP-Sync und Rechnungserstellung laufen über den Action Scheduler, damit sie den Checkout nie blockieren. Anpassungen entstehen über Action- und Filter-Hooks in einem eigenen Plugin, nicht durch Eingriffe in den WooCommerce-Kern, denn der Shop eines Mannheimer Händlers muss das nächste Woo-Update ohne Drama überleben.

#Wie ein Projekt abläuft

1. Audit und Bestandsaufnahme. Wir analysieren den bestehenden Shop oder das Vorhaben: Produktstruktur, Checkout, aktive Zahlungsarten, Versandzonen, Steuerregeln, vorhandene Integrationen und eine Lighthouse-Messung auf den meistbesuchten Produkt- und Kategorieseiten. Technische Schulden und schnelle Verbesserungen werden schriftlich dokumentiert, bevor Code entsteht.
2. Plan für Payment, Versand und Integration. Wir legen fest, welche Gateways aus deutscher Käufersicht Pflicht sind, wie Versand und Carrier-Anbindung aussehen, wie die Warenwirtschaft angebunden wird und wo die Grenze zwischen Kern, Plugin-Code und Theme verläuft.
3. Umsetzung in Feature-Branches. Entwicklung nach den Coding Standards von WordPress und WooCommerce, mit Tests auf den Zahlungs- und Bestellpfaden, in nachvollziehbaren Iterationen mit lauffähigem Stand am Ende jedes Schritts.
4. QA gegen Testumgebung. Vollständiger Durchlauf auf einer produktionsnahen Testumgebung: Warenkorb, Checkout, Testzahlungen auf jedem Gateway, Rückerstattung, Kunden-E-Mails, Bestellbearbeitung im Admin. Erst danach geht es live.
5. Go-live und Übergabe. DNS, SSL, Cache-Warmup, Redirect-Prüfung und Monitoring. Nach dem Start bleiben wir in Bereitschaft für die erste kritische Phase und übergeben mit dokumentierten Runbooks für jedes Gateway.

#Probleme, mit denen Mannheimer Händler zu uns kommen

• Der Checkout ist langsam oder bricht ab. Häufig liegt es an Cart-Fragments, einem schweren Theme oder zu vielen synchron geladenen Gateway-Skripten. Wir messen den echten Engpass und beheben ihn, statt ein weiteres Optimierungs-Plugin zu stapeln.
• Kauf auf Rechnung, SEPA und giropay fehlen oder funktionieren halb. Wir richten die in Deutschland erwarteten Bezahlwege sauber ein, inklusive Fehlerpfaden, Webhooks und Idempotenz, damit Doppelbuchungen ausgeschlossen sind.
• Die Buchhaltung passt nicht zum Shop. DATEV-Export, korrekte Rechnungsnummern, MwSt.-Logik und der innergemeinschaftliche EU-Handel über das OSS-Verfahren werden so konfiguriert, dass die Steuerberatung nicht jeden Monat nacharbeiten muss.
• B2B- und Multi-Warehouse-Logik fehlt. Industriezulieferer aus dem Rhein-Neckar-Raum brauchen Bestände an mehreren Lagerstandorten, kundenspezifische Konditionen und Großempfänger-Adressen für Lieferungen direkt an die Fertigung. Diese Logik bauen wir innerhalb von WooCommerce statt in einer Parallelwelt.
• Rechtliche Unsicherheit. Impressum, Widerrufsbelehrung, Preisangabenverordnung, DSGVO/BDSG, das TTDSG für Cookie-Einwilligungen und ab Juni 2025 das Barrierefreiheitsstärkungsgesetz (BFSG) gehören in die Shop-Architektur, nicht in eine nachträgliche Bastelei.

#Was Sie als Ergebnis erwarten können

Wir vereinbaren die Erfolgskriterien vor Projektbeginn schriftlich, statt mit erfundenen Prozentwerten zu werben. Üblich sind: spürbar schnellere Produkt- und Kategorieseiten mit optimierter Bildauslieferung in WebP und AVIF, ein Checkout, der die in Deutschland erwarteten Bezahlarten vollständig und stabil anbietet, sowie eine belastbare Infrastruktur für die Lastspitzen rund um Black Friday und das Weihnachtsgeschäft. Jede Kennzahl wird vor und nach der Umsetzung gemessen und in der Projektdokumentation festgehalten. Für Mannheimer B2B-Shops kommt eine zweite Messreihe dazu: Durchlaufzeit von der Bestellung bis zur Buchung in der Warenwirtschaft, Anteil der Bestellungen ohne manuelle Nacharbeit und Reklamationsquote durch Adress- oder Preisfehler.

#Warum Händler in Mannheim mit uns arbeiten

Wir sind seit Jahren aktiv in der WordPress- und WooCommerce-Community und bauen mit den Werkzeugen, über die andere nur lesen. Wir haben WooCommerce-Shops unterschiedlicher Größe und Lastprofile gebaut und kennen den Unterschied zwischen einem Shop, der gut aussieht, und einem, der in der deutschen Bezahlrealität wirklich konvertiert. Jede Architektur-Entscheidung wird begründet und dokumentiert, damit Ihr Team den Shop danach selbst weiterführen kann. Für Mannheimer Auftraggeber relevant: Wir kennen den Unterschied zwischen einem Shop, der für einen klassischen D2C-Markenhändler in den Planken konfiguriert ist, und einem, der die Beschaffungsprozesse eines Industriezulieferers im Hafen abbildet.

#Sicherheit, DSGVO und BFSG-Barrierefreiheit

Unsere Sicherheits-Baseline gilt für jedes Projekt: HTTPS mit HSTS, eine Content Security Policy gegen XSS, Schwachstellen-Scanning der Abhängigkeiten in der CI, Zwei-Faktor-Authentifizierung für alle Admin-Konten und getestete Backups. Da ein Shop personenbezogene Daten verarbeitet, gehört die DSGVO in die Architektur: ein Einwilligungsmanagement nach TTDSG, das vor dem Setzen nicht-essenzieller Cookies greift, Auftragsverarbeitungsverträge mit allen Dienstleistern, Datensparsamkeit im Checkout und nachvollziehbare Löschkonzepte. Für kritische Industriezulieferer aus dem Hafen wird ergänzend NIS2 relevant, sobald sie als wichtige Einrichtung im Sinne der Richtlinie eingestuft sind. Trusted-Shops- oder eKomi-Anbindung und rechtssichere Pflichttexte (Impressum, Widerrufsbelehrung, AGB) werden technisch sauber eingebunden, nicht nur ins Theme kopiert.

Seit Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) Online-Shops für Verbraucher zu barrierefreien Bedien- und Bezahlflächen nach WCAG 2.1 AA. Wir bauen Checkout, Produktdetailseiten und Kontaktformulare so, dass Tastaturbedienung, Screenreader-Beschriftung, ausreichende Kontrastwerte und sichtbare Fehlermeldungen Teil der Standardarchitektur sind, nicht eines nachträglichen Overlays.

#Performance-Engineering

Geschwindigkeit ist im Wettbewerb ein harter Faktor, gerade wenn ein Shop gegen Amazon-Gewohnheiten ankämpft. Unser Ansatz für WooCommerce in Mannheim:

• Asset-Optimierung: responsive Bilder in WebP und AVIF, bereinigtes und routenweise gesplittetes CSS, Tree-Shaking und Code-Splitting beim JavaScript.
• Caching-Architektur: mehrstufig vom Browser-Cache über das CDN bis zum Objekt-Cache (Redis) und intelligent invalidierten Transients.
• Netzwerk-Optimierung: HTTP/3, Brotli-Kompression, gezielte Preconnect- und DNS-Prefetch-Hints, deutsche Edge-Knoten der gewählten CDN-Anbieter, damit Käufer aus dem Rhein-Neckar-Raum kurze Wege haben.
• Rendering-Optimierung: Critical CSS inline, asynchrone Stylesheets, Lazy Loading von Bildern und Iframes.

Jede Entscheidung wird gemessen, der Vorher-Nachher-Stand dokumentiert und als Baseline beigelegt. Idealo-Preisfeeds für Mannheimer Händler, die im Preisvergleich präsent sein wollen, werden so eingebunden, dass sie nicht bei jedem Cron-Lauf das Backend ausbremsen.

#Häufige Fragen aus Mannheim

Bauen Sie auch B2B-Shops für Zulieferer im Industriehafen oder Maschinenbau? Ja. Netto-Preise, kundenspezifische Preislisten, Mindestbestellmengen, Freigabeprozesse, Multi-Warehouse-Bestand und die Anbindung an JTL-Wawi, plentymarkets, Xentral oder ein bestehendes ERP gehören zu unserem Standardrepertoire.

Können Sie einen bestehenden, langsamen Shop übernehmen? Ja. Wir beginnen mit einem Audit aus Lighthouse-, WP-CLI-Profil- und Query-Monitor-Lauf, finden den realen Engpass und beheben ihn gezielt, statt den Shop neu zu bauen, wo es nicht nötig ist.

Arbeiten Sie nur mit Unternehmen aus Mannheim? Nein. Der Schwerpunkt liegt auf der Metropolregion Rhein-Neckar (Mannheim, Ludwigshafen, Heidelberg, Worms, Speyer) und dem deutschen Markt, aber wir arbeiten deutschlandweit und für Exporteure auch grenzüberschreitend. Gerade Hersteller aus dem Großraum Mannheim, deren Märkte bis Frankreich und in den Beneluxraum reichen, profitieren von einem Shop, der mehrere Sprachen, Währungen und Steuerlogiken sauber trennt.

Wie gehen Sie mit der neuen BNPL-Regulierung um? Ab dem 20. November 2026 fällt durch die EU-Verbraucherkreditrichtlinie das bisherige 200-Euro-Limit für Buy-Now-Pay-Later weg, jede Ratenzahlung wird kreditprüfungspflichtig. Wir konfigurieren Klarna und PayPal Pay Later so, dass die geänderten Anforderungen am Checkout korrekt greifen, ohne dass dabei die Conversion unnötig leidet.

Wie binden Sie Idealo-Feeds und Preisportale ein? Über einen geplanten Export aus dem Shop, der nicht bei jedem Aufruf neu berechnet, sondern aus einem aktualisierten Snapshot ausgeliefert wird. So bleibt der Shop schnell, auch wenn täglich Tausende Produktdatensätze in Richtung Idealo, Google Shopping oder vertikale Branchenportale aus dem Rhein-Neckar-Raum geschickt werden.

#Lokaler Kontext, am Thema WooCommerce orientiert

Der Bezug zu Mannheim, dem Industriehafen und der Metropolregion Rhein-Neckar ist kein Dekor, sondern entscheidet über technische Prioritäten: Ein B2B-Zulieferer aus dem Hafen braucht eine andere Checkout- und Integrationslogik als ein D2C-Markenshop aus der Innenstadt, und beide brauchen die deutsche Bezahl- und Rechtsbasis. Wir halten die Seite und das Projekt bei WooCommerce: klare Ist-Analyse, schriftliche Annahmen, messbare Abnahmekriterien und ein nachvollziehbarer Lieferweg.

#Checkout und Bestellintegrität

Der Checkout ist die einzige Stelle im Shop, an der ein technischer Fehler direkt Geld kostet. Alles davor lässt sich nachträglich reparieren, eine Bestellung mit falschem Zahlungsstatus nicht. Deshalb behandeln wir Zahlungsbestätigung, Bestandsführung und Protokollierung als einen zusammenhängenden Mechanismus und nicht als drei getrennte Plugin-Einstellungen.

Die Server-zu-Server-Benachrichtigung ist die einzige verlässliche Quelle für den Zahlungsstatus. Der Browser-Rücksprung auf die Bestellbestätigungsseite sagt nichts darüber aus, ob das Geld autorisiert wurde. Der Kunde kann den Tab schließen, das Mobilnetz kann während der 3DS-Weiterleitung abbrechen, die Bank kann die Freigabe verzögert bestätigen. woocommerce_thankyou feuert nur, wenn der Browser zurückkommt, und darf deshalb nie den Bestellstatus setzen. Verbindlich ist ausschließlich der Callback, den das Gateway serverseitig an den Shop schickt, in WooCommerce üblicherweise über WC()->api_request_url() und den Hook woocommerce_api_request. Erst dieser Aufruf löst WC_Order::payment_complete() aus, setzt die Transaktions-ID über set_transaction_id() und hebt die Bestellung aus pending in den Folgestatus, den woocommerce_payment_complete_order_status bestimmt, in der Regel processing, bei rein digitalen Bestellungen completed. Vor der Verarbeitung wird der Rohtext des Requests über php://input gelesen, die daraus berechnete Signatur mit hash_equals() gegen die mitgeschickte verglichen und der Aufruf bei Abweichung verworfen, damit eine manipulierte Anfrage nicht als Zahlungseingang durchgeht. Der Endpunkt antwortet schnell mit HTTP 200 und lagert die eigentliche Arbeit (ERP-Sync, Rechnungserzeugung, Versand-Trigger) über den Action Scheduler aus.

Wiederholte Signale müssen idempotent verarbeitet werden. Jedes ernst zu nehmende Gateway wiederholt die Zustellung, wenn der Shop nicht mit HTTP 200 antwortet, und tut das über Stunden bis Tage hinweg. Ein Auslieferungs-Fenster, ein 502 des Reverse Proxy oder eine Zeitüberschreitung im ERP-Aufruf reichen aus, damit dieselbe Zahlung mehrfach eintrifft. Wir speichern die Event-ID des Gateways in einer eigenen Tabelle mit UNIQUE-Index und lassen die Datenbank entscheiden: Schlägt das Einfügen fehl, war das Ereignis schon verarbeitet, und der Handler bricht sauber ab. Die Prüfung darf nicht als Lesen mit anschließendem Schreiben in PHP erfolgen, weil zwei parallele Callbacks genau zwischen diesen beiden Schritten kollidieren können. Zusätzlich wird vor jeder Zustandsänderung mit has_status() geprüft, ob die Bestellung den Zielzustand bereits erreicht hat. Wenn HPOS als Speicher aktiv ist, gilt dasselbe: Statuswechsel laufen über WC_Order::update_status() mit Begründungstext, nie über direkte Schreibzugriffe auf die Order-Tabellen.

Bestand wird beim Start der Zahlung reserviert, nicht erst bei der Buchung. WooCommerce legt beim Absenden des Checkouts eine Reservierung in der Tabelle für reservierten Bestand an, deren Gültigkeit an die Einstellung woocommerce_hold_stock_minutes gekoppelt ist, standardmäßig 60 Minuten. Läuft die Frist ab, ohne dass eine Zahlungsbestätigung eintrifft, wird die Reservierung freigegeben und die Bestellung storniert. Die endgültige Abbuchung übernimmt wc_maybe_reduce_stock_levels() beim Statuswechsel, die Rückbuchung wc_maybe_increase_stock_levels() bei Stornierung. Für Mannheimer B2B-Shops mit Beständen an mehreren Lagerstandorten reicht das Standardverhalten selten aus: Dort muss die Reservierung den Standort mitführen, sonst reserviert der Shop Ware, die physisch im Außenlager liegt und nicht rechtzeitig an die Fertigung geliefert werden kann. Bei Rechnungskauf, der in Deutschland eine Standarderwartung ist, wird die Reservierung an die Freigabe des Zahlungsdienstleisters gekoppelt, nicht an den Klick auf den Bestellbutton.

Abgelehnte Zahlungen brauchen einen definierten Rückweg. process_payment() liefert bei Ablehnung ein Fehlerergebnis, die Bestellung bleibt auf pending oder wechselt auf failed, und der Warenkorb muss erhalten bleiben, damit der Kunde eine andere Bezahlart wählen kann. Was dabei regelmäßig schiefgeht: Die Ablehnung kommt asynchron, nachdem der Kunde die Seite längst verlassen hat, und der Shop hat den Bestand bereits abgebucht. Deshalb prüft der Callback-Handler explizit auf Ablehnungs- und Rückbuchungsereignisse und führt die Bestandskorrektur genauso konsequent aus wie die Buchung. Eine an der SCA-Prüfung gescheiterte Kartenzahlung, eine zurückgegebene SEPA-Lastschrift und eine von Klarna negativ beschiedene Bonitätsprüfung sind drei verschiedene Fälle mit drei verschiedenen Folgeprozessen, und sie sind in der Gateway-Dokumentation einzeln zu beschreiben.

Teilerstattungen sind im B2B der Normalfall, nicht die Ausnahme. Wenn von zehn Positionen zwei aus einer anderen Charge nachgeliefert werden oder eine Position beanstandet wird, entsteht keine Vollstornierung, sondern eine Teilerstattung mit anteiliger Umsatzsteuer und anteiligen Versandkosten. In WooCommerce erzeugt wc_create_refund() dafür ein eigenes WC_Order_Refund-Objekt, das die Ursprungsbestellung unverändert lässt. Ob die Rückzahlung überhaupt über die API laufen kann, entscheidet supports( 'refunds' ) des Gateways; wo das fehlt, muss der manuelle Erstattungsweg dokumentiert sein, sonst driften Shop und Buchhaltung auseinander. Die Hooks woocommerce_order_partially_refunded und woocommerce_order_fully_refunded sind die richtigen Ansatzpunkte, um Lagerrückbuchung, DATEV-Export und Storno-Rechnung anzustoßen. get_remaining_refund_amount() verhindert, dass in Summe mehr erstattet wird als vereinnahmt wurde.

Protokollierung entscheidet, ob die Bestellhistorie rekonstruierbar bleibt. Jeder eingehende Callback wird über wc_get_logger() mit eigener Quelle je Gateway geschrieben, inklusive Event-ID, Bestell-ID, Betrag, Währung und Ergebnis der Signaturprüfung. Kartendaten und vollständige IBANs gehören dort nicht hinein, das schreibt schon der Grundsatz der Datenminimierung nach Artikel 5 DSGVO vor. Parallel dazu bekommt die Bestellung über add_order_note() eine für Menschen lesbare Spur, damit Support und Buchhaltung im Admin sehen, warum ein Status gewechselt hat, ohne Serverlogs anzufordern. Die Aufbewahrungsdauer der Logdateien steuert der Filter woocommerce_logger_days_to_retain_logs und wird bewusst so gesetzt, dass sie den üblichen Reklamations- und Rückbuchungszeitraum abdeckt. Diese Kombination aus maschinellem Log und Bestellnotiz ist der Unterschied zwischen einer Klärung, die aus den Daten heraus möglich ist, und einer Diskussion mit dem Zahlungsdienstleister ohne eigene Belege. Wie schnell auf Auffälligkeiten reagiert wird und wer nachts erreichbar ist, regelt der Wartungsvertrag.

Vor jedem Go-live läuft dieser Teil als eigener QA-Block: Zahlung mit Testkarten je Gateway, doppelt zugestellter Callback, Callback mit ungültiger Signatur, abgelaufene Bestandsreservierung, abgelehnte Zahlung nach Verlassen der Seite, Teilerstattung für eine Einzelposition und die Kontrolle, dass jeder dieser Fälle in Log und Bestellnotiz auffindbar ist.

#Projekt in Mannheim starten

Wenn Sie in Mannheim oder der Metropolregion Rhein-Neckar WooCommerce-Entwicklung brauchen, melden Sie sich für ein unverbindliches Erstgespräch. Wir sehen uns Ihre Situation an, klären Ziele, Zeitrahmen und Rahmenbedingungen und geben eine ehrliche Einschätzung. Die Preisgestaltung ist individuell und richtet sich nach Umfang und Integrationstiefe. Jedes gute Projekt beginnt mit klarer Kommunikation und gemeinsamen Erwartungen.