Pengujian CAPTCHA untuk antrean dan checkout platform tiket di staging

Lingkup aman: Panduan ini hanya berlaku untuk platform tiket milik sendiri atau yang sudah mendapat otorisasi eksplisit untuk diuji di staging dan pra-produksi. Isinya adalah pola diagnostik, pengujian, dan observabilitas untuk integrasi CAPTCHA Anda sendiri — bukan panduan untuk situs pihak ketiga, event publik, atau alur pembelian tanpa izin.

Widget CAPTCHA checkout yang lolos sekali-dua kali di uji manual sering tetap gagal begitu antrean nyata datang — dan tim baru menyadarinya beberapa menit sebelum tiket dibuka ke publik. Panduan ini menunjukkan cara menutup celah tersebut: menguji integrasi CAPTCHA pada antrean dan checkout platform tiket Anda sendiri di staging, memakai event fiktif, kursi uji, dan pembayaran simulasi, jauh sebelum event sungguhan diaktifkan.

Kenapa antrean tiket butuh skenario CAPTCHA yang realistis

Checkout tiket biasanya menumpuk lebih dari satu jenis CAPTCHA di titik yang berbeda: reCAPTCHA v2 atau v3 saat masuk antrean, lalu Cloudflare Turnstile atau reCAPTCHA lagi saat checkout. Jika jalur QA Anda melewati CAPTCHA sama sekali — misalnya di-mock atau dimatikan sementara — tim baru tahu integrasi rapuh saat trafik nyata datang, dan pada saat itu perbaikan sudah terlambat. Menyertakan CAPTCHA yang benar-benar diselesaikan lewat CaptchaAI dalam alur staging menutup gap ini sebelum event live, dengan risiko nol terhadap pembeli maupun inventaris tiket asli.

Lingkup aman: apa yang boleh dan tidak boleh diuji

• Hanya platform tiket milik sendiri, atau yang sudah diberi otorisasi tertulis untuk diuji.
• Event, kursi, tiket, dan token pembayaran yang dipakai semuanya fiktif.
• Validasi berjalan di antrean dan endpoint QA internal — bukan alur yang dipakai pembeli asli.
• Tidak ada pembelian nyata, dan tidak ada interaksi dengan platform tiket pihak ketiga mana pun.

Menyusun antrean QA internal

Replikasi arsitektur antrean produksi Anda apa adanya: pengguna QA masuk ke antrean fiktif di https://staging.example.com/ticketing/queue-test, menerima posisi antrean, lalu diteruskan ke checkout di https://staging.example.com/ticketing/checkout-test begitu slot tersedia. Jika layanan produksi Anda berjalan di region Asia Tenggara — AWS ap-southeast-3 (Jakarta) atau ap-southeast-1 (Singapura), GCP asia-southeast2 — jalankan worker QA dari region yang sama. Angka latensi yang Anda catat jadi lebih dekat ke kondisi nyata, termasuk untuk pengguna dengan koneksi mobile yang kurang stabil, yang di pasar Indonesia bukan kasus minoritas.

Menyiapkan data uji: event, kursi, dan pembayaran fiktif

Definisikan data uji secara eksplisit di kode, bukan menyalin data event nyata. Setiap kursi punya harga dalam sen dan token pembayaran memakai penanda qa_pm_token_demo yang jelas-jelas bukan kredensial produksi:

FAKE_EVENT = {
    'id': 'evt_qa_001',
    'url': 'https://staging.example.com/ticketing/fake-event',
    'seats': [{'row': 'A', 'col': i, 'price_cents': 5000} for i in range(1, 21)],
}
FAKE_PAYMENT = {'token': 'qa_pm_token_demo'}

Mengirim task CAPTCHA ke CaptchaAI dari staging

Fungsi berikut mengirim task reCAPTCHA v2 ke in.php, menyimpan task ID, lalu polling res.php setiap 5 detik sampai statusnya selesai:

import os, requests, time
API_KEY = os.environ['CAPTCHAAI_API_KEY']

def solve_recaptcha_v2(sitekey, pageurl):
    r = requests.post('https://ocr.captchaai.com/in.php', data={
        'key': API_KEY, 'method': 'userrecaptcha',
        'googlekey': sitekey, 'pageurl': pageurl, 'json': 1,
    }).json()
    tid = r['request']
    while True:
        time.sleep(5)
        rr = requests.get('https://ocr.captchaai.com/res.php', params={
            'key': API_KEY, 'action': 'get', 'id': tid, 'json': 1,
        }).json()
        if rr['status'] == 1:
            return rr['request']

Pola yang sama berlaku untuk reCAPTCHA v3 (tambahkan parameter version dan action) maupun untuk method: 'turnstile' — hanya parameter yang berubah, alur kirim-simpan-polling-pakai tetap identik untuk ketiga tipe CAPTCHA yang dibahas di panduan ini.

Memvalidasi token di backend QA

Kirim token yang dikembalikan CaptchaAI ke endpoint pesanan tiket QA internal Anda. Backend memverifikasi token CAPTCHA seperti biasa, mengunci kursi fiktif, dan mengembalikan ID pesanan tiruan. Tidak ada tiket nyata yang pernah diproses di jalur ini — seluruh siklus, dari antrean sampai konfirmasi, tetap berada di staging.

Kriteria pass/fail dan pencatatan hasil uji

Uji dianggap pass jika: token diterima backend, kursi fiktif berhasil dikunci, dan latensi end-to-end berada di bawah ambang internal yang sudah Anda tetapkan. Sebagai referensi ambang yang wajar, reCAPTCHA v3 biasanya selesai di bawah 4 detik dan Cloudflare Turnstile di bawah 10 detik menurut data resmi CaptchaAI — pakai angka ini sebagai baseline, bukan target mutlak, karena kondisi jaringan staging Anda sendiri yang menentukan. Catat setiap nilai per kasus_qa supaya tren regresi terlihat dari waktu ke waktu, bukan cuma di run terakhir.

Troubleshooting pengujian CAPTCHA checkout tiket

Pertanyaan yang sering diajukan

Apa bedanya menguji CAPTCHA di staging dengan menguji di produksi?

Di staging, seluruh data — event, kursi, token pembayaran — fiktif, dan Anda bebas mengulang pengujian berkali-kali tanpa risiko terhadap inventaris tiket nyata. Fokusnya observabilitas dan regresi, bukan validasi transaksi sungguhan.

Apakah pengujian ini boleh diarahkan ke platform tiket pihak ketiga?

Tidak. Panduan ini khusus untuk platform tiket milik sendiri atau yang sudah memberi otorisasi tertulis. Menguji atau mengotomatisasi checkout di platform pihak ketiga tanpa izin berada di luar lingkup aman ini.

CAPTCHA jenis apa saja yang bisa diuji dengan alur ini?

reCAPTCHA v2, reCAPTCHA v3, dan Cloudflare Turnstile — tiga tipe yang paling umum muncul di titik masuk antrean dan checkout tiket. Ketiganya didukung penuh oleh CaptchaAI dengan pola kirim-simpan-polling-pakai yang sama.

Berapa ambang waktu penyelesaian yang wajar untuk uji checkout tiket?

Gunakan SLA resmi CaptchaAI sebagai baseline: reCAPTCHA v3 di bawah 4 detik, Cloudflare Turnstile di bawah 10 detik. Sesuaikan ambang pass/fail internal Anda dengan angka ini plus margin untuk latensi jaringan staging.

Bisakah proses ini dijalankan otomatis di pipeline CI/CD sebelum event diluncurkan?

Bisa. Karena seluruh data bersifat fiktif dan endpoint-nya internal, skrip pengiriman task dan validasi token di atas cocok dijadwalkan sebagai job CI/CD rutin — dijalankan setiap kali ada perubahan pada alur antrean atau checkout, bukan cuma menjelang event besar.

Panduan terkait

• Mulai cepat dengan CaptchaAI
• Pengujian CAPTCHA QA yang terotorisasi
• Menguji endpoint CAPTCHA pada formulir milik sendiri
• Debugging saat tes browser gagal padahal API berhasil
• Cara menyelesaikan reCAPTCHA v2 lewat API
• Cara menyelesaikan Cloudflare Turnstile lewat API
• Cara menyelesaikan GeeTest v3 lewat API

Ambil API key CaptchaAI dan validasi integrasi CAPTCHA checkout tiket Anda sendiri di staging.