Deutsch English

Testleitfaden für Integrationen

Dieser Leitfaden prüft, ob eine Integration das tut, was sie verspricht. Er gilt für jede Umsetzung — ob von uns geliefert, von Ihrem Team gebaut oder aus unserer Spezifikation erzeugt. Jeder Schritt nennt die Vorbereitung, die Durchführung und das Ergebnis, das eintreten muss. Tritt es nicht ein, ist die Integration nicht abnahmefähig.

Sechs der Schritte sind als Ausschlusskriterium gekennzeichnet. Sie prüfen nicht die Bequemlichkeit, sondern die Wirksamkeit der Sperre. Wer sie nicht besteht, hat eine Alterssperre, die sich umgehen lässt — und damit keine.

Abnahme anfragen Zur Installationsanleitung

Vorbereitung

Umgebung	Testumgebung von insic, nicht die Produktivumgebung. Bestellungen dürfen keine Zahlung auslösen.
Zugänge	Administratorkonto im Shop, Zugriff auf das Protokoll, Postfach für Testadressen.
Werkzeuge	Browser mit Entwicklerwerkzeugen. Für die Schnittstellen-Schritte genügt „Als cURL kopieren“ im Netzwerk-Tab — ein eigenes Werkzeug ist nicht nötig.
Testdaten	Eine frische E-Mail-Adresse je Durchlauf. Adressen aus früheren Läufen verfälschen das Ergebnis, weil bereits ein Konto besteht.
Ausgangszustand	Kaufsperre eingeschaltet, geforderter Status verifiziert, Protokollierung der Rückmeldungen aktiv.

Alle Schritte im privaten Fenster durchführen. Eine bestehende Administratorsitzung verfälscht mehrere Prüfungen, weil sie Zwischenspeicher und Berechtigungen mitbringt, die eine Kundin nicht hat.

A — Grundfunktion

A1 · Widget erscheint vollständig

Durchführung	Verifizierungsseite als abgemeldeter Besucher aufrufen.
Erwartet	Das Widget erscheint mit Beschriftungen, in den Farben des Partners, ohne Fehlermeldung in der Browserkonsole.
Nicht bestanden	Felder ohne Beschriftung oder ohne Gestaltung: Die Domain ist nicht freigeschaltet. Leere Fläche: Der Loader wird nicht geladen oder die Kennung fehlt.

A2 · Registrierung legt ein Konto an

Durchführung	Im Widget mit frischer Adresse registrieren und die Prüfstrecke durchlaufen.
Erwartet	Im Shop entsteht ein Konto mit dieser Adresse. Es trägt eine Kennung des Prüfdienstes.
Nicht bestanden	Kein Konto vorhanden. Prüfen Sie, ob der Browser-Rücklauf feuert und ob die Kontoanlage über Rückmeldung eingeschaltet ist.

A3 · Rückmeldung erreicht den Shop

Durchführung	Nach A2 die Statusanzeige beobachten, ohne die Seite neu zu laden.
Erwartet	Der Status wechselt selbsttätig. Im Protokoll steht ein Eingang mit dem Ergebnis übernommen.
Nicht bestanden	Protokoll leer: Die Rückmeldeadressen zeigen nicht auf diesen Shop. Eingang vorhanden, aber kein Konto gefunden: Die Zuordnung über Kennung oder Adresse greift nicht.

B — Wirksamkeit der Sperre

Der Kern der Abnahme. Vier der sechs Ausschlusskriterien stehen hier.

B1 · Kasse verweigert ungeprüfte Konten

Vorbereitung	Konto mit Status 0, altersbeschränktes Produkt im Warenkorb.
Durchführung	Kasse aufrufen und Bestellung abschicken.
Erwartet	Die Bestellung wird abgelehnt, mit verständlichem Hinweis und Weg zur Prüfung. Keine Bestellung in der Übersicht.
Nicht bestanden	Bestellung geht durch, oder der Hinweis erscheint erst nach der Zahlung.

B2 · Sperre hält auch ohne Oberfläche · Ausschlusskriterium

Vorbereitung	Wie B1. Im Netzwerk-Tab die Anfrage der Kasse mit „Als cURL kopieren“ sichern.
Durchführung	Die kopierte Anfrage im Terminal erneut senden, unter Umgehung der Oberfläche.
Erwartet	Die Schnittstelle antwortet mit einem Fehler. Es entsteht keine Bestellung.
Nicht bestanden	Die Bestellung wird angelegt. Dann sitzt die Prüfung im Browser statt auf dem Server — die Sperre ist wirkungslos, weil sie sich mit fünf Zeilen umgehen lässt.

B3 · Geprüfte Konten kommen durch

Vorbereitung	Dasselbe Konto, jetzt mit Status verifiziert.
Durchführung	Bestellung erneut abschicken.
Erwartet	Die Bestellung geht durch, ohne erneute Prüfung und ohne zusätzliche Rückfrage.
Nicht bestanden	Weiterhin gesperrt. Häufigste Ursache: Der geforderte Status ist höher gesetzt als der erreichte.

B4 · Widerruf wirkt sofort · Ausschlusskriterium

Vorbereitung	Verifiziertes Konto aus B3, Warenkorb gefüllt.
Durchführung	Den Status beim Prüfdienst zurücksetzen und ohne Abmelden sofort bestellen.
Erwartet	Die Bestellung wird abgelehnt.
Nicht bestanden	Die Bestellung geht durch. Dann verlässt sich die Integration auf einen gespeicherten Wert, statt vor der Bestellung nachzufragen.

B5 · Nur betroffene Ware ist gesperrt

Vorbereitung	Sperre auf eine Kategorie eingegrenzt, Konto mit Status 0.
Durchführung	Erst ein freies Produkt bestellen, dann ein gesperrtes.
Erwartet	Das freie Produkt geht durch, das gesperrte nicht. Ein gemischter Warenkorb wird abgelehnt.
Nicht bestanden	Der gemischte Warenkorb geht durch — dann ließe sich die Sperre durch Beilegen eines freien Artikels aushebeln.

C — Verhalten bei Störung und Angriff

C1 · Ausfall sperrt, statt durchzulassen · Ausschlusskriterium

Vorbereitung	Konto mit Status 0. Die API-Adresse in den Einstellungen auf eine nicht erreichbare Adresse ändern.
Durchführung	Bestellung versuchen.
Erwartet	Die Bestellung wird abgelehnt. Die Meldung nennt eine vorübergehende Störung, keinen technischen Fehler.
Nicht bestanden	Die Bestellung geht durch. Dann genügt es, den Prüfdienst zu stören, um die Sperre auszuschalten.

Adresse anschließend zurücksetzen. Alle folgenden Schritte brauchen wieder eine erreichbare API.

C2 · Rückmeldung ohne Nachweis wird verworfen · Ausschlusskriterium

Durchführung	Eine gültige Rückmeldung nachbilden, die einem bestehenden Konto Status 2 zuweist — aber ohne Kopfzeile mit dem Token beziehungsweise mit falscher Signatur senden.
Erwartet	Antwort mit Fehlercode. Der Status des Kontos bleibt unverändert. Im Protokoll steht abgewiesen.
Nicht bestanden	Der Status ändert sich. Dann kann jeder, der die Adresse kennt, sich selbst verifizieren — und, wenn Gutscheine daran hängen, in Serie Geld erzeugen.

C3 · Kein Nachweis, keine Annahme

Vorbereitung	Das Token in den Einstellungen leeren.
Durchführung	Eine korrekte Rückmeldung senden.
Erwartet	Sie wird abgewiesen. Eine Integration ohne gesetztes Geheimnis darf nichts annehmen, statt alles anzunehmen.
Nicht bestanden	Die Rückmeldung wird verarbeitet.

C4 · Wiederholung schadet nicht

Durchführung	Dieselbe gültige Rückmeldung dreimal hintereinander senden.
Erwartet	Ein Konto, ein Status, ein Gutschein. Keine Dubletten.
Nicht bestanden	Mehrere Konten oder mehrere Gutscheine. Prüfdienste wiederholen Rückmeldungen bei Zeitüberschreitung — das passiert im Betrieb ohne Zutun.

C5 · Browser-Ereignisse gelten nicht als Nachweis · Ausschlusskriterium

Durchführung	In der Browserkonsole das Ereignis nachbilden, mit dem das Widget eine bestandene Prüfung meldet.
Erwartet	Die Anzeige darf sich kurzzeitig ändern, der Status auf dem Server nicht. Eine anschließende Bestellung wird abgelehnt.
Nicht bestanden	Der Status wird übernommen und die Bestellung geht durch.

D — Konto und Anmeldung

D1 · Zugang ohne bekanntes Passwort

Vorbereitung	Konto, das über die Rückmeldung entstanden ist.
Durchführung	Die zugestellte Mail öffnen, dem Link folgen, Passwort setzen.
Erwartet	Nach dem Setzen ist die Person angemeldet. Der Link funktioniert genau einmal.
Nicht bestanden	Der Link führt auf die Anmeldeseite des Shopsystems oder lässt sich mehrfach verwenden.

D2 · Anmeldung bricht die Strecke nicht

Durchführung	Auf der Anmeldeseite absichtlich ein falsches Passwort eingeben.
Erwartet	Die Fehlermeldung erscheint auf derselben Seite. Die Meldung verrät nicht, ob die Adresse bekannt ist.
Nicht bestanden	Weiterleitung auf die Standard-Anmeldeseite des Shopsystems, oder eine Meldung wie „Benutzer unbekannt“.

D3 · Abmelden beendet beide Sitzungen

Durchführung	Abmelden, dann die Verifizierungsseite erneut aufrufen.
Erwartet	Das Widget zeigt die Registrierung, nicht die Strecke des vorherigen Kontos.
Nicht bestanden	Die vorherige Prüfstrecke erscheint. Am geteilten Rechner sähe die nächste Person die Daten der vorherigen.

E — Datensparsamkeit

E1 · Der Shop speichert keine Personendaten · Ausschlusskriterium

Durchführung	Nach einer vollständigen Prüfung alle zum Konto gespeicherten Zusatzfelder ansehen.
Erwartet	Kennung, Status, Zeitpunkt, zuletzt gelaufenes Verfahren. Sonst nichts.
Nicht bestanden	Geburtsdatum, Anschrift, Ausweisnummer oder Bankverbindung sind gespeichert. Auch dann, wenn es „nur zur Anzeige“ geschieht.

E2 · Das Protokoll enthält keine Inhalte

Durchführung	Protokolleinträge und Serverprotokoll nach einem Durchlauf durchsehen.
Erwartet	Zeitpunkt, Art des Vorgangs, Ergebnis. Keine übertragenen Inhalte, keine Passwörter, keine Token.
Nicht bestanden	Vollständige Rückmeldungen stehen im Klartext im Protokoll.

F — Optionale Funktionen

Nur zu prüfen, wenn eingeschaltet.

F1 · Bestätigungscode

Erwartet	Ohne Code keine Bestellung. Nach mehreren Fehlversuchen wird der Code ungültig. Ändert sich der Warenkorb, ist erneut zu bestätigen. Ein abgelaufener Code wird abgewiesen.
Nicht bestanden	Der Code lässt sich beliebig oft raten oder gilt nach Änderung des Warenkorbs weiter.

F2 · Gutschein

Erwartet	Genau ein Gutschein je Person. Er ist an die geprüfte Adresse gebunden und einmal einlösbar. Nach Löschen und erneutem Anlegen des Kontos entsteht kein zweiter.
Nicht bestanden	Mehrfachausgabe, oder der Code lässt sich mit beliebiger Adresse einlösen.

Abnahmeprotokoll

Zum Ausfüllen und Zurücksenden. Eine Integration gilt als abgenommen, wenn alle Ausschlusskriterien bestanden sind und die übrigen Abweichungen benannt und begründet wurden.

Schritt	Bestanden	Bemerkung
A1 Widget vollständig
A2 Konto entsteht
A3 Rückmeldung kommt an
B1 Kasse verweigert
B2 Sperre ohne Oberfläche
B3 Geprüfte kommen durch
B4 Widerruf wirkt
B5 Nur betroffene Ware
C1 Ausfall sperrt
C2 Rückmeldung ohne Nachweis
C3 Kein Geheimnis, keine Annahme
C4 Wiederholung schadet nicht
C5 Browser-Ereignis zählt nicht
D1 Zugang ohne Passwort
D2 Anmeldung bricht nicht
D3 Abmelden wirkt doppelt
E1 Keine Personendaten
E2 Protokoll ohne Inhalte
F1 Bestätigungscode
F2 Gutschein

Geprüft von · Datum · System und Version · Umgebung

Protokoll einreichen

Hinweise zur Durchführung

Warum die Schnittstellen-Schritte nicht weggelassen werden dürfen

B2, C1, C2 und C5 prüfen dasselbe aus vier Richtungen: ob die Entscheidung auf dem Server fällt. Genau das ist die Stelle, an der Integrationen erfahrungsgemäß scheitern — die Oberfläche sieht richtig aus, die Prüfung sitzt aber im Browser. Wer nur durchklickt, bemerkt das nicht.

Testkonten hinterlassen Spuren

Jeder Durchlauf erzeugt ein Konto beim Prüfdienst, im Shop und gegebenenfalls einen Gutschein. Löschen Sie Testkonten nach der Abnahme in beiden Systemen, sonst blockieren sie die Adressen für spätere Läufe.

Nach jeder Aktualisierung erneut prüfen

Ein Update des Shopsystems, des Themes oder eines Zahlungsmoduls kann die Sperre aushebeln, ohne dass jemand die Integration angefasst hat. Die Gruppe B mit rund zehn Minuten Aufwand gehört deshalb in jede Abnahme nach einer Aktualisierung.

Nur gegen eigene Systeme

Dieser Leitfaden beschreibt Prüfungen, die Konten anlegen und Bestellvorgänge auslösen. Führen Sie ihn ausschließlich auf Systemen durch, für die Sie verantwortlich sind, und ausschließlich in der Testumgebung.

Test guide for integrations

This guide verifies that an integration does what it claims. It applies to every implementation — shipped by us, built by your team, or generated from our specification. Each step states the setup, the action and the result that must occur. If it does not occur, the integration is not ready for acceptance.

Six steps are marked as a blocking criterion. They do not test convenience, they test whether the gate actually holds. An integration that fails them has an age gate that can be bypassed — which means it has none.

Request acceptance Installation guide

Preparation

Environment	The insic test environment, not production. Orders must not trigger a payment.
Access	Administrator account in the shop, access to the log, a mailbox for test addresses.
Tools	A browser with developer tools. For the API steps, „Copy as cURL“ in the network tab is enough — no dedicated tool required.
Test data	A fresh email address per run. Addresses from earlier runs distort the result because an account already exists.
Starting state	Purchase gate enabled, required status verified, callback logging switched on.

Run every step in a private window. An existing administrator session distorts several checks because it carries caches and capabilities a customer does not have.

A — Basic function

A1 · Widget renders completely

Action	Open the verification page as a signed-out visitor.
Expected	The widget appears with labels, in the partner’s colours, with no error in the browser console.
Failed if	Fields without labels or styling: the domain is not allowlisted. Empty area: the loader is not being fetched, or the partner identifier is missing.

A2 · Registration creates an account

Action	Register in the widget with a fresh address and complete the verification flow.
Expected	An account with that address exists in the shop and carries an identifier from the verification service.
Failed if	No account exists. Check whether the browser callback fires and whether account creation via callback is enabled.

A3 · Callback reaches the shop

Action	After A2, watch the status display without reloading the page.
Expected	The status changes on its own. The log shows an entry with the outcome accepted.
Failed if	Empty log: the callback URLs do not point at this shop. Entry present but no account found: matching by identifier or address is not working.

B — Effectiveness of the gate

The core of the acceptance test. Four of the six blocking criteria are here.

B1 · Checkout rejects unverified accounts

Setup	Account at status 0, age-restricted product in the cart.
Action	Open the checkout and place the order.
Expected	The order is rejected, with an understandable message and a path to verification. No order appears in the list.
Failed if	The order goes through, or the message only appears after payment.

B2 · The gate holds without the interface · blocking criterion

Setup	As in B1. In the network tab, capture the checkout request with „Copy as cURL“.
Action	Replay the captured request from a terminal, bypassing the interface.
Expected	The API responds with an error. No order is created.
Failed if	The order is created. The check then lives in the browser rather than on the server — the gate is worthless, because five lines are enough to bypass it.

B3 · Verified accounts pass

Setup	The same account, now at status verified.
Action	Place the order again.
Expected	The order goes through, with no repeat verification and no extra prompt.
Failed if	Still blocked. Most common cause: the required status is set higher than the one reached.

B4 · Revocation takes effect immediately · blocking criterion

Setup	The verified account from B3, cart filled.
Action	Reset the status at the verification service and order immediately, without signing out.
Expected	The order is rejected.
Failed if	The order goes through. The integration then relies on a stored value instead of asking before the order.

B5 · Only affected goods are blocked

Setup	Gate limited to one category, account at status 0.
Action	First order an unrestricted product, then a restricted one.
Expected	The unrestricted product passes, the restricted one does not. A mixed cart is rejected.
Failed if	The mixed cart passes — the gate could then be bypassed by adding an unrestricted item.

C — Behaviour under failure and attack

C1 · An outage blocks rather than allows · blocking criterion

Setup	Account at status 0. Change the API endpoint in the settings to an unreachable address.
Action	Attempt an order.
Expected	The order is rejected. The message refers to a temporary disruption, not a technical error.
Failed if	The order goes through. Disrupting the verification service would then be enough to switch the gate off.

Restore the endpoint afterwards. All later steps need a reachable API again.

C2 · A callback without proof is discarded · blocking criterion

Action	Reproduce a valid callback that sets an existing account to status 2 — but send it without the token header, or with an invalid signature.
Expected	An error response. The account status is unchanged. The log shows rejected.
Failed if	The status changes. Anyone who knows the URL could then verify themselves — and, where coupons depend on it, mint money in a loop.

C3 · No secret, no acceptance

Setup	Clear the token in the settings.
Action	Send a correct callback.
Expected	It is rejected. An integration without a configured secret must accept nothing rather than everything.
Failed if	The callback is processed.

C4 · Repetition does no harm

Action	Send the same valid callback three times in a row.
Expected	One account, one status, one coupon. No duplicates.
Failed if	Multiple accounts or multiple coupons. Verification services retry callbacks on timeout — this happens in production without anyone’s involvement.

C5 · Browser events are not proof · blocking criterion

Action	In the browser console, reproduce the event the widget emits when verification succeeds.
Expected	The display may change briefly; the status on the server must not. A subsequent order is rejected.
Failed if	The status is adopted and the order goes through.

D — Account and sign-in

D1 · Access without a known password

Setup	An account created through a callback.
Action	Open the email that was sent, follow the link, set a password.
Expected	After setting it, the person is signed in. The link works exactly once.
Failed if	The link leads to the shop system’s own login page, or can be used more than once.

D2 · Signing in does not break the flow

Action	Enter a deliberately wrong password on the sign-in page.
Expected	The error appears on the same page. The message does not reveal whether the address is known.
Failed if	A redirect to the shop system’s default login page, or a message such as „unknown user“.

D3 · Signing out ends both sessions

Action	Sign out, then open the verification page again.
Expected	The widget shows registration, not the flow of the previous account.
Failed if	The previous verification flow appears. On a shared computer the next person would see the previous person’s data.

E — Data minimisation

E1 · The shop stores no personal data · blocking criterion

Action	After a complete verification, inspect every additional field stored against the account.
Expected	Identifier, status, timestamp, most recent method. Nothing else.
Failed if	Date of birth, address, ID number or bank details are stored — including when it happens „only for display“.

E2 · The log contains no payloads

Action	Review the log entries and the server log after a run.
Expected	Timestamp, type of event, outcome. No transmitted content, no passwords, no tokens.
Failed if	Full callback bodies appear in the log in clear text.

F — Optional features

Only to be tested where enabled.

F1 · Confirmation code

Expected	No order without a code. After several failed attempts the code becomes invalid. A changed cart requires a new confirmation. An expired code is rejected.
Failed if	The code can be guessed indefinitely, or remains valid after the cart changes.

F2 · Coupon

Expected	Exactly one coupon per person, restricted to the verified address and redeemable once. Deleting and recreating the account does not produce a second one.
Failed if	Multiple issues, or the code can be redeemed with any address.

Acceptance record

To be completed and returned. An integration is accepted when all blocking criteria pass and any remaining deviations are named and justified.

Step	Passed	Note
A1 Widget complete
A2 Account created
A3 Callback arrives
B1 Checkout rejects
B2 Gate without interface
B3 Verified accounts pass
B4 Revocation takes effect
B5 Only affected goods
C1 Outage blocks
C2 Callback without proof
C3 No secret, no acceptance
C4 Repetition does no harm
C5 Browser event is not proof
D1 Access without password
D2 Sign-in does not break
D3 Sign-out ends both
E1 No personal data
E2 Log without payloads
F1 Confirmation code
F2 Coupon

Tested by · Date · System and version · Environment

Submit the record

Notes on running the tests

Why the API steps must not be skipped

B2, C1, C2 and C5 test the same thing from four directions: whether the decision is made on the server. That is precisely where integrations tend to fail — the interface looks right while the check sits in the browser. Clicking through does not reveal it.

Test accounts leave traces

Every run creates an account at the verification service, one in the shop, and possibly a coupon. Delete test accounts in both systems after acceptance, otherwise they block the addresses for later runs.

Retest after every update

An update to the shop system, the theme or a payment module can defeat the gate without anyone touching the integration. Group B takes about ten minutes and belongs in every post-update check.

Only against your own systems

This guide describes tests that create accounts and trigger checkout attempts. Run it only against systems you are responsible for, and only in the test environment.

Testleitfaden für Woocommerce