Allinpay Yunshangtong 2.0 Integration Guide

Problem to solve

When integrating Allinpay Yunshangtong 2.0, the main risk is not just API debugging. Teams can choose the wrong product version, hard-code APP_ID or keys into source, handle signing and async callbacks inconsistently, or miss edge cases in refunds and callback processing. The skill provides a constrained integration guide for that scenario, turning payment onboarding into confirmable, reusable, and verifiable steps.

How it works

The main workflow runs in order: product selection, payment service selection, parameter acquisition, code generation, and quality checks. Each blocking confirmation point requires an explicit user reply, preventing code generation before the business path is confirmed. Code generation prioritizes existing samples in reference/示例代码/: signing, message assembly, HTTP calls, file upload/download, and async notification handling are produced from matched examples first. Transactional flows such as consumption and refunds also check for corresponding demos before generating new code. Auxiliary workflows cover troubleshooting, business knowledge, API index, and solution consulting, useful for signature failures, missing callbacks, transCode lookup, and drafting integration plans. Quality checks include key security, signing and encryption, async notification, transaction result handling, refunds, file download, and pre-launch validation, helping turn commonly missed engineering details into a checklist.

Boundaries

This is best suited for merchants or ISV developers who have already decided to use Allinpay Yunshangtong 2.0 and need help generating integration code, reviewing API calls, and preparing a joint debugging plan. It is not a sandbox, key vault, or formal API documentation replacement. Developers must still review generated code, load APP_ID, private keys, public keys, and service endpoints from configuration, and avoid placeholders or fake data in real integration.