先说结论：验证码识别 API 标注的“每千次 X 元/美元”只是报价单位，平台不会等攒满 1000 次再结算。多数平台每完成一次任务就从余额里扣一次，单次扣费 = 千次单价 ÷ 1000。主流平台的扣费触发点是“成功返回识别结果”，识别失败或服务端超时一般不扣费，或者把预扣的金额退回来。
需要特别算清楚的是另一件事：平台认定的“成功”，是把 token 或文本答案交给你；目标网站是否接受这个结果，平台通常看不到，也不会据此退款。所以核算预算时，除了看报价，还要看有多少次识别真正让业务流程走完。
一次调用到底扣多少钱
举例：某类验证码报价为 $1.00 / 1K（这是假设价格，不是任何平台的实际报价），那么：
- 每成功识别一次，扣 $0.001
- 一天成功识别 3,000 次，扣 $3.00
- 一个月成功识别 50 万次，扣 $500
在常见的任务式接口中，客户端先提交任务，再轮询结果，比如 createTask 加 getTaskResult 的组合，同时还有一个查询余额的接口。按行业惯例，轮询结果和查询余额本身不单独收费，费用只在任务产出结果时扣除。不过各家的规则由自己决定，正式接入前应该做一次小流量调用，然后对照账单流水，确认轮询次数有没有被计入费用。
什么情况扣费，什么情况不扣
主流云端识别平台大致按下面的规则处理：
- 成功返回 token 或文本答案：扣费。
- 服务端识别超时、无法识别、返回错误状态：不扣费，或者自动退回预扣额度。
- 请求参数错误、任务被拒绝创建：通常不会进入识别流程，也就不产生识别费用。具体按各平台的错误码说明执行。
扣费的实现方式有两种。一种是创建任务时先预扣，失败后退回；另一种是成功后才扣。两种做法最后的净费用一样，但对账时余额会有短暂波动。因此核算成本时，应该以余额流水或账单明细为准。只数“创建了多少个任务”会把失败任务也算进去，只数“收到多少个 token”又看不出退款是否到账。
最容易算错的一点：API 成功不等于业务通过
一次验证码处理可以分成三个结果，它们是逐层递减的：
- API 返回结果：平台计费到这一步为止。
- 目标站点接受结果：token 提交后通过校验。
- 业务完成：页面拿到了你需要的数据，或者测试流程跑通了。
下面这些情况里，第 1 步已经成功并扣费，第 2 步却失败了：
- IP 或指纹不一致：求解时使用的环境和实际提交请求的浏览器环境对不上。Cloudflare 整页 Challenge 下发的 cf_clearance 与请求 IP 和环境相关，换了代理就可能失效。Turnstile 组件和整页 Challenge 是两种不同的机制，区别可以参考 Turnstile 和 5 秒盾有什么区别。
- reCAPTCHA v3 分数不够：目标站可能要求 0.7 或 0.9 以上的分数。低分 token 虽然成功返回，校验时仍会被拒。v3 的工作机制可以参考 reCAPTCHA 的工作原理与自动化链路。
- 会话过期或 token 过期：拿到结果后等太久才提交，页面会话或 token 的有效期已经过了。
- 任务类型选错：例如把 Enterprise 版本当作普通版本提交。平台照常返回结果，目标站却不认。
以上失败不一定都是识别服务的问题，也不一定都是 IP 的问题，需要结合日志逐项排查。从成本角度看，这些都是“已扣费但没用上”的调用。对自动化团队来说，它们往往是有效单价高于报价的主要原因。
为什么不同验证码类型价格差很多
“按千次计费”并不代表所有类型同一个价格。不同类型消耗的算力、交互复杂度和风控难度不同，单价也不同。2026 年初几篇第三方评测文章给出的行业参考区间如下，仅用来理解价格量级，不能当作任何平台的报价：
- 简单图形或文字 OCR：约 $0.5–1.0 / 1K
- reCAPTCHA v2/v3 等常见 token 类型：约 $0.8–2.0 / 1K
- Cloudflare Turnstile/Challenge、GeeTest v4、DataDome、Arkose/FunCaptcha 等复杂类型：约 $1.2–3.0+ / 1K
比较价格时，要拿同一种验证码类型、同一币种、同一计费单位去比。平台首页标的“最低价”一般对应最便宜的类型，不能拿它乘以你全部的调用量。如果业务里混合了多种验证码，应该分类型统计调用量，再分别乘以对应的单价。
阶梯优惠和其他计费方式
识别服务常见的收费方式有三种：
- 预充值、按量扣费：用多少扣多少，调用规模上去后享受阶梯单价。适合调用量有波动的数据采集、CI 回归和突发任务，也是目前最常见的方式。
- 并发线程包月：按同时处理的任务数收费。适合调用量大且全天分布均匀的场景。如果调用量低或集中在某几个时段，平均单价反而偏高。
- 本地或离线买断授权：前期一次性付费，之后的部署、维护和更新由自己负责。
评估阶梯优惠时，要确认档位按什么统计：是充值金额还是月度成功次数，是否分类型单独计算，以及档位多久重置一次。这些细节会直接影响你实际能拿到哪一档价格。
按业务成功次数计算真实有效单价
预算里建议用这个指标：
有效单价 = 该类型的总扣费 ÷ 目标站点接受（或业务完成）的次数 × 1000
算例（全部为假设数据）：
- 报价 $1.00 / 1K，本月成功返回 50 万次，扣费 $500
- 其中 45 万次被目标站接受，接受率 90%
- 有效单价 = 500 ÷ 450,000 × 1000 ≈ $1.11 / 1K
再假设客户端的超时设置过短，有 10% 的验证码被重复提交了一次，而且两次都成功返回：
- 实际成功返回并扣费的次数变成 55 万次，扣费 $550
- 有效结果仍然只有 45 万次
- 有效单价升到约 $1.22 / 1K
可以看到，报价只差几分钱的两家平台，如果接受率差几个百分点，或者某一边的重试逻辑有问题，最终成本的差距会比报价差距大得多。
这些工程问题会放大账单
- 重试风暴：客户端等待时间比平均识别耗时还短，于是放弃旧任务、又提交新任务。旧任务如果随后成功，照样会扣费。建议一个验证码实例只绑定一个任务 ID，按任务状态决定是继续轮询还是重新提交，并限制最大重试次数。轮询间隔、超时和异常处理的写法可以参考 Python 验证码识别 API 接入。
- 只看成功率，不记录拒绝原因：请求日志里至少应记下任务 ID、验证码类型、识别耗时、提交时间和目标站返回结果，否则分不清钱花在了哪一层。
- v3 分数达不到阈值：先确认目标站需要的分数和 action 参数，再批量调用。
- 自备代理不稳定：使用带代理的任务类型时，如果代理本身断线或被封，任务可能失败，或者返回的结果不可用。代理的成本和稳定性应该和识别费用一起核算。
- 拿到结果后提交太慢：token 有有效期。求解、提交、下一步操作之间的时间间隔要控制好。
比较报价时逐项确认
- 你要用的每种验证码类型各自的千次单价，以及币种。
- 计费触发点是“返回结果”还是其他口径；轮询和查询余额是否收费。
- 哪些失败会退款，退款是自动完成还是需要申请，在账单里怎么显示。
- 阶梯优惠的统计方式和档位。
- 在同一类型、同一时段、同一环境下，小流量测出的目标站接受率和延迟分位数（P50、P95 分开记录）。
完整的选型步骤可以参考 验证码识别 API 怎么选。如果打算从现有平台迁移，价格之外还要逐个任务核对字段和账单口径，见 2Captcha 替代方案怎么选。
NexCaptcha 的计费口径
NexCaptcha 官网的公开说明是：按千次成功识别计费，识别失败退款，按用量提供阶梯优惠，并提供测试额度。官网首页列出了 33 种报价类型，不同类型分别定价，首页的最低价不适用于所有类型。具体的阶梯档位和各类型的详细价格表，以官网当前展示的内容和实际账单为准；本文不替平台推测折扣比例或退款时限。
比较合适的做法是：先用测试额度，针对你自己的一两种主要验证码类型跑一轮小流量测试，记录扣费次数、退款情况和目标站接受率，按上面的公式算出有效单价，再决定充值多少。验证码类型、价格和联系工程师的入口都在 NexCaptcha 官网首页。
