Testbestellung vor dem Shopstart:
Fehlende Zahlungsarten und Rechnungsdownloads prüfen

Ein Webshop kann auf den ersten Blick fertig wirken: Produkte sind angelegt, die Kasse ist erreichbar und mehrere Zahlungsarten wurden konfiguriert. Trotzdem ist damit noch nicht bewiesen, dass ein Kunde den gesamten Bestellweg erfolgreich durchlaufen kann. Eine Zahlungsart kann im echten Checkout fehlen. Die Bestellung kann zwar eingehen, aber keine Rechnung erzeugen. Oder das Dokument ist vorhanden, lässt sich im Kundenkonto jedoch nicht öffnen.

Genau deshalb gehört vor jeden Shopstart eine vollständige Testbestellung. Du prüfst nicht nur einzelne Einstellungen, sondern den zusammenhängenden Weg aus Sicht eines echten Kunden: Warenkorb → Kasse → Zahlung → Bestellung → Rechnung → Kundenkonto. Erst wenn diese Kette funktioniert, hast du eine belastbare Grundlage für die Freigabe.

Peleides bringt die dafür notwendigen Bereiche in einer gemeinsamen Umgebung zusammen. Entscheidend ist aber nicht die Anzahl vorhandener Funktionen, sondern ihr Zusammenspiel. Wenn du den Peleides-Webshop als zusammenhängenden Verkaufsprozess betrachtest, erkennst du Fehler früher und kannst sie nachvollziehbar eingrenzen.

Warum eine eingerichtete Kasse
noch keine Startfreigabe ist

Eine Admin-Einstellung zeigt dir, was konfiguriert wurde. Der Checkout zeigt dir, was ein Kunde tatsächlich sieht. Zwischen diesen beiden Ebenen können weitere Bedingungen liegen: der ausgewählte Modus, die Vollständigkeit einer Anbindung, der Inhalt des Warenkorbs, das Land, die Währung, der Status des Kundenkontos oder eine shopindividuelle Regel. Deshalb darf ein aktivierter Schalter nie der einzige Abnahmebeleg sein.

In der aktuellen Peleides-Administration sind Konfigurationsbereiche für Banküberweisung, PayPal, Stripe und PostFinance sichtbar. Das belegt, dass diese Zahlungswege im System vorgesehen und konfigurierbar sind. Es belegt nicht automatisch, dass jede Zahlungsart in jedem Checkout angezeigt wird oder einen echten Test erfolgreich abschliesst. Genau diese Trennung macht den Test so wichtig.

Ein älterer, vollständig anonymisierter Supportfall zeigt das Problem sehr anschaulich. Bei einer geplanten Testbestellung wurde im Checkout nur eine Zahlungsart angezeigt, obwohl weitere erwartet wurden. Im selben Verlauf wurde später gemeldet, dass der Rechnungsdownload im Kundenkonto nicht funktionierte. Für die fehlenden Zahlungsarten war im Verlauf keine belastbare Ursache dokumentiert. Das Symptom ist deshalb ein sinnvoller Ausgangspunkt für eine Checkliste, aber kein Beleg für eine bestimmte technische Erklärung.

Die wichtigste Regel lautet: Beobachtung und Ursache werden getrennt festgehalten. „Im Checkout ist nur eine Zahlungsart sichtbar“ ist eine Beobachtung. „Die Schnittstelle ist defekt“ wäre ohne weitere Prüfung lediglich eine Vermutung. Diese saubere Sprache verhindert voreilige Änderungen und macht die Fehlersuche deutlich effizienter.

Die Testbestellung sauber vorbereiten

Ein guter Test beginnt nicht mit einem spontanen Klick durch den Shop. Lege zuerst fest, was du erwartest. Notiere den Testzeitpunkt, das verwendete Gerät, den Browser, den Login-Status, das Lieferland, die Währung, den Inhalt des Warenkorbs und die erwarteten Zahlungsarten. Verwende ausschliesslich neutrale Testdaten und einen dafür freigegebenen Testzugang.

Wähle einen realistischen Warenkorb, der dem späteren Verkauf entspricht. Wenn du physische und digitale Produkte anbietest oder verschiedene Liefergebiete bedienst, reicht ein einziger Testfall möglicherweise nicht aus. Starte dennoch mit einem klar abgegrenzten Basisszenario. Weitere Varianten kommen erst danach. So weisst du bei einer Abweichung, welcher konkrete Fall betroffen ist.

Halte auch das erwartete Ergebnis für jede Station fest:

• Der Warenkorb enthält das richtige Produkt und die richtige Menge.
• Die Kasse fragt nur die vorgesehenen Daten ab.
• Alle für diesen Testfall erwarteten Zahlungsarten sind sichtbar.
• Die ausgewählte Zahlung lässt sich bis zur vorgesehenen Bestätigung durchlaufen.
• Die Bestellung erscheint genau einmal in der Administration.
• Die Bestellbestätigung enthält die erwarteten Angaben.
• Die Rechnung wird gemäss der Shopkonfiguration erzeugt.
• Das Kundenkonto zeigt die Bestellung und erlaubt den vorgesehenen Dokumentenzugriff.

Diese Liste ist bewusst ergebnisorientiert. Sie verlangt nicht, dass du technische Interna errätst. Sie beschreibt, was ein Kunde und was ein Shopverantwortlicher nach jedem Schritt sehen müssen.

Wenn Zahlungsarten
im Checkout fehlen

Fehlt eine erwartete Zahlungsart, prüfst du zuerst die einfachsten Ebenen. Ist sie für den Shop grundsätzlich vorgesehen? Befindet sich die Anbindung im passenden Betriebsmodus? Sind die notwendigen Konfigurationsfelder vollständig? Passt der Testfall zu den Bedingungen, unter denen die Zahlungsart angeboten werden soll? Erst wenn diese Fragen beantwortet sind, lohnt sich eine tiefergehende technische Analyse.

Vergleiche immer Erwartung und tatsächliche Anzeige. Ein Screenshot des Checkout-Bereichs kann dabei helfen, sofern er keine personenbezogenen Daten, Adressen, E-Mail-Adressen oder zahlungsbezogene Geheimnisse enthält. Ebenso wichtig ist ein kurzer Vermerk, welche Zahlungsarten du erwartet hast. Ohne diese Erwartung ist später nicht mehr eindeutig, ob wirklich etwas fehlte oder ob die Kasse korrekt gefiltert hat.

Für die konkrete Einrichtung kannst du die vorhandenen Peleides-Unterlagen verwenden. Die Anleitung, Stripe in Peleides einzurichten, beschreibt diesen Zahlungsanbieter als eigene Vertiefung. Für Schweizer Shopprojekte steht zusätzlich die Dokumentation zu PostFinance Checkout als Peleides-Schnittstelle bereit. Der neue Abnahmetest ersetzt diese anbieterspezifischen Anleitungen nicht. Er prüft, ob die gewählte Konfiguration am Ende im realen Kundenweg ankommt.

Bleibt die Abweichung bestehen, sichere nur die für die Diagnose notwendigen Informationen. Zugangsdaten, Schlüssel, Bankverbindungen und persönliche Kundendaten gehören weder in ein Ticket noch in einen Magazin-Screenshot. Ein guter Fehlerbericht enthält den Testfall, den Zeitpunkt, die erwartete und die sichtbare Auswahl sowie die letzte erfolgreich erreichte Station. Das genügt häufig, um die nächste Prüfung gezielt anzusetzen.

Bestellung, Rechnung und Kundenkonto
als Kette prüfen

Nach der Zahlung ist der Test nicht beendet. Prüfe zuerst, ob die Bestellung in der Administration angekommen ist und ob sie nur einmal vorhanden ist. Vergleiche danach die wichtigsten Angaben mit dem Testfall: Produkt, Menge, Kundenstatus, Lieferart und gewählter Zahlungsweg. Die öffentlichen Informationen zu den Bestellfunktionen im Peleides-Webshop geben dir den passenden Funktionsrahmen für diese Station.

Im nächsten Schritt kontrollierst du die Kommunikation. Ist eine Bestellbestätigung vorgesehen, muss sie den richtigen Vorgang verständlich abbilden. Prüfe Betreff, Anrede, Bestellbezug und die für den Kunden wichtigen nächsten Schritte. Verwende dafür einen kontrollierten Testempfänger. Reale Kundenadressen gehören nicht in ein wiederverwendbares Abnahmeprotokoll.

Danach folgt die Rechnung. Die aktuelle Peleides-Administration enthält eine Option, eine Rechnung automatisch mit der Bestellung zu generieren. Auch hier gilt: Die Einstellung ist nur die Voraussetzung. Der Test muss zeigen, ob tatsächlich ein Dokument für den neuen Auftrag vorhanden ist und ob dessen Zuordnung stimmt.

Öffne anschliessend das Kundenkonto mit demselben Testzugang. Ist die Bestellung sichtbar? Führt der Dokumentenbereich zur richtigen Rechnung? Lässt sich die Datei öffnen oder herunterladen? Prüfe ausserdem, ob der Dateiname und die Darstellung verständlich sind. Ein Dokument, das nur in der Administration existiert, aber vom vorgesehenen Kundenweg nicht erreichbar ist, erfüllt den Abnahmetest noch nicht.

Warum Slugs und Routen
Teil des Tests sind

Ein Slug ist der lesbare Teil einer Webadresse. In Peleides lassen sich unter anderem Pfade für Warenkorb, Kasse und Kundenkonto konfigurieren. Solche Einstellungen wirken unscheinbar, können aber eine technische Abhängigkeit berühren. Wenn ein Link oder eine Funktion intern noch einen früheren Pfad erwartet, kann der sichtbare Button korrekt aussehen und trotzdem am falschen Ziel enden.

Der anonymisierte Supportfall liefert dafür einen konkreten historischen Hinweis: Beim Rechnungsdownload war dokumentiert, dass der Kundenkonto-Slug von einem früheren Wert auf einen neuen Wert geändert worden war, während eine Code-Stelle noch den alten Pfad erwartete. Die Zuordnung wurde damals angepasst. Das ist kein Hinweis auf einen heutigen Peleides-Defekt, sondern ein gutes Beispiel dafür, warum konfigurierbare Routen in einen vollständigen Regressionstest gehören.

Prüfe nach jeder Änderung an Kundenkonto-, Warenkorb- oder Kassenpfaden mindestens den direkten Seitenaufruf, die Navigation aus dem Shop und einen funktionsgebundenen Link wie den Dokumentendownload. Das Ziel ist nicht, jeden Link im System manuell zu testen. Du konzentrierst dich auf die Stellen, deren Funktion vom geänderten Pfad abhängt.

Die Peleides-Funktionsseite erklärt, wie Kunden Rechnungen und weitere Dokumente herunterzuladen können. Nutze dieses erwartete Ergebnis als letzte Station deines Tests. Wenn der Zugriff scheitert, halte fest, ob bereits die Kundenkonto-Seite, die Bestellansicht oder erst der Download selbst betroffen ist. Diese Eingrenzung spart bei der Fehleranalyse viel Zeit.

Ein reproduzierbares
Abnahmeprotokoll verwenden

Ein Test ist besonders wertvoll, wenn er später wiederholt werden kann. Erstelle deshalb ein kurzes Protokoll mit einer Zeile pro Station. Für jede Zeile genügen Erwartung, Ergebnis, Status und Beleg. Als Status verwendest du beispielsweise bestanden, abweichend oder blockiert. Beim Beleg reicht ein datenschutzsicherer Screenshot oder eine neutrale Testreferenz.

Führe den Basistest nach Änderungen an Zahlungsanbindungen, Checkout-Feldern, Kundenkonto-Pfaden, Rechnungslogik oder Bestellkommunikation erneut aus. So wird aus einer einmaligen Kontrolle ein kleiner Regressionstest. Du erkennst nicht nur neue Fehler, sondern auch unbeabsichtigte Folgen einer an anderer Stelle vorgenommenen Anpassung.

Vermeide es, während eines fehlgeschlagenen Tests mehrere Einstellungen gleichzeitig zu verändern. Ändere eine klar begründete Sache, wiederhole denselben Testfall und dokumentiere das Ergebnis. Sonst ist später nicht nachvollziehbar, welche Änderung geholfen oder eine weitere Abweichung erzeugt hat.

Die Startfreigabe erfolgt erst, wenn alle für den Basistest verpflichtenden Stationen bestanden sind. Eine unwichtige optische Abweichung kann als Nacharbeit dokumentiert werden. Eine fehlende Zahlungsart, eine nicht eingegangene Bestellung oder ein nicht erreichbares Rechnungsdokument ist dagegen ein echter Blocker. So bleibt die Entscheidung transparent und hängt nicht vom Bauchgefühl ab.

Dein nächster Schritt

Wenn du einen neuen Shop vorbereitest oder mit deinem aktuellen System unzufrieden bist, beginne nicht bei einer langen Funktionsliste. Beginne bei deinem wichtigsten Verkaufsvorgang und teste ihn vollständig. Ein sauberer Ende-zu-Ende-Test zeigt dir, ob Einstellungen, Oberfläche und Kundenerlebnis wirklich zusammenpassen.

Möchtest du den Ablauf für deinen Shop gemeinsam durchgehen, kannst du eine unverbindliche Peleides-Live-Demo vereinbaren. Im Gespräch lässt sich dein gewünschter Bestellweg aufnehmen, im System zeigen und in konkrete Testfälle übersetzen.