Solution
Your own staging flow sits behind the same challenge your users see. Solve it in CI so the suite runs unattended instead of being skipped.
Who this is for
QA engineers, SDETs and platform teams running end-to-end suites against staging and production systems they own. The suite runs on every merge and again overnight, and someone triages the red builds in the morning. They are testing their own application, so the target site’s terms are their own terms.
The problem
Signup and checkout are the most business-critical paths and the only ones behind a challenge, so they are the first specs to get marked skip. Turning the captcha off in staging means the suite stops testing what ships. Teams want the real widget solved inside the pipeline with a fixed deadline, so a slow solve degrades into a retry rather than a red build.
[ 02 ]Challenges you will hit
Works with
[ 04 ]Questions about this one
Yes, and it is the case the CI plan was built around: you own or operate the system under test. Keep the key scoped to your CI runners so it does not leak into other work.
Put a deadline on the solve call and fall back to a retry. Each type page publishes its P50 and P95, so the step timeout can be sized from measured numbers rather than a guess.
Yes, including Google’s published test keys. Pass the staging page URL and the sitekey exactly as they appear in the DOM.
Yes, as long as the runner has outbound HTTPS to one hostname. No inbound connection is needed; results are polled, or delivered to a callback URL inside your network.
Create a key, paste it into the sample above, and watch a real token come back. No card, no sales call.
