① 一句话需求

把电子钱包的注册手机号校验改为按品牌、按代理线配置，并在绑定与提款时按固定顺序执行。

② 术语写死表

③ 全局红线表

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

本次只管 GCash、Maya、GrabPay 的绑定、提款账户比对及相关后台配置。不管银行卡、提款渠道、解绑／重置、玩家级白名单或既有风控规则。阅读者为客户端前端、账户后端、提款后端、运营配置、合规与测试。

1.1 分类与新增配置

1.1.1 位置：网站管理 ▸ 基本配置 ▸ 提款账户限制（Withdrawal Account Restriction）。该一级目录与 运营参数 并列，新增四项：

1.1.2 两侧独立。开发若调整系统名称，两个总开关仍以 _switch 结尾，四项使用相同前缀。

1.2 两套值域

1.2.1 沟通与逻辑统一使用“开启／关闭”，不得脱离配置类型只说数字。

1.3 例外名单

1.3.1 格式沿用 KYC 触发节点配置：代理:值,代理:值。

1.3.2 运行日志记录无效／重复条目原文与组序，不记录玩家资料。

1.4 既有配置移入分类

1.4.1 gcash_binding_amount、maya_binding_amount、grabpay_binding_amount 移入 提款账户限制。只换分类；标题、系统名称、默认值、现值、品牌继承及前台判定全部不变。

3.1 手机号规范化与比较

3.1.1 两边沿用既有规则规范为 11 位纯数字后精确比较，不比较显示格式，也不新增国家码转换。注册手机号取提交当下会员档案，不存历史；任一侧无法规范时，在校验开启状态下判不相等。

3.2 绑定侧

3.2.1 两个入口最终进入同一个流程：Account 或提款页 → SMS verification → Fund Accounts → 钱包分页签 → + Add → 绑定弹窗 → Confirm。

3.2.2 后端在最终提交时按以下顺序校验；首个失败即停止，只显示对应的既有／本需求文案：

1. 必填与钱包账号既有格式。
2. OTP 是否正确。
3. 同钱包类型是否重复账户。
4. 该钱包类型绑定数量是否已满。
5. 实时计算绑定侧结论；若开启，比对规范化后的钱包手机号与注册手机号。
6. 全部通过后才写入绑定。

3.2.3 绑定侧关闭时跳过第 5 步，其余既有校验仍执行。第 5 步不符时停留绑定页、不落绑定，并显示 §6 指定 Toast。绑定页须保留返回 Fund Accounts 的既有入口。

3.3 提款侧

3.3.1 提款页先执行既有提款条件与表单校验，包含打码量、可用渠道、金额与渠道限制。通过后：

1. 实时计算提款侧结论。
2. 若开启，比对所选电子钱包账户与当下注册手机号。
3. 比对通过或结论关闭，才建立提款单并进入既有流程。

3.3.2 不符时发起失败、停留提款页，不建立提款单、账变或提现风控审核记录，并显示 §6 指定 Toast。放行后的成功弹窗按 Confirm 只关闭弹窗，仍留在提款页。

3.4 作用范围

3.4.1 三种电子钱包行为一致。提款渠道分配、单笔限额、解绑双人复核及每种钱包的绑定数量上限均不改；后台 绑定信息 ＞ AccountNo 与 绑定信息 ＞ WalletAddress 的栏位、页签及操作也不改。

6.1 本需求使用的两条通用文案

6.2 原型会出现的既有文案

6.2.1 银行卡提醒仅为原型既有流程证据，不表示本需求开始管银行卡。

① Requirement in One Sentence

Make registered-Phone-Number validation for e-wallets configurable by brand and agent line, and run it in a fixed order during binding and withdrawal.

② Fixed Terminology

③ Global Invariants

④ Scope and Exclusions

This requirement covers GCash, Maya, and GrabPay binding, withdrawal-account comparison, and related backoffice configuration. It excludes bank cards, withdrawal channels, unbinding/reset, player allowlists, and existing risk-control rules. Readers are client frontend, account backend, withdrawal backend, Operations configuration, Compliance, and QA.

1.1 Category and New Settings

1.1.1 Path: 网站管理 ▸ 基本配置 ▸ 提款账户限制 (Withdrawal Account Restriction). This top-level directory is next to 运营参数. Add four settings:

1.1.2 The two sides are independent. If development changes the system names, both master switches must still end in _switch, and all four settings must use the same prefix.

1.2 Value Domains

1.2.1 Communication and logic must use “On/Off.” Do not state a number without its configuration type.

1.3 Exception List

1.3.1 Use the existing KYC 触发节点配置 format: Agent:Value,Agent:Value.

1.3.2 The runtime log records the raw invalid/duplicate entry and group position, but no player data.

1.4 Move Existing Settings

1.4.1 Move gcash_binding_amount, maya_binding_amount, and grabpay_binding_amount into 提款账户限制. Change only the category. Keep title, system name, default, current value, brand inheritance, and frontend decision behavior unchanged.

3.1 Phone Number Normalization and Comparison

3.1.1 Normalize both numbers to 11 digits using existing rules, then compare exactly. Do not compare display formatting and do not add country-code conversion. Read the Registered Phone Number from the current member profile at submission time; do not store history. If either side cannot be normalized while validation is On, treat them as unequal.

3.2 Binding Side

3.2.1 Both entries end in the same flow: Account or withdrawal page → SMS verification → Fund Accounts → wallet tab → + Add → binding dialog → Confirm.

3.2.2 On final submission, the backend validates in this order. Stop at the first failure and show only its existing/required copy:

1. Required values and existing wallet-account format.
2. Correct OTP.
3. Duplicate account for the same wallet type.
4. Binding-count limit for that wallet type.
5. Resolve the binding-side decision in real time; if On, compare normalized wallet and Registered Phone Numbers.
6. Write the binding only after all checks pass.

3.2.3 When binding-side validation is Off, skip step 5 and keep every other existing validation. If step 5 fails, remain on the binding page, create no binding, and show the Toast in §6. Keep the existing return entry to Fund Accounts.

3.3 Withdrawal Side

3.3.1 The withdrawal page first runs existing conditions and form validation, including turnover, available gateway, amount, and channel limits. After they pass:

1. Resolve the withdrawal-side decision in real time.
2. If On, compare the selected e-wallet account with the current Registered Phone Number.
3. Create the withdrawal request and continue the existing flow only if comparison passes or the decision is Off.

3.3.2 On mismatch, fail and stay on the withdrawal page. Create no withdrawal request, balance transaction, or withdrawal risk-review record. Show the Toast in §6. After an allowed request, Confirm on the success dialog closes only the dialog and remains on the withdrawal page.

3.4 Scope

3.4.1 All three e-wallets behave the same. Do not change withdrawal-channel assignment, per-transaction limits, dual review for unbinding, or binding-count limits by wallet type. Do not change fields, tabs, or actions under backoffice 绑定信息 ＞ AccountNo or 绑定信息 ＞ WalletAddress.

6.1 Two Shared Messages Used by This Requirement

6.2 Existing Copy Shown in the Prototype

6.2.1 The bank-card warning is evidence of an existing prototype flow. It does not put bank cards in scope.