WeChat Pay Score Access Guide

Global Interaction Specifications

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

1. All questions must receive clear answers from the user before proceeding. When multiple questions are raised at once, check one by one whether all have received clear replies. Unanswered questions must be followed up again, 严禁自行假设、推断或使用默认值.
2. Access Mode Pre-confirmation: Before using any capability, confirm the Merchant Mode or Service Provider Mode first. No need to repeat if it has been clarified. The core differences between the two modes (parameter naming, API path prefix, signature utility class) can be found in

   Access Guide/Signature and Verification Rules.md

   for each role.
3. Step-by-step Confirmation Protocol (except for simple knowledge Q&A):

• ① Clarify Requirements: First understand the problem and give an initial judgment, do not pile up parameter lists.
• ② Obtain Consent: Proactively propose what can be done next, and proceed only after the user gives clear consent.
• ③ Collect Information: After the user agrees, inform the required information and collect it item by item, and execute only after all information is collected.
• ④ Confirm Before Execution: Briefly explain what will be done before the operation, and execute only after confirming consent; additionally prompt risks for online environments.

Capability Overview

1. Product Selection — Understand the functional positioning of WeChat Pay Score, sub-modes of orders requiring confirmation (first deposit-free / first enjoy), typical usage scenarios and access prerequisites
2. Sample Code — Full set of interfaces including create / query / cancel / complete / modify amount / sync status / refund / query refund / JSAPI / Mini Program / APP launch / three types of callbacks
3. Quick Business Reference — Development parameters and business rules (including APIv2 key and service ID), order status flow, field specifications such as

   risk_fund

   / completion amount formula /

   post_payments

   , signature verification, callback processing
4. Access Quality Assessment — General security radar + Pay Score exclusive radar: amount legality, order status mis-call prevention, callback and order query complementarity, APIv2 launch signature, risk fund upper limit verification, (service provider)

   sub_mchid

   routing anti-cross-order
5. Troubleshooting — TOP 20 error codes + common issues, covering HTTP errors / callback not received / signature failure / refund exceptions / role-specific issues / business rules / general access configuration

Routing Instructions: Capability 1 is used for product conceptual questions and access prerequisite confirmation. Users who have confirmed access to Pay Score can directly jump to Capabilities 2/3. Capabilities 2 and 3 can be called independently, but the "access mode pre-confirmation" must be completed for the first time. After hitting error codes or common issues in Capability 5, Capability 4 must be recommended at the end for one-time self-check.

Capability 1: Product Selection

When users ask "What is this product / what can it do / what scenarios is it suitable for / what prerequisites are needed for access / first deposit-free or first enjoy" → Load the product introduction document to answer. Users who have confirmed access to Pay Score can directly jump to Capabilities 2/3.

• Product Introduction (product overview + usage scenarios + access prerequisites):
  • Merchant Mode → 📄 Merchant Mode Product Introduction
  • Service Provider Mode → 📄 Service Provider Mode Product Introduction

Capability 2: Sample Code

When users request sample code for a certain interface → Confirm the access mode and language, load the

Interface Index.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, must retrieve and obtain from sample code files.

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

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

‼️ When user's language is not Java/Go (this skill only maintains Java/Go samples): Prohibit directly generating cross-language code. Process:

1. Obtain clear consent using

   AskQuestion

   (the copy must clearly indicate "reference implementation / not officially maintained / must self-review and test"), only send official Java/Go original text if not agreed.
2. After consent, generate business code "reference implementation" by translating based on official Java samples; then ask in plain text whether to translate Java public libraries (SDK utility classes + HTTP client), do not paste without clear consent. Attach the following disclaimer block before each code segment.

⚠️ The following code is a cross-language reference implementation, generated by AI by translating based on official Java samples, and is not maintained by WeChat Pay official.

• Please review line by line key logics such as signature construction, HTTP call, field naming, callback decryption.
• Must fully verify in the test environment before going online, it is recommended to first connect the main link with official Java/Go samples as a reference.
• In case of access issues, take official Java/Go samples as the standard.

‼️ Launch End Type Confirmation Rules: For "launch order confirmation page" / "launch order details page", must first confirm the launch end type (JSAPI Official Account / Mini Program / APP Android / APP iOS / APP HarmonyOS), as the message and signature rules are different for different ends; no need to ask about the launch end for other general interfaces (create / query / cancel / complete / modify amount / sync status / refund / query refund / three types of callbacks).

• When providing sample code, refer to the corresponding interface index according to the access mode:
  • Merchant Mode → 📄 Merchant Mode Interface Index
  • Service Provider Mode → 📄 Service Provider Mode Interface Index

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

Interface Index.md

to locate the interface file path, then load the specific file as needed. Do not load all files at once.

Capability 3: Quick Business Reference

When users ask about development parameters and business rules (mchid / sub_mchid / appid / sub_appid / APIv3 key / APIv2 key / Merchant API Certificate / WeChat Pay Public Key / Service ID), order status,

risk_fund

/ completion amount formula /

post_payments

fields, signature rules, callback mechanism and other business knowledge → Load the corresponding document according to the access mode.

• Development Parameters and Business Rules (parameter list + acquisition steps + order status flow + key field parameter transfer specifications + reconciliation and launch acceptance):
  • Merchant Mode → 📄 Merchant Mode Development Parameters and Business Rules
  • Service Provider Mode → 📄 Service Provider Mode Development Parameters and Business Rules
• Signature and Verification Rules (request signature / response verification / callback verification / launch Pay Score Mini Program APIv2 signature):
  • Merchant Mode → 📄 Merchant Mode Signature and Verification Rules
  • Service Provider Mode → 📄 Service Provider Mode Signature and Verification Rules
• Callback Processing (callback decryption / verification / idempotency / concurrency control):
  • Merchant Mode → 📄 Merchant Mode Callback Processing
  • Service Provider Mode → 📄 Service Provider Mode Callback Processing

Capability 4: Access Quality Assessment

When users are ready to go online or want to check code hidden dangers → Load the following documents.

‼️ Only check the functional modules actually used by the user. Modules such as profit sharing, APP launch, Mini Program launch must first confirm whether the user involves them, do not check or mention unused modules.

• Access Quality Check (including quality inspection persona + check list):
  • Merchant Mode → 📄 Merchant Mode Access Quality Check
  • Service Provider Mode → 📄 Service Provider Mode Access Quality Check

Capability 5: Troubleshooting

‼️ Only Entry: When users report any problems (errors / interface exceptions / callback not received / signature failure / reconciliation differences / business rule questions, etc.), first load the troubleshooting manual below according to the access mode, strictly follow the "troubleshooting process" in the manual, prohibit guessing the cause or directly analyzing the code by yourself.

‼️ After troubleshooting, must actively recommend access quality assessment at the end of the reply (take the opportunity of troubleshooting to check other potential problems at once); if need to recommend sample code, confirm the development language first, when the user's language is not Java/Go, follow the cross-language confirmation process of Capability 2 (pop-up confirmation → reference generation + disclaimer block + public library step-by-step).

• Troubleshooting Manual (1. TOP 20 Error Codes + 2. Common Issues, covering HTTP / callback / signature / refund / business rules / general configuration):
  • Merchant Mode → 📄 Merchant Mode Troubleshooting Manual
  • Service Provider Mode → 📄 Service Provider Mode Troubleshooting Manual

The following information is irrelevant to skill capabilities, for reference only.

💬 Community and Feedback