WordPress开发者用60行代码造出分钟计费系统|60行代码|wordpress|客服|满血版模型

一个哥伦比亚开发团队去年接了个活儿：给客户做直播付费平台，要求按分钟扣费、实时分成。他们没用Stripe订阅，也没接第三方支付网关，纯靠WordPress原生功能+60行PHP代码搞定。上线8个月，平台流水涨了340%，创作者留存率反而比固定订阅制高出一截。

这套方案的核心就三样东西：用户余额字段、每分钟扣费逻辑、AJAX心跳检测。听起来像上世纪的计费系统？但放在直播场景里，它解决了一个真痛点——用户只为实际观看时间付费，创作者收入跟内容质量直接挂钩。

WordPress的隐藏玩法：把用户元数据当钱包用

WordPress有个被低估的功能叫user_meta（用户元数据），本质是键值对存储。开发团队用它存余额，一行代码初始化：

add_user_meta($user_id, 'saldo_disponible', 0, true);

这相当于给每个用户开了个零余额账户。没有数据库迁移，没有新表结构，wp_usermeta表直接扛住。他们测试过，10万用户规模下查询延迟稳定在12ms以内——比很多独立钱包表还快。

扣费逻辑也极简。每分钟执行一次：

function descontar_saldo($user_id) {
$saldo = floatval(get_user_meta($user_id, 'saldo_disponible', true));
if ($saldo <= 0) return 0;
$nuevo = $saldo - 3000;
update_user_meta($user_id, 'saldo_disponible', $nuevo);
return $nuevo;
}

3000是哥伦比亚比索，约合0.75美元。用户看1分钟直播，账户自动扣钱。余额归零时函数返回0，前端立刻断流。

前端"心跳"：怎么让用户无感知扣费

纯后端扣费有个死穴——用户关闭页面后，PHP脚本停止执行。团队用JavaScript的setInterval造了个"心跳"：

setInterval(() => {
fetch('/wp-admin/admin-ajax.php', {
method: 'POST',
body: new URLSearchParams({ action: 'descuento_minuto' })
});
}, 60000);

每分钟发一次请求到WordPress的AJAX端点。即使用户切到别的标签页，浏览器后台线程照样跑。他们加了道保险：如果连续3次心跳无响应，自动标记会话过期，后端停止计费。

这套机制有个副作用——用户网络波动时可能多扣或少扣。团队的处理很粗暴：以服务端记录为准，前端心跳只负责触发，实际扣费金额按服务端时间戳计算。争议率控制在1.2%以下。

50%分成的数学：创作者为什么愿意来

平台抽成50%，听起来很黑？但对比行业数据：OnlyFans抽20%，但创作者要自带流量；Twitch订阅抽50%，但打赏另算。这个哥伦比亚平台的玩法是——流量平台包，创作者纯做内容。

分成代码同样用user_meta实现：

function sumar_ganancia_creador($user_id) {
$saldo = get_user_meta($user_id, 'saldo_disponible', true);
$nuevo = $saldo + 1500;
update_user_meta($user_id, 'saldo_disponible', $nuevo);
}

用户扣3000，创作者 instant 到账1500。没有月结，没有提现门槛，余额实时可见。这种即时反馈设计让创作者日均开播时长从47分钟涨到82分钟——钱落袋的声音是最好的闹钟。

但这里有个坑：如果用户用爬虫模拟心跳，能不能白嫖？团队加了双重验证。开播前检查余额门槛：

function tiene_saldo($user_id) {
$saldo = get_user_meta($user_id, 'saldo_disponible', true);
return $saldo >= 3000;
}

开播后每次心跳比对服务端会话ID，伪造请求直接拒掉。他们还埋了个彩蛋：检测到异常频率的IP，自动触发人工审核，误封率不到0.3%。