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

wechatpay-basic-payment

Coding & development

View repository

Updated 10-15 16:37

About this skill

WeChat Pay Basic Payment & Combined Payment Integration Guide

Global Interaction Specifications

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

  1. All questions must receive an explicit answer from the user before proceeding. If multiple questions are asked at once, each question must be checked one by one to confirm whether an explicit answer has been received from the user. For unanswered questions, they must be asked 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, first confirmMerchant ModeorService Provider Mode, no need to repeat if already specified. 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 execute operations):
  • ① Clarify requirements: First understand the user's question, give a preliminary judgment or cause analysis, and do not immediately pile up a parameter list.
  • ② Obtain consent: Proactively propose what can be done next,and only continue after the user explicitly agrees, and it is strictly prohibited to start collecting parameters or executing operations before the user has expressed a position.
  • ③ Collect information: After the user agrees, inform them what information is needed and collect it item by item; execution can only proceed after it is all collected.
  • ④ Confirmation before execution: Before preparing to execute 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, bill, etc. (display only, not written)
  3. Business Knowledge Quick Reference — Order status, refund rules, bill reconciliation, APPID binding, sub-merchant onboarding, account opening willingness confirmation, etc.
  4. Integration Quality Assessment — Signature verification, business logic completeness, callback handling compliance checks (including special items for combined payment/profit sharing/onboarding/account opening willingness 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 willingness confirmation are only applicable to the service provider/channel provider mode.

Capability 1: Product Selection

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

Capability 2: Sample Code

When the user wants 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. It is strictly forbidden to write any code from scratch; 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 signing process; it is strictly forbidden to write them directly into the user's project (it is forbidden to call 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 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.

‼️ For payment methods, only the "place order" and "invoke payment" APIs need confirmation; 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 confirm the integration mode and development language; there is no need to ask about the payment method—these APIs are completely identical across payment methods.However, combined payment order query, order close, and callbacks use dedicated APIs, so it is necessary to confirm whether the user is using basic payment or combined payment.

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

  1. Use AskQuestion to obtain explicit consent (the wording must clearly state "reference implementation / not officially maintained / must be reviewed and tested by yourself"); if consent is not given, only send the official Java/Go original text.

  2. After consent, use the official Java sample as the baseline to translate and generate a business code "reference implementation"; then use plain text to ask whether to translate the Java public libraries (SDK utility classes + HTTP client); if not explicitly requested, do not include them. Attach the disclaimer block below before each code segment.

⚠️ The following code is across-language reference implementation, generated by AI translating with reference to the official Java sample, and is not officially maintained by WeChat Pay.

  • Pleasereview line by line key logic such as signature construction, HTTP calls, field naming, and callback decryption.
  • Before going live, it must be fully verified in the test environment; it is recommended to first use the official Java/Go samples to get the main flow working as a reference.
  • If integration issues occur, the official Java/Go samples shall prevail.
  • When providing sample code is involved, 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 as needed. 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 integration modes. Sub-merchant Onboarding and Merchant Account Opening Willingness 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 risks → load the following documents.

‼️ Only check the functional modules the user actually uses. For modules such as Combined Payment, Profit Sharing, Onboarding, and Account Opening Willingness Confirmation, first confirm whether the user is involved;do not check or mention those not used。

Capability 5: Troubleshooting

When the user encounters an error or an API call exception → route and load according to the paths below.

‼️ When recommending sample code for troubleshooting, the development language must first be confirmed, and only the corresponding sample should be recommended. In the troubleshooting manual, the "Sample Code Recommendation" for each error code may involve both Java/Go language samples, but when outputting,only output the matching sample. If the development language has not yet been confirmed, naturally ask the user when recommending sample code.

‼️ If the user's language is not Java/Go, handle it according to the cross-language confirmation process in Capability 2(pop-up confirmation → reference generation + disclaimer block + public library step-by-step). First use text to explain the key fix points in the Java/Go sample (signature, fields, process), then after completing the full process, generate the "reference fix code" for the corresponding language.

Loading Strategy：

  • Path A (has Request-Id)→ read 排障手册.md, extract the error code, match it against the TOP 20 quick reference table and directly provide a solution; for those marked 🔧, guide the user to execute the script. If not matched, troubleshoot according to the manual's chapters; if still unresolved, load the corresponding FAQ document as a fallback.
  • Path B (no Request-Id)→ Confirm the payment method, and load the corresponding FAQ document for matching. If no match is found, load 排障手册.md as a fallback.
  • Path C (application/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 Guidelines: The script uses a 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. Consent must be obtained in accordance with the step-by-step confirmation protocol before execution.

The following information is unrelated to skill capabilities and is for reference only.

💬 Community and Feedback

If you encounter issues during use, have suggestions for improvement, or want to exchange integration experience with other developers, you are welcome to scan the QR code to add the enterprise WeChat group and discuss with the official team and community developers:

WeChat Pay Skills community group QR code