$ show alipay/alipay-sdk-php-all
This is the official Alipay Open Platform server SDK for PHP (ๆฏไปๅฎๅผๆพๅนณๅฐๆๅก็ซฏSDK). It is a client library, not a runnable application: a merchant's PHP backend constructs typed request objects, hands them to one of two client classes, and the client handles signing, certificate verification, HTTP transport, response verification, and optional field decryption against Alipay's gateway. The repository ships two parallel protocol generations side by side: v2, the legacy protocol using form/XML payloads and traditional RSA/RSA2 parameter signing, and v3, the RESTful JSON protocol generated from an OpenAPI description file via OpenAPI Generator. Together they cover thousands of Alipay APIs spanning payments, funds, mini-programs, IoT, insurance, credit, marketing, education, and financial services. The bulk of the repository (roughly 14,000 files) is auto-generated boilerplate: each v2 request class is a standalone DTO exposing getApiMethodName(), setBizContent/setApiParas, and standard transport metadata (notifyUrl, terminalType, prodCode, needEncrypt). These classes are structurally identical except for API method names and docblocks, which makes the corpus bloated and maintenance-heavy, and test/mock endpoints (e.g., AlipayOpenDanielTestQueryRequest) are mixed into the production surface with no clear curation. The genuinely hand-crafted value lives in the core client classes (AopClient, AopCertClient) and small helpers such as AopEncrypt, SignData, and the service-schema XML writers, where protocol knowledge such as certificate chain validation, zero-IV AES-CBC field encryption, and padded signature parameter sorting is encoded. Architecturally the SDK is a classic thin-transport library: developer builds request DTO -> client serializes to form/JSON -> sign -> POST to gateway -> parse and verify response -> return response object. External dependencies are limited to PHP's openssl and curl extensions plus the Alipay gateway certificate infrastructure. The v2 codebase shows its age (global namespace, require_once-era conventions, global function names like encrypt()/decrypt() that risk collisions), while the v3 SDK is cleaner and namespaced. The codebase is actively maintained โ commit and file metadata run through late 2025 and 2026 โ but the heavy generated cruft, v2/v3 duplication, and lack of in-repo tests keep this from being exemplary craftsmanship. For a PHP engineer integrating with Alipay, this is the authoritative SDK and the signing/encryption reference implementation is worth reading; for reuse in other projects, only the small crypto and schema-utility helpers extract cleanly.
The LLM identified 3 files worth highlighting for reuse:
Self-contained AES-128-CBC encryption/decryption helper with explicit PKCS7 padding, used to encrypt and decrypt sensitive request/response fields in the Alipay v2 protocol. It depends only on PHP's openssl extension and implements the padding logic explicitly rather than relying on hidden behavior, which is essential for interoperating with Alipay's zero-IV encryption scheme. Easily extractable into any PHP project needing deterministic AES-CBC interop.
The certificate-based client at the core of the v2 SDK. It implements the complete signed-request lifecycle: RSA2 signing of sorted parameters, application/CA certificate loading and validation, gateway endpoint selection, HTTP transport of form/JSON payloads, response signature verification, and optional decryption of encrypted fields. Though coupled to Alipay's request DTO conventions, its signing and certificate-verification logic is a clean, studyable reference implementation of public-key API authentication that generalizes to other RSA-signed gateway APIs.
Namespaced helper that serializes Alipay service-schema attribute arrays into structured XML (used for dynamically rendered service/UI schemas). It demonstrates a compact factory-and-writer pattern: ServiceSchemaFactory creates typed XMLAttribute/AttributeRule/Option objects, and the writer renders them into XML elements. Small, dependency-light, and portable to other XML configuration-generation tasks; the v3 namespaced version is notably cleaner than its duplicated v2 counterpart.