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

What Gpt-Agreement-Payment actually solves

The repository addresses a narrow reverse-engineering problem: the subscription flow for ChatGPT Plus, Team and Pro is spread across several vendors, and nobody documents how the pieces hand off to each other. DanOps-1/Gpt-Agreement-Payment reconstructs that chain from captured traffic and reimplements it as a runnable client. The README describes the path as Stripe Checkout, then PayPal, GoPay or QRIS, then ChatGPT manual approval, then Codex OAuth with PKCE. The output of a successful run is an OAuth refresh_token.

The intended audience is stated on the repository itself. The README carries a red badge reading CTF / bug bounty, and the caution block restricts use to systems you own, legal CTF events, in-scope assets in an authorised bug bounty programme, and security research. That framing matters more than any feature list. This is a tool for people who want to observe how a payment and identity chain behaves under adversarial conditions, and who can defend that use in writing.

It is not a subscription reseller's toolkit, even though the mechanics could be pointed that way. The README explicitly forbids fraud, payment circumvention, bulk account creation for resale, and use against unauthorised targets. Anyone whose need is simply a cheaper ChatGPT seat is not the audience, and the setup burden described later will not be worth it to them.

The four payment paths and what each one requires

The README documents four entry points, each tied to a different regional or promotional constraint. Team and Plus through a PayPal billing agreement run via pipeline.py --paypal. A Plus path using an OpenAI promotional long link plus PayPal guest checkout runs through scripts/no_card_paypal_plus.py. GoPay Indonesia runs via pipeline.py --gopay and uses Midtrans linking with a GoPay wallet binding, restricted to the IDR region. QRIS runs via pipeline.py --qris and uses Midtrans QRIS with a remote preview and reference polling to settle.

The prerequisites differ per path, and the README is explicit about which are mandatory. A PayPal billing agreement needs a real, loginable PayPal account, or the guest checkout flow, which in turn needs an SMS gateway API key for PayPal signup. GoPay needs a live WhatsApp number and a WhatsApp verification service. All paths need a proxy whose exit sits in the EU, US or Indonesia depending on the chosen route. A Cloudflare zone is optional for catch-all registration addresses, and an Outlook inbox pool is offered as an alternative.

The hardware floor is stated plainly: a Linux machine able to run Camoufox and Playwright, with about 5 GB of disk and 2 GB of memory. A VLM API key compatible with OpenAI is optional for hCaptcha solving, and the README notes that residential or pseudo-residential exits usually do not trigger hCaptcha, with a CLIP fallback when no VLM is configured. A captcha-solving platform key speaking the createTask/getTaskResult protocol is a further optional fallback for browser passive captchas.

Architecture: registration, checkout replay, and the OAuth handoff

The architecture diagram in the README shows a linear pipeline with a fork in the middle. pipeline.py or the web UI starts at CTF-reg/browser_register.py, which uses Camoufox against Turnstile. From there, CTF-pay/card.py replays Stripe Checkout. The flow then branches into one of three payment paths: Camoufox or Node RPA for the PayPal billing agreement, Midtrans linking with WhatsApp OTP for GoPay, or the QRIS code with remote preview for QRIS.

All three branches converge on Stripe polling until state=succeeded. After that, a second Camoufox login performs the Codex OAuth with PKCE, and the resulting refresh_token lands in output/webui.db, a SQLite file. The README points to docs/architecture.md for the subsystem breakdown and protocol details, and that document is where the real value of the repository sits.

The concurrency design is the most interesting engineering choice. webui/backend/parallel_runner.py runs N workers with a phone-lock critical section: workers sharing a phone serialise only the OTP stage through an advisory lock, while everything before and after OTP runs in parallel. Database atomic claims and placeholder INSERTs prevent two workers from grabbing the same promo link or the same inventory mailbox. The front end takes a phone pool of M rows and a concurrency count N that may exceed M, mapping workers to phones by i % M. That is a deliberate trade: throughput comes from parallelising the slow browser stages, while the OTP window, which is the part that breaks under races, stays serialised.

Installing it and running the web UI wizard

The README recommends the web UI configuration wizard as the new-user path, claiming it compresses one to three hours of manual setup to roughly fifteen minutes. It is a 14-step wizard with live preflight checks and a run controller that streams logs over SSE, and it generates two config files: CTF-pay/config.auto.json and CTF-reg/config.paypal-proxy.json.

The fastest route is Docker. The repository ships a Dockerfile with a multi-stage build (Node for the front end, Ubuntu 24.04 for the runtime) and a docker-compose.yml that bakes in Playwright Chromium and Firefox, Camoufox, a gost SOCKS5 relay and Node QuickJS. The compose file bind mounts the whole repository, so the host git working tree stays the source of truth and Python edits take effect after a restart rather than a rebuild.

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

After the container is up, the first visit redirects to /setup to create an administrator account. The compose file binds the port to 127.0.0.1 only, and the README warns against exposing 0.0.0.0 directly because there is no authentication layer in front. Public access is meant to go through an nginx reverse proxy with HTTPS, documented in webui/README.md.

If you would rather not use Docker, the manual path is three steps. Backend dependencies come from webui/requirements.txt, the front end is built once with pnpm, and the server starts as a Python module.

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

The standalone installation for the core pipeline is a separate list of packages, and the hCaptcha solver's machine-learning dependencies are deliberately kept out of it. The README suggests a dedicated virtual environment for torch, transformers, opencv-python, pillow and numpy, at roughly 4 GB.

pip install requests curl_cffi playwright camoufox browserforge mitmproxy pybase64
playwright install firefox
camoufox fetch
python -m venv ~/.venvs/ctfml
~/.venvs/ctfml/bin/pip install torch transformers opencv-python pillow numpy

Configuration starts by copying the example files, for instance CTF-pay/config.paypal.example.json to CTF-pay/config.paypal.json. The compose entrypoint bootstraps these from the .example.json templates automatically, and the container reads them live through the bind mount, so a docker compose restart picks up edits. Runtime tuning lives in environment variables on the service: WEBUI_DATA_DIR points at /app/output, OTP_TIMEOUT defaults to "60", and OPENAI_SENTINEL_REQUIRE_QUICKJS is set to "1" with OPENAI_SENTINEL_NODE_PATH at /usr/local/bin/node. The comment in the compose file explains the 60-second OTP timeout: the Cloudflare Email to Worker to KV path measures about 0.3 seconds end to end, so 60 seconds is a large margin, and failing fast lets the outer loop retry with a new persona and IP when OpenAI's honeypot branch never sends the mail.

The hCaptcha solver and the anti-fraud research notes

CTF-pay/hcaptcha_auto_solver.py is roughly 4000 lines and the README says it is usable independently of the payment pipeline. Its design is a VLM primary path, a CLIP and OpenCV heuristic fallback, and Playwright synthesis of human-like actions, covering twelve known hCaptcha challenge types. Keeping it standalone is a sensible decision: the solver has no dependency on Stripe or PayPal, so it can be evaluated on its own terms.

The empirical anti-fraud material is the part most likely to be quoted elsewhere. docs/anti-fraud-research.md reports exact string-level IP fingerprinting, delayed bans correlated across batches, and a separation between a probe layer and a ban layer. The README summarises the headline number as roughly 2 percent 24-hour survival across a 45-account sample, with a corrected model. That figure is a self-reported observation from the authors' own runs, not an independent measurement, and the README does not describe the sampling methodology in the summary. Treat it as a hypothesis worth reading rather than a benchmark.

The daemon is the operational counterpart. pipeline.py::daemon() is described as a twelve-way self-healing loop: 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 reclamation, a gost relay watchdog, and automatic DataDome slider dragging. The stated design goal is unattended operation for weeks. That is an ambitious claim, and the README does not publish an uptime figure to support it, so the honest reading is that the daemon exists and is structured for long runs, not that it has been proven to survive them.

Where Gpt-Agreement-Payment is the wrong tool

The README is unusually direct about this. It states that the project is not plug-and-play, that a first complete run usually takes one to three hours of configuration, and that the code is research-oriented, ordered by protocol stage, and does not chase maximum readability. Anyone expecting a supported integration should stop reading at that sentence.

The dependency surface is the practical failure mode. A working PayPal account or the guest checkout route, a region-correct proxy, a Linux host with browser automation, and for some paths an SMS gateway or a WhatsApp verification service all have to be in place before the first successful run. If any one of them is missing, the pipeline fails partway through a multi-stage flow, and the README does not document a rollback procedure for a run that dies after Stripe Checkout has already been replayed. That gap is worth knowing before you point it at anything that costs money.

The hCaptcha solver is also not a general-purpose component. It targets twelve known challenge types, and the README's own note says residential exits usually do not trigger hCaptcha at all, which means the solver's value depends heavily on the network you run from. On a datacentre exit you may need the VLM path, and without a VLM key you fall back to CLIP heuristics whose accuracy the README does not quantify. Finally, if your goal is simply to subscribe to ChatGPT, this is the wrong project entirely: the setup cost exceeds the task, and the licence terms in NOTICE are written for researchers, not customers.

How it compares to mitmproxy and Playwright used directly

The closest alternative is not another subscription tool. It is assembling the same work yourself from mitmproxy for traffic capture and Playwright for browser automation, which is what the project's own dependencies suggest. The difference is in what has already been decided. With raw mitmproxy and Playwright you capture the Stripe Checkout to PayPal to OAuth chain and write the replay logic yourself, including the state machine around Stripe polling and the PKCE handshake on the second login.

Gpt-Agreement-Payment encodes those decisions already: the branch structure for three payment rails, the convergence on state=succeeded, the refresh_token persistence into SQLite, and the phone-lock OTP critical section in parallel_runner.py. That last piece is the one hardest to reproduce quickly, because getting OTP concurrency right requires understanding which stage is race-sensitive. The cost of taking the pre-built path is that you inherit the project's opinions, its configuration file layout, and its research-grade code organisation.

A second comparison point is the anti-fraud documentation. If your interest is how IP fingerprinting and batch-correlated bans behave, the research notes are the asset, and you could read docs/anti-fraud-research.md without running any of the pipeline code. That is arguably the highest-value, lowest-risk way to use this repository: consume the protocol write-up and the empirical notes, and treat the executable parts as a reference implementation to check your own understanding against.

Licence, maintenance and upgrade cost

The code is MIT licensed, and the repository carries a LICENSE file at the top level. MIT is permissive, so the usual obligations apply: retain the copyright notice and the licence text in redistributions. That is the extent of what can be said here, and it is not legal advice.

The NOTICE file is separate from the licence and carries more weight in practice. The README states that using the project means accepting all terms in NOTICE, that it is provided AS IS with no warranty, and that the maintainers accept no liability. The caution block lists the prohibited uses. Read NOTICE before you clone, because it constrains behaviour rather than just attribution.

Maintenance is a live question rather than a settled one. The repository is not archived, and the last push was on 2026-06-15. No releases were retrieved, so there is no tagged version to pin against; you are tracking main. The Dockerfile builds from ubuntu:24.04 and node:20-bookworm-slim, and the compose file notes that a full upgrade means docker compose build --no-cache followed by docker compose up -d, which pulls new base images and Python packages. Because the repository is bind mounted rather than copied into the image, a git pull changes the running code after a restart, which lowers upgrade friction but also means an upstream commit can change behaviour without any version boundary to notice. Pin a commit hash if you need reproducibility.

Editorial conclusion

Adopt it if you are doing authorised security research or a CTF and you already have a PayPal account, a region-locked proxy and a Linux box that can run Camoufox, because the protocol detail in docs/architecture.md is the actual deliverable. Do not adopt it if you want a subscription automation product: the README states the first end-to-end run usually takes one to three hours of configuration, and the anti-fraud sample it publishes records roughly 2 percent 24-hour survival across 45 accounts. Before anything else, read the NOTICE file, since the README says using the project means accepting its terms, and confirm your target is inside an authorised bug bounty scope.

Frequently asked questions

Official sources

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