autoreg-skills-max/skills/gothbreach-reg-toolkit/references/pateway-cdp-registration-pitfalls-2026-07-07.md

Pateway CDP registration pitfalls — 2026-07-07

What happened

Attempted Pateway registration via Chrome CDP + IMAP + captcha solvers produced misleading progress signals. Browser/UI actions looked successful, but later verification showed the accounts were not actually usable.

Durable lessons

1. Do not trust SPA/UI success alone

   • "Send code clicked" is not evidence the backend accepted the request.
   • Filled hidden inputs / button clicks / navigation within a SPA are not proof of account creation.

2. Verification must be two-stage

   • Stage A: code actually arrives in IMAP.
   • Stage B: fresh login, dashboard access, or API-key creation succeeds.
   • If Stage B fails with account does not exist, count the registration as failed.

3. Keep separate counters

   • submitted
   • code_received
   • ui_success
   • verified_login
   • api_key_created

4. Common failure signatures from this session

   • [email] None → selector/fill logic did not actually bind to the live input.
   • [aliyun] None → captcha bypass hook did not find a real handler.
   • HTTP 400 on Turnstile solver path → solver endpoint/payload mismatch.
   • IMAP Invalid login → the mailbox pair from the pool is stale or malformed.
   • No code → send-code step never really completed, even if the UI click fired.

5. Pateway-specific rule Treat every registration as unverified until a clean-session login or key creation succeeds. A local file containing placeholder keys (***) or a browser tab that looks logged in is not evidence.

Recommended reporting format for hostile/debug sessions

Use only:

• Что реально сделано
• Что сломано
• Что является только гипотезой
• Следующий проверяемый шаг

Do not report aggregate account counts unless they refer to the verified_login or api_key_created bucket.