In der QA für Ticketing-Plattformen ist selten das Lösen des CAPTCHAs die eigentliche Hürde – schwierig ist der Nachweis, dass ein einmal gelöstes Token den Sprung von der Warteschlange zum Checkout übersteht, ohne dass die Sitzung abreißt. Genau diese Übergänge prüfen Sie am verlässlichsten in einer eigenen Staging-Umgebung, lange bevor der Vorverkauf startet. Dieser Leitfaden zeigt, wie Sie reCAPTCHA v2, reCAPTCHA v3 und Cloudflare Turnstile in Ihren eigenen Ticketing-Flows testen – vom Warteschlangeneintritt bis zum Kaufabschluss.
Anwendungsbereich: Dieser Leitfaden behandelt Integrations- und QA-Tests für Ticketing-Flows, die Sie selbst betreiben oder für die ein ausdrückliches Testmandat vorliegt. Sämtliche Beispiele laufen gegen Staging-Umgebungen, Testveranstaltungen und Fake-Zahlungstoken. Eine Anleitung zum automatisierten Ticketkauf auf öffentlichen Plattformen ist nicht Teil dieses Artikels.
CAPTCHA-Typen im Ticketing-Checkout und ihre Lösungszeiten
Ticketing-Seiten setzen CAPTCHAs an genau den Stellen ein, an denen die Last am höchsten ist: beim Warteschlangeneintritt und im Checkout. Diese Typen begegnen Ihnen dabei am häufigsten:
| CAPTCHA-Typ | Typischer Einsatz | Lösungszeit (Richtwert) |
|---|---|---|
| reCAPTCHA v2 | Warteschlangeneintritt, Checkout | 8–20 Sekunden |
| reCAPTCHA v3 | Score-basierte Veranstaltungsseiten | 5–15 Sekunden |
| Cloudflare Turnstile | Seitenzugriff, Checkout | 2–8 Sekunden |
hCaptcha taucht auf einigen Ticketing-Seiten ebenfalls auf, gehört jedoch nicht zu den von CaptchaAI unterstützten Typen. Richten Sie Ihre Testfälle deshalb auf reCAPTCHA und Turnstile aus. reCAPTCHA v3 verdient dabei besondere Aufmerksamkeit: Es liefert einen Score statt einer klaren Bestanden-Antwort, weshalb Ihre serverseitige Schwellenwert-Prüfung genauso zum Testumfang gehört wie das Lösen selbst.
Was Sie im Warteschlangen- und Checkout-Flow prüfen sollten
Eine fehlerhafte CAPTCHA-Integration blockiert legitime Nutzer und drückt die Konversionsrate. Diese fünf Punkte decken die häufigsten Bruchstellen ab:
- Warteschlangen-CAPTCHA: Wird das CAPTCHA beim Warteschlangeneintritt korrekt angezeigt und verarbeitet?
- Token-Weitergabe: Wird das Token korrekt an den Warteschlangen-Service übergeben?
- Sitzungskontinuität: Bleibt die Sitzung von der Warteschlange bis zur Bezahlung erhalten?
- Checkout-CAPTCHA: Wird das Token beim Zahlungsschritt korrekt verarbeitet?
- Fehlermeldungen: Erhält der Tester bei CAPTCHA-Fehlschlägen klare Fehlermeldungen?
Beispiel: Warteschlangen- bis Checkout-Flow in Staging prüfen
Das folgende Skript spielt den kompletten Weg vom Warteschlangeneintritt bis zum Kaufabschluss gegen eine Staging-Veranstaltung durch. Es löst pro Schritt ein frisches Token und verwendet durchgehend dieselbe Session. Der Ablauf umfasst drei Schritte:
- Warteschlangeneintritt mit einem frisch gelösten reCAPTCHA-Token.
- Übergabe der Warteschlangen-ID an den Checkout innerhalb derselben Session.
- Kaufabschluss mit Testticket und Fake-Zahlungstoken.
import requests
import time
CAPTCHAAI_KEY = "YOUR_API_KEY"
CAPTCHAAI_URL = "https://ocr.captchaai.com"
def solve_captcha(method, sitekey, pageurl):
# Generischer CAPTCHA-Client fuer Ticketing-QA
data = {
"key": CAPTCHAAI_KEY,
"method": method,
"googlekey": sitekey,
"pageurl": pageurl,
"json": 1,
}
resp = requests.post(f"{CAPTCHAAI_URL}/in.php", data=data, timeout=30)
resp.raise_for_status()
task_id = resp.json()["request"]
for _ in range(30):
time.sleep(5)
result = requests.get(
f"{CAPTCHAAI_URL}/res.php",
params={"key": CAPTCHAAI_KEY, "action": "get", "id": task_id, "json": 1},
timeout=30,
)
result.raise_for_status()
data_r = result.json()
if data_r.get("status") == 1:
return data_r["request"]
raise TimeoutError("CAPTCHA-Lösungszeit abgelaufen")
def test_queue_entry(session):
# Warteschlangeneintritt in eigener Staging-Umgebung testen
queue_url = "https://staging.ticketing.test/event/TEST-EVT-001/queue"
token = solve_captcha(
method="userrecaptcha",
sitekey="6Lc_TEST_QUEUE_SITEKEY",
pageurl=queue_url,
)
resp = session.post(
queue_url,
data={"g-recaptcha-response": token},
timeout=30,
)
resp.raise_for_status()
queue_id = resp.json().get("queue_id")
print(f" Warteschlangen-ID erhalten: {queue_id}")
return queue_id
def test_checkout(session, queue_id):
# Checkout-Schritt in eigener Staging-Umgebung testen
checkout_url = "https://staging.ticketing.test/checkout"
token = solve_captcha(
method="userrecaptcha",
sitekey="6Lc_TEST_CHECKOUT_SITEKEY",
pageurl=checkout_url,
)
resp = session.post(
checkout_url,
data={
"g-recaptcha-response": token,
"queue_id": queue_id,
"ticket_id": "TEST-TICKET-001", # Testticket (keine echte Veranstaltung)
"payment_token": "tok_test_example", # Fake-Zahlungstoken
},
timeout=30,
)
resp.raise_for_status()
assert resp.status_code == 200, f"Checkout fehlgeschlagen: {resp.status_code}"
print(f" Checkout-Status: {resp.status_code} — bestanden")
def run_ticketing_qa_test():
# Vollstaendigen Warteschlangen-bis-Checkout-Flow in Staging testen
session = requests.Session()
print("Starte Ticketing-QA-Test in Staging-Umgebung...")
queue_id = test_queue_entry(session)
test_checkout(session, queue_id)
print("QA-Test bestanden: Vollstaendiger Warteschlangen-Checkout-Flow erfolgreich")
if __name__ == "__main__":
run_ticketing_qa_test()
Ein regionaler Festival-Veranstalter, der seinen Ticketshop selbst auf Infrastruktur bei Hetzner oder IONOS betreibt, kann diesen Flow gegen eine Testveranstaltung durchspielen, lange bevor der eigentliche Vorverkauf beginnt – und so Regressionen im CAPTCHA-Handling vor dem Ansturm ausschließen.
Sitzungskontinuität zwischen Warteschlange und Checkout absichern
Der häufigste Integrationsfehler ist nicht ein fehlgeschlagenes CAPTCHA, sondern eine Sitzung, die zwischen Warteschlange und Checkout abreißt. Der folgende Test stellt sicher, dass die Session-Cookies über alle Schritte hinweg erhalten bleiben:
import requests
def test_session_continuity():
# Pruefen, ob Session-Cookies korrekt durch den Flow weitergegeben werden
session = requests.Session()
# Schritt 1: Warteschlange betreten
session.get("https://staging.ticketing.test/event/TEST-EVT-001", timeout=30)
initial_cookies = dict(session.cookies)
print(f"Cookies nach Schritt 1: {list(initial_cookies.keys())}")
# Schritt 2: CAPTCHA loesen und Token uebermitteln
# (hier CaptchaAI-Lösung einfügen)
# Schritt 3: Checkout aufrufen
session.get("https://staging.ticketing.test/checkout", timeout=30)
checkout_cookies = dict(session.cookies)
# Sicherstellen, dass Session-Cookies noch vorhanden sind
for key in initial_cookies:
assert key in checkout_cookies, f"Cookie '{key}' fehlt nach Schritt 3"
print("Sitzungskontinuitaet: Alle Cookies bleiben erhalten")
Lassen Sie diesen Test nicht nur einmal, sondern unter simulierter Last laufen: Wenn viele Sitzungen gleichzeitig durch die Warteschlange gehen, treten Cookie- und Token-Probleme deutlich häufiger auf als im Einzeldurchlauf. Protokollieren Sie pro Testlauf, an welchem Schritt ein Token oder Cookie verloren geht – so lässt sich die Bruchstelle eindeutig einer Komponente zuordnen, statt sie später im Livebetrieb zu suchen.
Häufige Fehler in Ticketing-CAPTCHA-Integrationen
| Problem | Ursache | Maßnahme |
|---|---|---|
| Warteschlangen-CAPTCHA schlägt fehl | Token abgelaufen | Token erst kurz vor der Übermittlung lösen |
| Sitzung nach Warteschlange ungültig | Session-Cookie fehlt | Cookie-Weitergabe in der Staging-Config prüfen |
| Checkout gibt 403 zurück | Serverseitige Validierung schlägt fehl | Secret-Key und Verifikations-Endpunkt prüfen |
| Zu viele Anfragen | Rate-Limiting im Staging | Anfragen zeitlich verteilen |
| Zahlung nach CAPTCHA abgelehnt | Kein CAPTCHA-Problem | Zahlungskonfiguration separat prüfen |
Häufige Fragen
Wie stelle ich sicher, dass ein gelöstes Token den Checkout erreicht?
Lösen Sie das Token erst unmittelbar vor dem jeweiligen Schritt und übermitteln Sie es innerhalb desselben Session-Objekts. Token verfallen nach ca. 120 Sekunden; ein zu früh gelöstes Token ist beim Kaufabschluss oft schon ungültig.
Warum besteht der Warteschlangen-Schritt, der Checkout-Schritt aber nicht?
Meist liegt es nicht am CAPTCHA selbst. Prüfen Sie zuerst, ob die Session-Cookies vom Warteschlangen- bis zum Checkout-Request erhalten bleiben und ob am Checkout ein anderer Sitekey als in der Warteschlange verwendet wird.
Lässt sich die Ticketing-QA-Suite in eine CI-Pipeline einbinden?
Ja. Die Tests laufen als reine HTTP-Anfragen und eignen sich für GitLab CI oder GitHub Actions. Hinterlegen Sie den API-Schlüssel als geschütztes CI-Secret und lassen Sie die Suite vor jedem Release gegen Ihre Staging-Umgebung laufen.
Muss ich beim Testen von Session-Cookies die DSGVO beachten?
In Staging mit Testdaten ist das Risiko gering, doch IP-Adressen und Session-Kennungen gelten als personenbezogene Daten. Verwenden Sie in Testläufen ausschließlich synthetische Nutzerdaten und keine echten Kundendatensätze.
Verwandte Leitfäden
- CaptchaAI in wenigen Minuten einrichten
- CAPTCHA-QA in autorisierten Testumgebungen
- CAPTCHA-Endpunkte in eigenen Webformularen testen
- CAPTCHA-Tests in der CI-Pipeline automatisieren
Prüfen Sie Ihren Warteschlangen- und Checkout-Flow in Staging – holen Sie sich Ihren CaptchaAI-Schlüssel und lösen Sie das Token in jedem Testschritt.