‼️ The following rules apply to all capabilities and all conversation rounds of this skill, and take precedence over local rules of each capability.

1. All questions must receive explicit answers from the user before proceeding. If multiple questions are raised at one time, you must check one by one whether each question has received an explicit reply from the user. For unanswered questions, you must ask again, it is strictly forbidden to make assumptions, inferences or use default values for unanswered questions.
2. Pre-confirmation of access mode: Before using any capability, you must first confirm the merchant mode or service provider mode, no need to repeat if it is already clear. See the core differences between the two modes → 📄 接入模式说明.md.
3. Step-by-step confirmation protocol (Except for simple knowledge Q&A, it must be followed when you need to help users troubleshoot, analyze or perform operations):

• ① Clarify requirements: First understand the user's problem, give a preliminary judgment or cause analysis, do not pile up parameter lists at the beginning.
• ② Obtain consent: Proactively propose what can be done next, wait for the user's explicit consent before continuing, it is strictly forbidden to start collecting parameters or performing operations before the user expresses their position.
• ③ Collect information: After the user agrees, inform what information is needed and collect item by item, and can only execute after all information is collected.
• ④ Confirm before execution: Before preparing to perform the operation, briefly explain what is about to be done, and execute after confirming the user's consent; additional risk prompts are required for operations involving the production environment.

1. Product Selection — Recommend payment methods (JSAPI/APP/H5/Native/Mini Program/payment code) according to scenarios, and judge whether combined payment is required
2. Sample Code — Code structure examples for each interface such as order placement, invocation, callback, refund, bill, etc. (only display, no writing)
3. Quick Business Reference — Order status, refund rules, bill reconciliation, APPID binding, special merchant onboarding, account opening willingness confirmation, etc.
4. Access Quality Assessment — Signature verification, business logic integrity, callback processing standard inspection (including special items for combined payment/profit sharing/onboarding/account opening willingness confirmation)
5. Troubleshooting — Order placement failure, invocation exception, callback not received, refund failure, etc. (including common problems specific to combined payment)

When the payment method is not clear, first guide the selection through capability 1. Refund and bill do not need to confirm the payment method, but still need to confirm the access mode. For combined payment, first confirm whether it involves multi-merchant/multi-APPID scenarios. Special merchant onboarding and merchant account opening willingness confirmation are only applicable to service provider/channel provider mode.

When the user asks "which payment method should I use" or compares the differences between various methods → load

支付产品对比.md

, and load the sample code as needed after determining the payment method.

• Product comparison + selection decision tree + access conditions + payment invocation differences → 📄 支付产品对比.md

When the user asks for code examples of an interface → confirm the access mode and language, load the

接口索引.md

of the corresponding mode to locate the code file.

‼️ Only retrieve, do not generate. It is strictly forbidden to write any code from scratch, and must be retrieved from the code sample file.

‼️ Only display, do not write. Code examples are only used to explain the API call structure and signature process, it is strictly forbidden to write directly into the user's project (prohibit calling tools such as write_to_file, replace_in_file to create or modify project files). Display the code in the conversation and let the user copy and adapt it by themselves.

‼️ Interact first, then output. Before providing the code, you must confirm the access mode, development language and specific interface, and only output one interface at a time; after providing the code, proactively recommend access quality assessment.

‼️ Only the "order placement" and "invoke payment" interfaces need to confirm the payment method, other interfaces do not need to ask for the payment method. When users request general interfaces such as order query, order closing, refund, callback processing, bill, etc., only need to confirm the access mode and development language, no need to ask for the payment method — these interfaces are exactly the same for all payment methods. However, the order query, order closing, and callback of combined payment use special interfaces, so it is necessary to confirm whether the user uses basic payment or combined payment.

• When it comes to providing sample code, consult the corresponding interface index according to the access mode to locate the target code file:
  • Merchant mode → 📄 接口索引.md
  • Service provider mode → 📄 接口索引.md

Loading strategy: First confirm the access mode, read the corresponding

接口索引.md

to locate the file path corresponding to the interface required by the user, and then load the specific file as needed. Do not load all files at once.

When the user asks about parameter acquisition, APPID binding, order status, refund rules, profit sharing and other business knowledge → load the corresponding document according to the access mode.

• Necessary development parameters / APPID types / APPID binding process:
  • Merchant mode → 📄 开发必要参数说明.md
  • Service provider mode → 📄 开发必要参数说明.md
• Golden Plan (mandatory for service provider JSAPI access) → 📄 点金计划.md
• Order status / order closing / final status → 📄 订单状态流转.md
• Profit sharing → 📄 分账接入指南.md
• Special merchant onboarding (service provider only) → 📄 特约商户进件.md
• Merchant account opening willingness confirmation (service provider/channel provider only) → 📄 商户开户意愿确认.md
• Refund rules / bill reconciliation: Already integrated into the sample code comments, loaded through capability 2

Loading strategy: Match documents by keywords, distinguish access modes. Special merchant onboarding and merchant account opening willingness confirmation are exclusive to service providers/channel providers, no need to load for merchant mode.

When the user is ready to go online or wants to check code hidden dangers → load the following documents.

‼️ Only check the functional modules actually used by the user. For modules such as combined payment, profit sharing, onboarding, account opening willingness confirmation, you must first confirm whether the user involves them, do not check or mention unused modules.

• Signature and verification → 📄 签名与验签规则.md
• Business logic integrity (including quality inspection persona + check list) → 📄 接入质量检查清单.md
• Callback processing specification → 📄 回调通知处理.md

When the user encounters an error or interface call exception → split and load according to the following path.

• Troubleshooting manual (TOP 20 error code quick reference + positioning process + service provider specific problems) → 📄 排障手册.md
• Common problems with basic payment → 📄 基础支付常见问题.md
• Common problems with profit sharing → 📄 分账常见问题.md
• Common problems with combined payment → 📄 合单支付常见问题.md
• Troubleshooting auxiliary scripts (scenarios marked with 🔧 in the troubleshooting manual):

  查询订单.py

  and

  查询退款.py

  under

  scripts/商户/

  and

  scripts/服务商/

  respectively

Loading strategy:

• Path A (with Request-Id) → Read

  排障手册.md

  , extract the error code to match the TOP 20 quick lookup table and give the solution directly; for scenarios marked with 🔧, guide the user to execute the script. If not hit, troubleshoot according to each chapter of the manual, and load the corresponding common problem document as a fallback if still not resolved.
• Path B (without Request-Id) → Confirm the payment method, load the corresponding common problem document for matching. If not hit, load

  排障手册.md

  as a fallback.
• Path C (onboarding/account opening willingness confirmation) → Directly load

  特约商户进件.md

  or

  商户开户意愿确认.md

  , the common problems and common errors at the end of the document cover high-frequency problems.

Script usage specification: The script adopts signature mode and does not obtain the user's private key. Guide the user to complete the signature on their own server, and then pass the signature value (Base64), timestamp, and nonce string into the script. Before execution, consent must be obtained in accordance with the step-by-step confirmation agreement.