邦斧开放平台 · 会员资产口径权威文档 v1.0.5

文档性质：本文件是接入方（甲方）与邦斧（乙方）之间关于会员积分、消费券（抵扣券）及其释放规则的唯一口径依据。

凡双方文档、口头沟通、演示材料与本文件不一致处，以本文件为准。

变更程序：任何口径变更须双方书面确认后生效，并同步升版（本文件由 v1.0 起编号）。单方不得以系统调整为由改变口径。

2.4 ★ 释放发券时扣多少积分：min(券额 ÷ 5, 会员持有积分)

出处：app/common/Member.php:9205-9206（settleBugSmallDeductionMoneyForty）

$member_dec_integral  = round(bcmul(1, bcdiv($member_record_back, 5, 4), 5), 4);  // 券额 ÷ 5
$member_integral      = $member_info['integral'];
$member_dec_integral  = min($member_dec_integral, $member_integral);               // ★ 被持有积分封顶

★ 这条对开放平台的含义：券由「让利入池」产生，不依赖积分。

接入方的会员即使一个积分都没有，券照发。积分只是"有就顺带扣掉一点"。

★ 退款时如何处理积分：不处理（不动积分）。理由：

① 券已发给会员且不回收（既有口径）⇒ 为其换券付出的积分也不回滚，等价交换自洽；

② 未释放就退款的订单，本就没扣过积分 ⇒ 无可回滚。

实测：会员 5 积分 → 释放发券扣 1 → 剩 4 → 退款后仍为 4（已入 accept_reconciliation 套件断言）。

2.5 ★★ 开放平台（BOP）的积分/入池口径：1:1，且不乘邦斧会员等级倍率

既有系统口径（Member.php:5134 原话）：「入池额度 = 积分基数（唯一计算源，两者 1:1 一一对应）」。

★ 为什么 BOP 不套用 integralBaseAmount()：它内部会乘 BusinessLevel::getEarnRate(bid, mid)

—— 那是邦斧自有商城的会员等级倍率。BOP 的会员在接入方商城，我方再乘一次就是二次放大，

金额与对方商城对不上。

实测：该错误会把 10 元让利变成 9 元入池（因为邦斧侧该会员的倍率是 0.9）。

★ 让利率上限 20% 沿用既有硬顶，但处理方式不同：既有是悄悄封顶（基数被压小），

BOP 是直接拒绝（40001）—— 避免接入方以为被吞钱。与「余额不足拒绝、不按余额截断」同一原则。

2.6 ★★ 退款：扣回积分，但不调用既有 reduceIntegralAndDeduction()

既有退款函数（Member.php:7116）做六件事：①退抵用券 ②扣回会员积分 ③扣回商家积分 ④扣回已派发的券 ⑤入池作废 ⑥积分分账退回。生产实证：订单退款扣除积分 108 条 / 8,674.16。

BOP 只做 ②⑤，且在模块内自己实现 —— 不调用该既有函数。原因（实测）：

该函数第 ④ 步把「ppsid<>0 的已派发券」从平台层 member.deduction_money 扣回；

而 BOP 的券在商家专属层 member_business_deduction_money ⇒ 对 BOP 调用它会把会员的

平台层券余额扣成负数（2026-10-12 实测 -2.2500）。

该函数是为邦斧自营订单（券在平台层）写的，语义不适用于 BOP。

扣回额的精确口径（照 Member.php:7207-7258）：扣回 = 该订单发出积分 − 该订单已扣回的积分。 ⇒ 释放时若已用掉一部分积分换券，退款只扣回剩余部分，不会多扣。 实测：发出 10 → 释放消耗 2 → 退款扣回 8（余额归 0，非 -2）。

2.7 ★ 券的账户属性口径（2026-10-12 拍板）

★ 为什么「不能提现」这条要写死：券若可提现，性质就从「消费抵扣凭证」变成「可兑付资金」，

会牵出资金池、支付牌照、备付金等问题。不支持提现是我方能保持「纯技术服务」定位的前提之一。

★ 为什么「转赠」要留后台开关：转赠是套现与洗券的高风险入口（A 转给 B 再由 B 处理）。

因为已经不支持提现，风险可控；但仍把开关交给商户 —— 由商户按自己业务判断是否开启，

风险与责任随之落在商户一侧。

一、账户与余额构成

接入方在邦斧侧持有两类账户，二者不是同一个东西，不可相加对外表述为"总资产"。

1.1 积分账户

1.2 消费券账户（亦称"抵扣券""抵用金"，同一物的三个叫法）

### ★★ 本次对接的范围（先看这条）

接入方是独立的商家平台，本次只使用「商家专属券」。

平台通用券（会员级券）不在此次对接范围内，原因：它是邦斧平台自有的通用券，

由接入方之外的体系发放与承担，接入方既不发放也不核销。

因此：

- 接口返回的 可用券额度 = 本商家专属券（不含平台通用券）；

- 若某会员在邦斧侧另有平台通用券，接口会以独立字段单列并注明"未计入可用"，

不得把它算进可用额度 —— 否则接入方会拿一个自己用不了的额度去抵扣。

- 平台通用券若日后纳入范围，须双方书面确认后升版本文档（见 §七）。

券余额在邦斧系统中的完整构成 = 会员级通用券 + 该商家专属券（平台自有口径，供理解系统全貌；本次对接只用后者）

对外说明口径：向消费者展示的"可用抵扣券"应为两者之和；向单一商家展示"本店可抵扣"时，应为商家专属券部分。两个数字不同是设计如此，不是数据错误。

1.3 「冻结」的真实含义 —— ★ 易被误解，必须按此口径对外

邦斧的"券冻结"是整体禁用开关，不是"冻结了多少钱"的金额桶。

1.4 待释放（释放池）—— 与上述余额完全独立

释放池是商家侧的未来收益发放机制，与会员手上的券余额是两条独立的账，不互相抵扣、不可相加。

★ 对外只说池余额与累计已释放两个数。"历史入池总额"是只增不减的累计量，不是当前可用的钱，不得当作余额对外展示。

1.5 重要：不存在"总资产"这类合计

积分、券余额、释放池三者口径与用途完全不同（积分是兑换凭证、券是消费抵扣、释放池是商家未来收益）。任何把三者相加得到的"总资产""总余额"都是错误的，双方对外材料均不得使用。

二、积分与券的换算

2.1 换算比例

换算公式（唯一正确写法）：

派发券金额 ≤ 派发基数 × 兑换比例          （乘数即兑换比例，默认 5）
扣减积分   =  派发券金额 ÷ 兑换比例        （即 1 积分最多释放「兑换比例」元券）

以默认值 5 为例：1 积分最多可释放 5 元券；反向，发放 10 元券需扣 2 积分。

2.2 配置口径的显示差异 —— ★ 易错

配置值在数据库中为「界面值 ÷ 10」（界面设 5 → 库中存 0.50），系统读取后还原为界面值（乘数）使用。 ⇒ 双方核对配置时，一律以「界面显示值」沟通（即 5 表示 1 积分换 5 元），不要拿库里的 0.50 对账。

2.3 券的实际抵扣顺序与上限

本次对接（只用商家专属券）：因为只涉及一层券，不存在"先扣哪层"的问题。

下面列出的顺序是邦斧平台自有口径（平台券 + 商家券并存时先扣商家专属券、再扣平台通用券），

在此记录以便日后扩展时对齐，本次对接不适用。

单笔订单实际抵扣额取下三者的最小值：

实际抵扣 = min( 券可用余额 , 本单应付金额 , 订单金额 × 抵扣比例上限 )

2.4 积分不可直接消费

积分不能直接抵扣订单、不能提现、不能转赠他人。唯一出口是兑换为券。 ⇒ 接入方如需"积分直接抵钱"的效果，须由接入方在其侧自行实现，不得表述为邦斧能力。

三、有效期口径 ★

3.0 ★★ 「积分变成的券没有有效期」的完整证据链

这一条是客户最容易担心、也最容易出纠纷的条款，故给出五条互相独立的证据（任一条被推翻都可质疑结论）：

第 5 条的对照组说明（客户若听说"邦斧有积分过期功能"，可用此解释）：

对外可用的表述：「积分变成的抵用券、以及释放池释放出来的券，没有有效期，系统不会过期回收。」

这句话有上述五条证据支撑，可放心写入商务材料与用户协议。

反之，任何"邦斧券有过期规则/到期作废"的说法都是错的，不要写。

3.0.1 ★ 一个必须提前告知客户的正常现象：券可以被兑换成平台券

系统里存在「商家券 → 平台券」的兑换功能（消费者可主动操作，按兑换比例换算）。 这会导致：该会员在商家层的券余额减少，但并非你方核销所致（券流水里会显示来源为兑换）。

这一条不是 Bug，是既有功能。提前说清楚，避免上线后被当成故障排查。

3.1 活跃度口径（积分与券的发放闸门）

• 会员连续不消费达到阈值（默认 1 个月）后，系统停止继续发放新的券；
• 但已有积分不受影响、不清零、不为 0；
• 会员恢复消费后，即刻恢复发放。

对外表述须为："不活跃 = 暂停发放新券"，不得表述为"积分作废""券作废""清零"。

3.2 接入方若需要"券有效期"能力

当前邦斧侧不提供。接入方如确需：

• 由接入方在自己侧记录券的到期时间并自行作废；
• 或提出需求走变更流程（§六），由乙方评估后另行报价与排期。

不得对外宣称邦斧券"有过期规则/有过期回收"。

四、精度与单位 ★

★ 接入方必须以此为准：

1. 调用接口时，金额参数必须传整数分，禁止传浮点元（会因浮点误差产生一分钱级的对账差异）；

积分参数/返回值按 4 位小数处理，不要取整（取整会丢用户资产）；

1. 展示前由接入方自行"分 → 元"除以 100 并保留 2 位；
2. 任何"四舍五入到元"的处理都会导致对账不平，须避免。

五、时间口径

接入方服务器时间与邦斧存在偏差超窗时，接口会返回"时间戳超期"。应校准接入方服务器 NTP，不要靠重试绕过。

六、幂等、可见性与对账

对账建议节奏：接入方每日以 request_id 拉取处理结果，每月与我方账单的"调用明细"核对请求量。

七、口径溯源与争议处理

1. 唯一依据：本文档。双方材料、口头承诺与本文件冲突时，以本文件为准。
2. 变更程序：任何口径调整，须由提出方发出书面变更通知，双方确认后升版；未经确认的单方变更不生效。
3. 争议处理：对某笔金额有异议时，双方以邦斧侧流水（含余额快照）为准进行核对；核对结果不一致的，双方指定技术负责人会同排查。
4. 不在本文档内的事项（下列事项须另行书面约定，不适用"以本文档为准"）：
5. 券在何种交易条件下的发放规则与金额（属商务约定）
6. 接入方与消费者的法律关系、资金流向、税务
7. 推广激励的具体形态与合规性

八、尚未定稿、待双方确认的口径

以下三项目前无单方结论，须双方确认后补入本文档（确认前，涉及的系统行为不代表最终口径）：

附：本文档的技术实现位置与逐条溯源（供双方工程复核）由乙方另行提供，不随本文档对业务方披露。

6.x 合作终止与限流口径（2026-10-12 定稿）

合作终止：终止是交割，不是改状态位。终止前必须核对并导出全量数据（会员资产 / 券流水 / 积分流水 / 业务流水 / 账单）；平台侧终止动作会：① 固化交割快照（当时负债/会员数/未释放池余额） ② 批量吊销该接入方全部令牌 ③ 置为「已终止」。终止后所有接口返回 40108（合作已终止·不可恢复）， 与 40102（停用·可恢复）严格区分 —— 不可恢复的合作不能报成"可联系恢复"。

终止时点的资产归属：终止只断服务，不动任何业务数据（券负债、积分、流水原样保留并导出给客户）。 会员手上未使用的券由客户承接兑付；池中未释放额度终止后不再出批。

限流：两个维度同时生效 —— appid 维度（默认 600 次/分钟）与单接口维度 （默认不限）。窗口为分钟，与计费口径（按分钟调用量阶梯）自洽。单接口维度只拦被超限的那个接口。

版本记录

邦斧开放平台（BOP）· 口径权威文档 v1.0.3 · 2026-10-12