充值方式管理 · 限额设置 · PRD

作者 Luke　版本 v1.9　日期 2026-09-11　状态 进行中　平台 BRAND_A & BRAND_B　类 M

L0 · 快速掌握

① 一句话需求

在 充提渠道管理 ▸ 充值方式管理 的每个充值方式新增 设置限额，按总代维护单笔充值最小／最大限额；有记录取本清单值，没有记录才取基本配置。

② 术语写死表

③ 全局红线表

④ 适用范围与「不做」边界

本期包含入口、限额列表、增改删、批量改删、取值优先级、充值方式联动、四个权限点与管理员日志。不改充值方式既有创建／修改／删除／启停逻辑、充值渠道分配、基本配置、玩家端页面／文案；不做首充／非首充分开设置、清单筛选搜索、导入导出或批量失败明细。

1. 页面与资料

1.1 入口

1.1.1 充值方式列表既有 修改、删除、启用／禁用 不变，末尾新增 设置限额。有查看权限才显示入口；充值方式停用时仍可进入配置。

1.2 限额列表

1.2.1 标题为 充值方式管理列表–{充值渠道}–限额列表。一个充值方式一份列表，本页不做筛选与搜索。

1.2.2 默认按 ID 正序。

2. 新增与账号解析

2.1 表单与容错解析

2.1.1 页顶包含 添加代理（仅限总代） 多行输入、单笔最小限额、单笔最大限额、添加、返回。一次可输入多个总代，共用一组限额。账号栏内提示为 可用逗号、分号、空格或换行分隔。

2.1.2 前后端使用同一条管线：

1. 将英文逗号 ,、中文逗号 ，、英文分号 ;、中文分号 ；、Tab、空格与换行识别为分隔。
2. 去除每项前后空白并跳过空项；连续、开头或结尾分隔符都不报错。
3. 账号按大小写不敏感去重；同批重复只算一项。
4. 以清洗去重后的账号数判断单条／批量与 100 个上限。

2.1.3 清洗后 0 个账号按必填未填；大于 100 个整批不提交并保留输入。不存在“账号格式错误”分支：无法对应账号的字串按“查无此账号”处理。

2.2 对象校验与部分成功

2.2.1 批量逐条独立写入；有成功项就只回成功数，不列失败明细；0 项成功时统一回 本批次无可新增的总代账号，不借用任一单一对象错误。同批重复去重，并发撞唯一键只剔除冲突项。不校验总代是否已被分配该充值渠道。

3. 取值、生效与联动

3.1 限额规则

3.1.1 两个限额都只收 1–50000 的正整数，含端点，不收 0、负数、小数或千分位；最小必须严格小于最大。本清单可比基本配置更宽或更严，不取交集。

3.2 玩家提交取值

1. 以玩家所属总代＋本次充值方式查本清单；有记录就取本清单的一组值，并同时用于首充与非首充。
2. 没有记录或本清单读取失败时，回落基本配置：首充取首充值，非首充取非首充值；读取失败同时写系统运行日志。
3. 基本配置也取不到时，该充值方式不可用并沿用既有处理。

3.2.1 限额作用于总代整条代理线。玩家点击提交时读取并校验一次；保存后的改动只影响之后的新提交，在途充值订单与后续支付回调不重判。下游只回本次生效的最小／最大值，不回来源层级。

3.3 充值方式联动

3.3.1 停用充值方式时保留全部限额记录；玩家不能选择该方式，重新启用后原记录恢复生效。物理删除充值方式时，同一事务物理删除其全部限额记录并写日志；受影响总代回落对应基本配置。取消渠道分配不删除记录，重新分配后恢复生效。

4. 修改、删除、批量与并发

4.1 修改与删除

4.1.1 单条与批量修改共用弹窗：顶部显示 本次将修改 {n} 笔限额配置，总代栏禁用且完整可滚动，两个金额栏留空且都必填；确认后统一改为同一组值，不设二次确认。请求若带总代字段，拒绝整个请求。

4.1.2 单条与批量删除共用二次确认，不设备注；弹窗完整列出账号，不截断。确认后物理删除，立即回落基本配置；同一总代可重新新增并取得新 ID。

4.2 选取与并发

4.2.1 批量修改／删除未勾选时不发请求。逐行勾选只在当前页有效；表头全选覆盖整份清单并跨页。批量遇已删除或越权项时跳过，其余继续，结果统一显示 操作成功 且不带笔数。

4.2.2 同一记录并发修改以后保存者为准；被删除后再单条修改／删除则提示刷新。所属充值方式已删除时退回充值方式列表。重复提交不得产生重复记录或重复删除。

5. 权限、提示与留痕

5.1 权限

5.1.1 后端每次读写都复核页面权限、写权限、管理员 BRAND 与充值方式 BRAND。

5.2 后台提示语

5.2.1 格式符号本身不触发提示。系统查询／写入异常沿用后台原始错误呈现，不包装新文案。

5.3 留痕

5.3.1 新增、修改、删除及充值方式连带删除写管理员操作日志，记录对象 ID、总代、充值方式、前后值；批量记一条汇总并带对象 ID 清单。批量新增另记提交数、成功数、剔除数及被剔账号。日志不设备注／操作原因。降级读取写系统运行日志。

L2 · 验收与附录

文档版本：v1.9 | 日期: 2026-09-11 | 作者: Luke | 文档状态：进行中

Deposit Method Limit Settings · PRD (English)

Author Luke　Source Version v1.9　Translation Version EN-1.5　Date 2026-09-14　Status In Progress　Platforms BRAND_A & BRAND_B　Category M

This file is the English translation of PRD_v1.9_DepositMethodLimitConfig.md. The Chinese PRD remains the authoritative source. If the two files differ, follow the Chinese PRD and update this translation.

EN-1.5 aligns Admin Action Log and the minimum／maximum per-transaction limit labels with the shared translation dictionary. All source rules are unchanged.

L0 · Quick Overview

All Master Agent examples in the infographic use the required @BRAND_A suffix.

① Requirement in One Sentence

Add Set Limits to every Deposit Method under Deposit & Withdrawal Channel Management ▸ Deposit Method Management. Maintain per-transaction minimum and maximum deposit limits by Master Agent. Use the Override List when a record exists; otherwise use Base Configuration.

② Fixed Terminology

③ Global Invariants

④ Scope and Exclusions

This release includes the entry point, limit list, create, edit, delete, batch edit and delete, value-source priority, Deposit Method linkage, four permission points, and the Admin Action Log. It does not change existing Deposit Method create, edit, delete, enable, or disable behavior; deposit-channel assignment; Base Configuration; or player-facing pages and copy. It does not add separate first-deposit and non-first-deposit settings, list filtering or search, import or export, or batch-failure details.

1. Page and Data

1.1 Entry Point

1.1.1 Keep the existing Edit, Delete, and Enable / Disable actions in the Deposit Method list. Append Set Limits. Show the entry point only with view permission. The configuration page remains accessible when the Deposit Method is disabled.

1.2 Limit List

1.2.1 The title is Deposit Method List – {Deposit Channel} – Limit List. Each Deposit Method has one list. This page has no filter or search.

1.2.2 Default sort: ID ascending.

2. Create and Account Parsing

2.1 Form and Tolerant Parsing

2.1.1 The top of the page contains a multiline Add Agents (Master Agents only) input, Minimum Per-Transaction Limit, Maximum Per-Transaction Limit, Add, and Back. One submission may contain multiple Master Agents sharing one limit pair. The account placeholder is Separate with commas, semicolons, spaces, or line breaks.

2.1.2 Frontend and backend use the same pipeline:

1. Treat English comma ,, Chinese comma ，, English semicolon ;, Chinese semicolon ；, Tab, spaces, and line breaks as separators.
2. Trim each item and skip empty items. Consecutive, leading, or trailing separators do not cause an error.
3. Deduplicate accounts case-insensitively. A duplicate within the same batch counts once.
4. Use the cleaned, deduplicated account count to determine single versus batch processing and the 100-account limit.

2.1.3 After cleaning, zero accounts is treated as a missing required field. More than 100 accounts blocks the entire batch and retains the input. There is no account-format-error branch: a string that cannot be resolved to an account is handled as account not found.

2.2 Object Validation and Partial Success

2.2.1 Write each batch item independently. If any item succeeds, return only the success count and no failure details. If zero items succeed, always display No Master Agent accounts in this batch can be added. and do not reuse any single-item error. Deduplicate within the batch. If a concurrent write hits the unique key, remove only the conflicting item. Do not validate whether the Master Agent has already been assigned that deposit channel.

3. Value Selection, Effect, and Linkage

3.1 Limit Rules

3.1.1 Both limits accept only positive integers from 1–50000, inclusive. Reject 0, negative values, decimals, and thousands separators. Minimum must be strictly less than maximum. The Override List may be wider or narrower than Base Configuration; do not take the intersection.

3.2 Value Selection at Player Submission

1. Query the Override List by the player's Master Agent and current Deposit Method. If a record exists, use its pair for both first and non-first deposits.
2. If no record exists or the Override List read fails, fall back to Base Configuration: use first-deposit values for a first deposit and non-first-deposit values otherwise. On read failure, also write a system runtime log.
3. If Base Configuration also cannot be read, the Deposit Method is unavailable and follows existing handling.

3.2.1 The limits apply to the Master Agent's entire downline. Read and validate once when the player clicks submit. Saved changes affect only later submissions; do not re-evaluate in-flight deposit orders or subsequent payment callbacks. Downstream responses include only the effective minimum and maximum, not the source tier.

3.3 Deposit Method Linkage

3.3.1 Disabling a Deposit Method retains all limit records. Players cannot select the method while it is disabled; re-enabling restores the records. Physically deleting a Deposit Method physically deletes all its limit records in the same transaction and writes a log; affected Master Agents fall back to the matching Base Configuration. Removing channel assignment does not delete records; reassignment restores them.

4. Edit, Delete, Batch, and Concurrency

4.1 Edit and Delete

4.1.1 Single and batch edit use the same dialog titled Edit limits for {n} records. The Master Agent field is disabled and fully scrollable. Both amount fields open empty and are required. Confirmation updates all selected records to the same pair, with no second confirmation. The buttons are Confirm and Cancel. If the request contains a Master Agent field, reject the entire request.

4.1.2 Single and batch delete use the same confirmation dialog and have no Remarks field. The dialog lists every account without truncation. On confirmation, physically delete the records and immediately fall back to Base Configuration. The same Master Agent may be added again and receives a new ID.

4.2 Selection and Concurrency

4.2.1 Batch edit or delete sends no request when nothing is selected. Row selection applies only to the current page; header Select All covers the complete list across pages. In a batch, skip deleted or unauthorized items and continue with the others. The result always displays Operation successful. without a count.

4.2.2 For concurrent edits to one record, the later save wins. If a record was deleted before a single edit or delete, prompt the operator to refresh. If the owning Deposit Method was deleted, return to the Deposit Method list. Repeated submission must not create duplicate records or repeat a deletion.

5. Permissions, Copy, and Audit Logs

5.1 Permissions

5.1.1 On every read and write, the backend revalidates page permission, write permission, the administrator's BRAND scope, and the Deposit Method BRAND.

5.2 Backoffice Copy

Chinese remains the source copy. The English column is the approved display translation for the bilingual prototype.

5.2.1 Formatting characters alone do not trigger a message. System query or write failures use the existing raw backoffice error presentation and do not introduce new copy.

5.3 Audit Logs

5.3.1 Create, edit, delete, and linked deletion of a Deposit Method write the Admin Action Log containing object ID, Master Agent, Deposit Method, and before-and-after values. One batch writes one summary with the object ID list. Batch create also records submitted, successful, and removed counts plus removed accounts. Logs have no Remarks or operation-reason field. Fallback reads write a system runtime log.

L2 · Acceptance and Appendices

Source document version: v1.9 | Translation: EN-1.5 | Date: 2026-09-14 | Author: Luke | Translation status: In Progress