SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillswechatpay-basic-payment

wechatpay-basic-payment

Coding & development

View repository

Updated 10-15 17:26

About this skill

WeChat Pay Basic Payment & Combined Payment Integration 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 a clear answer from the user before continuing. If multiple questions are asked at once, each question must be checked one by one to confirm whether it has received a clear answer from the user. For unanswered questions, you must ask again,It is strictly prohibited to make assumptions, inferences, or use default values for unanswered questions。
  2. Integration Mode Pre-confirmation: Before using any capability, you must first confirmmerchant modeorservice provider mode. If already specified, no need to repeat. For the core differences between the two modes, see → 📄 Integration Mode Description.md。
  3. Step-by-step Confirmation Protocol(except for simple knowledge Q&A; must be followed when helping users troubleshoot, analyze, or perform operations):
  • ① Clarify requirements: First understand the user's question, give a preliminary judgment or cause analysis, and do not start by piling up a list of parameters.
  • ② Obtain consent: Proactively propose what can be done next,and only continue after the user explicitly agrees. It is strictly prohibited to start collecting parameters or performing operations before the user has responded.
  • ③ Collect information: After the user agrees, inform them what information is needed and collect it item by item; execution can only proceed once all is collected.
  • ④ Confirmation before execution: Before preparing to perform an operation, briefly explain what is about to be done, and execute only after confirming the user agrees; if the online environment is involved, additional risk warnings must be provided.

Capability Overview

  1. Product Selection — Recommend payment methods based on the scenario (JSAPI/APP/H5/Native/Mini Program/payment code), and determine whether combined payment is needed
  2. Example Code — Code structure examples for each interface's order placement, invocation, callback, refund, bills, etc. (display only, no writing)
  3. Business Knowledge Quick Reference — Order status, refund rules, bill reconciliation, APPID binding, sub-merchant onboarding, account opening intention confirmation, etc.
  4. Integration Quality Assessment — Signature signing and verification, business logic completeness, callback handling standardization checks (including special items for combined payment/profit sharing/onboarding/account opening intention confirmation)
  5. Troubleshooting — Order placement failure, invocation exceptions, callbacks not received, refund failure, etc. (including common issues specific to combined payment)

When the payment method is not specified, first guide selection through Capability 1. Refunds and bills do not require confirmation of the payment method, but still require confirmation of the integration mode. Combined payment requires first confirming whether a multi-merchant/multi-APPID scenario is involved. Sub-merchant onboarding and merchant account opening intention confirmation apply only to service provider/channel provider mode.

Capability 1: Product Selection

When the user asks "which payment method should be used" or compares the differences between methods → load 支付产品对比.md, and after determining the payment method, load example code as needed.

Capability 2: Sample Code

When the user requests a code sample for a certain API → confirm the integration mode and language, and load the corresponding mode's 接口索引.md to locate the code file.

‼️ Retrieve only, do not generate. Writing any code from scratch is strictly prohibited; it must be retrieved from the code sample files.

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

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

‼️ Payment method only needs to be confirmed for the "Place Order" and "Invoke Payment" APIs; other APIs do not require asking about the payment method. When the user requests general APIs such as order query, order close, refund, callback handling, bills, etc., only the integration mode and development language need to be confirmed, and there is no need to ask about the payment method—these APIs are completely identical across payment methods.However, the order query, order close, and callback for combined payment use dedicated APIs, so it is necessary to confirm whether the user is using basic payment or combined payment.

  • When providing sample code, consult the corresponding API index according to the integration mode to locate the target code file:

Loading strategy: first confirm the integration mode, read the corresponding 接口索引.md to locate the file path corresponding to the API the user needs, then load the specific file on demand. Do not load all files at once.

Capability 3: Business Knowledge Quick Reference

When the user asks about business knowledge such as parameter acquisition, APPID binding, order status, refund rules, profit sharing, etc. → load the corresponding document according to the integration mode.

Loading strategy: match documents by keywords, distinguishing the integration mode. Sub-merchant onboarding and merchant account opening intention confirmation are exclusive to service providers/channel providers, and do not need to be loaded in merchant mode.

Capability 4: Integration Quality Assessment

When the user is preparing to go live or wants to check code for hidden risks → load the following documents.

‼️ Only check the functional modules actually used by the user. Modules such as combined payment, profit sharing, merchant onboarding, and account opening willingness confirmation must first confirm whether the user is involved.If unused, do not check and do not mention。

Capability 5: Troubleshooting

When the user encounters an error or abnormal API call → load by the routing paths below.

Loading strategy：

  • Path A (has Request-Id)→ read 排障手册.md, extract the error code to match the TOP 20 quick reference table and directly provide the solution; for those marked 🔧, guide the user to execute the script. If no match is found, troubleshoot according to the chapters in the manual; if still unresolved, load the corresponding FAQ document as a fallback.
  • Path B (no Request-Id)→ confirm the payment method, load the corresponding FAQ document for matching. If no match is found, load 排障手册.md as a fallback.
  • Path C (merchant onboarding/account opening willingness confirmation)→ directly load 特约商户进件.md or 商户开户意愿确认.md, the FAQs and common errors at the end of the document cover high-frequency issues.

Script usage specification: the script uses signature mode and does not obtain the user's private key. Guide the user to complete the signature on their own server, then pass the signature value (Base64), timestamp, and random string to the script. Before execution, consent must be obtained according to the step-by-step confirmation protocol.