打码成本怎么算：计费口径、失败返还与对账方法

打码成本失控通常不是单价贵，而是计费口径没对齐。同一批业务，A 平台按请求计费、B 平台按成功计费，标价看起来一样，月账单能差 40% 以上。

四种常见计费口径

1. 按请求计费：发一次扣一次，失败也扣。适合成功率稳定的场景。
2. 按成功计费：只有识别成功才扣，单价通常高 20%–50%。
3. 按题计费：点选类按「题」而非「次」，一次请求多题时单价翻倍。
4. 预扣 + 返还：先扣后返，返还可能是延迟到账或折算成余额，注意是否能提现。

把公式写清楚

真实单次成本 = 标价 ÷ 有效通过率 × (1 + 重试率)。

举例：标价 0.01 元，有效通过率 85%，平均重试 0.3 次，则真实成本 ≈ 0.0153 元，比标价高 53%。这就是为什么必须先测通过率再谈价格。

失败返还的三个陷阱

• 返还到「赠送余额」而不是可提现余额：等于把钱锁死在平台里。
• 返还延迟 24–72 小时：短期跑量时容易造成余额虚低，被迫追加充值。
• 只对「识别错误」返还，不对「超时」返还：而高峰期超时往往才是失败主因。

一套可执行的日对账方法

1. 业务侧记录每次请求的 request_id、时间、结果、耗时。
2. 每天导出平台账单，按 request_id 关联，统计「平台扣费但业务未成功」的比例。
3. 连续三天比例超过 5%，就找服务商要解释；超过 15%，直接切备用通道。
4. 月底按周汇总成一张表：请求量、成功量、扣费、有效单价、异常扣费。

日请求 120000，成功 101500，扣费 1320 元
有效单价 = 1320 / 101500 ≈ 0.0130 元/次
标价 0.0100 元/次 → 溢价 30%，处于可接受区间

三个降本手段

• 缓存同一验证码：同一张图片重复请求是最常见的浪费。
• 先本地预判：简单的字符型验证码用本地模型先跑一遍，只把失败的上送平台。
• 错峰跑量：把非实时任务挪到凌晨低峰，超时率和单价都更友好。

打码是典型的「按量付费」成本项，能算清楚单次成本，就能算清楚整个项目的盈亏线。