Gpt-Agreement-Payment: a protocol replay toolkit for ChatGPT subscription flows

The problem Gpt-Agreement-Payment actually attacks

The project treats a ChatGPT subscription as a protocol, not as a web page. Its README describes the chain as Stripe Checkout, then PayPal, GoPay or QRIS, then ChatGPT manual approval, then Codex OAuth with PKCE. Each arrow in that chain is an HTTP conversation between a browser, a payment processor and OpenAI, and each one has state that has to be carried forward correctly. The toolkit reconstructs those conversations from captured traffic and reimplements them as a runnable client, so the whole sequence can be driven from a command instead of a browser session.

The audience is narrow and the README says so. The use badge points at CTF and bug bounty work, and the caution block restricts use to systems you own, legal CTF targets, authorised in-scope bug bounty assets and security research. If you are a payments engineer curious about how subscription provisioning looks end to end, the architecture document is the interesting part. If you want a cheaper ChatGPT plan, this is the wrong repository, and the README's own survival numbers are the reason.

Four payment paths and the state machine behind them

There are four entry points. `pipeline.py --paypal` runs Stripe Checkout into a PayPal billing agreement and then ChatGPT manual approval. `scripts/no_card_paypal_plus.py` takes an OpenAI promo campaign long link through PayPal guest checkout to complete the same billing agreement. `pipeline.py --gopay` uses Midtrans linking with a GoPay wallet bind for the IDR region, and `pipeline.py --qris` uses Midtrans QRIS with remote preview plus reference polling for settlement. All four converge on the same Stripe poll for `state=succeeded`, and after that a second Camoufox login performs the Codex OAuth with PKCE exchange. The output is a `refresh_token` written into `output/webui.db`, a SQLite file.

The concurrency model is the part worth studying. `webui/backend/parallel_runner.py` runs N workers but serialises the OTP stage per phone number with an advisory lock, so pre-OTP and post-OTP work stays parallel while only the code-entry critical section is exclusive. A database atomic claim plus a placeholder INSERT prevents two workers from taking the same promo link or the same inventory mailbox. The frontend maps workers onto a phone pool of M rows by `i % M`, which means N can exceed M. That is a deliberate design: phones are the scarce, rate-limited resource, and everything else can be widened.

Installing it and reaching the webui setup wizard

The repository ships a multi-stage `Dockerfile` and a `docker-compose.yml`, and the README calls Docker the fastest path. The compose file bind-mounts the whole repository into the container, so the host git working tree stays the source of truth and a Python edit only needs a restart. The default port binding is `127.0.0.1:8765`; the compose comments say that exposing `0.0.0.0` directly is not advised because there is no authentication layer in front.

git clone https://github.com/DanOps-1/Gpt-Agreement-Payment
cd Gpt-Agreement-Payment
docker compose up -d --build
# default: 127.0.0.1:8765, first visit redirects to /setup

After the build finishes, open `http://127.0.0.1:8765/` in a browser. According to the README, the first visit redirects to `/setup`, where you create the administrator account. From there the 14-step wizard with live preflight checks generates two configuration files, `CTF-pay/config.auto.json` and `CTF-reg/config.paypal-proxy.json`, and the README claims this replaces roughly 1 to 3 hours of manual configuration with about 15 minutes.

If you prefer to skip Docker, the manual path installs the Python dependencies, builds the frontend once, and starts the server module. The README lists the runtime packages as requests, curl_cffi, playwright, camoufox, browserforge, mitmproxy and pybase64, followed by the Firefox browser install and the Camoufox fetch step.

pip install -r webui/requirements.txt
cd webui/frontend && pnpm i && pnpm build && cd ../..
python -m webui.server

The hCaptcha solver's machine learning dependencies are separate and the README suggests a dedicated virtual environment because torch, transformers, opencv-python, pillow and numpy come to roughly 4 GB. The README notes that residential or pseudo-residential egress often does not trigger hCaptcha at all, and that without a VLM key the solver falls back to CLIP heuristics.

What the hCaptcha solver does and where it stops

`CTF-pay/hcaptcha_auto_solver.py` is described as roughly 4000 lines and usable on its own. Its primary path is a vision language model, with a CLIP and OpenCV heuristic fallback and Playwright synthesis of human-like pointer movement, covering 12 known hCaptcha challenge types. The README also mentions an optional third-party captcha service compatible with the createTask and getTaskResult protocol as a fallback for browser passive captcha.

The honest limitation is that this is a solver, not a guarantee. The README positions the VLM key as optional and explicitly ties the heuristic fallback to whether your egress looks residential, which means the solver's success rate is coupled to the network path rather than being a fixed property of the code. If your target's captcha provider rotates challenge types faster than the 12 documented ones, the fallback chain degrades to CLIP matching and you should expect failures rather than a clean error. Nothing in the README documents a benchmark for the solver, so treat any accuracy expectation as unverified.

The anti-fraud measurements are the most useful artefact

`docs/anti-fraud-research.md` is where the project stops being a script collection. The README summarises its findings as IP-level exact string fingerprinting, delayed batch-correlated bans, and a separation between a probe layer and a ban layer. The headline sample is 45 accounts with roughly 2 percent survival over 24 hours, and the README says the document includes a corrected model.

That number is the single most important thing on the page, because it reframes the whole toolkit. A pipeline that produces a working `refresh_token` in about 5 minutes, or 2 tokens in about 3 minutes with two workers on one phone, is not the same as a pipeline that produces accounts that still exist the next day. The gap between those two statements is the actual subject of the research document. If you are evaluating this repository for anything other than research, read that file before you read the install instructions.

The twelve-way daemon and its real prerequisites

`pipeline.py::daemon()` is described as a self-healing loop with twelve mechanisms, including automatic IP rotation through the Webshare API with a fallback to a cached `/tmp/gost_last.json` when Webshare is unstable, Cloudflare DNS quota cleanup, tmpfs orphan collection, a gost relay watchdog and automatic DataDome slider dragging. The stated design goal is unattended operation for weeks.

The prerequisite list is what makes that goal expensive. The README requires a real, loginnable PayPal account or the guest checkout protocol flow, a proxy whose egress sits in EU, US or ID depending on the payment path, optionally a Cloudflare zone for catch-all registration mailboxes or an Outlook code pool, and a Linux machine with about 5 GB of disk and 2 GB of memory for Camoufox and Playwright. PayPal guest checkout additionally needs an SMS gateway API key, and GoPay needs a live WhatsApp number plus a WhatsApp receiving service. The compose file raises `shm_size` to 1 GB because Firefox crashes with the 64 MB default, and sets `OTP_TIMEOUT` to 60 seconds with the comment that this is still roughly 200 times the measured end-to-end latency of the Cloudflare Email to Worker to KV path. That is a specific, checkable claim, and it is the kind of detail the rest of the documentation should have more of.

Alternatives and the difference in approach

The closest alternative for the capture side is mitmproxy, which the project itself lists as a dependency. mitmproxy is a general interception proxy: you write addons, inspect flows and replay requests by hand. Gpt-Agreement-Payment is the opposite shape, a fixed, opinionated client for one specific multi-stage subscription flow, with the state machine and the OTP locking already built. If you need to understand an unfamiliar flow, mitmproxy is the better tool because it makes no assumptions. If you already know the flow and want it executed repeatedly with concurrency, the fixed client is the point.

For browser automation, Playwright alone is the general option, and Camoufox is the anti-detection Firefox build this project layers on top. Playwright gives you a documented, stable API and a large ecosystem; Camoufox trades that for fingerprint control, which is exactly the trade this project needs and exactly why it is harder to install and debug. Neither is a substitute for the other, and choosing Camoufox means accepting that your debugging surface is a patched browser rather than the upstream one.

Licence, maintenance and what upgrading costs

The repository is MIT licensed, and the README carries a separate `NOTICE` file whose terms it says you accept by using the project. MIT covers the code; the NOTICE covers acceptable use, and it prohibits fraud, payment circumvention, bulk account creation for resale, third-party terms of service violations and unauthorised targets. Those are two different documents doing two different jobs, and the NOTICE is the one that constrains what you may do with the output. This is a description of what the files say, not legal advice.

The last push to the default branch was on 2026-06-15, which is more than six months before today, so the repository is not being actively developed at the moment. There are no retrieved releases, which means upgrades happen by pulling the default branch. The Dockerfile is multi-stage and the compose file bind-mounts the repository, so a `git pull` followed by `docker compose restart webui` is the routine path for Python changes, while frontend changes need a rebuild inside the container. The Dockerfile comments note that Node is copied from the `frontend-builder` stage rather than installed from apt, specifically to avoid version drift, so a base image bump is where upgrade risk concentrates. `docker compose build --no-cache && docker compose up -d` is the documented full rebuild.

Editorial conclusion

Adopt it only if you are doing authorised security research, a CTF, or an in-scope bug bounty, and you already have the PayPal account, the EU/US/ID proxy and the Linux host the README lists. Do not adopt it if you want a cheaper ChatGPT subscription or an unattended account factory: the README itself reports roughly 2 percent 24-hour survival across 45 accounts, and the NOTICE forbids fraud, payment circumvention and bulk account resale. Before running anything, read NOTICE and docs/anti-fraud-research.md, then confirm your target's scope and your payment path's region lock.

Frequently asked questions

Official sources

1. DanOps-1/Gpt-Agreement-Payment on GitHub
2. Issues
3. License: MIT
4. README