# WeChatDeveloper for PHP: WeChat APIs, Mini Programs, and Payments

> WeChatDeveloper is a PHP SDK for WeChat public accounts, Mini Programs, WeChat Work, WeChat Pay V2 and V3, and Alipay. It suits PHP applications that want one entry point for common Chinese platform APIs, although its documented API examples and compatibility claims need verification against the target WeChat products.

**zoujingli/WeChatDeveloper** — 【新】微信服务号+微信小程序+微信支付+支付宝支付

- Repository: https://github.com/zoujingli/WeChatDeveloper
- Website: https://www.kancloud.cn/zoujingli/wechat-developer/content
- Stars: 1,691 · Forks: 445
- Language: PHP
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/zoujingli-wechatdeveloper

## The PHP integration problem addressed by WeChatDeveloper

WeChatDeveloper targets PHP developers who need to connect an application to several WeChat-facing products without writing each request, signature, token, or response-handling path from scratch. The repository covers public accounts, Mini Programs, WeChat Work, WeChat Pay, and Alipay. According to the README, its original foundation is `wechat-php-sdk`, from which this project was refactored and optimized.

This scope matters because these products expose different API families. A public-account application may need OAuth2.0, menus, customer messages, material uploads, JSSDK, or QR codes. A Mini Program application may need login-related user handling, subscription messages, content checks, shipping, or Mini Program codes. Payment code has an additional dependency on merchant credentials, transaction-specific data, and the selected payment mode. WeChatDeveloper packages those areas under separate classes rather than presenting one undifferentiated client.

The intended user is therefore a PHP application team maintaining server-side integrations with Chinese messaging and payment platforms. It is less suitable for a small static site with no server, or for a project whose only requirement is one narrowly scoped HTTP request. The README describes broad feature coverage, but it does not document which account permissions, certifications, regional restrictions, or product approvals are required for every listed feature. Those platform conditions cannot be inferred from the source code alone.

## How the WeChat, WeChatDeveloper, and WePay directories fit together

The repository layout reflects a module-per-platform design. `WeChat/` contains WeChat-facing modules, `WeMini/` relates to Mini Programs, and `WePay/` covers the documented payment surface. A separate `WePayV3/` tree represents the newer payment path. `AliPay/` contains the Alipay implementation, while the root `We.php` file provides the common entry point described by the README as `\We::`.

The documented pattern starts by loading `WeChatDeveloper/include.php`, assembling a configuration array, and asking the factory for the required service. Examples create `\We::WeChatUser($config)`, `\We::WePayOrder($config)`, or `\We::AliPayWeb($config)`. This keeps credential configuration separate from the chosen feature class. It also means an application can replace one integration class without changing the configuration shape used by the others.

Most calls appear to return decoded API data as associative arrays. The user-management example reads `$result['data']['openid']`, while the V2 payment example reads `$result['prepay_id']`. The Mini Program and payment examples therefore expect the caller to inspect vendor response fields and handle unsuccessful responses according to the surrounding application.

For endpoints not exposed as a named convenience method, the README documents `callApi()`. Its first argument can be a full HTTP URL for WeChat endpoints or an `apiMethod` such as `alipay.trade.query` for Alipay. It accepts a parameter array and one of `GET`, `POST`, `PUT`, or `DELETE`. This escape hatch broadens compatibility, but it also shifts responsibility to the caller for constructing a valid endpoint, placing credentials in the correct location, and understanding the vendor's response contract.

## Composer installation and a first WeChat user-list call

The README identifies Composer as the recommended installation method. Install the stable package in a PHP project that already has a writable cache location and the required extensions. This command adds the stable package through Composer:

```bash
composer require zoujingli/wechat-developer
```

The README specifies a minimum PHP version of PHP 5.4 and recommends PHP 7.0+, with PHP 7.4 or PHP 8.0 recommended for production. It lists `curl`, `json`, `xml`, `openssl`, `mbstring`, and `bcmath` as required extensions. The cache directory must also be writable. The documentation does not give a command for checking these extensions, so installation success alone should not be treated as proof that the runtime satisfies them.

After installing through Composer, the documented manual entry point is still `WeChatDeveloper/include.php`. A first server-side operation can create the user service with credentials and request its list. Replace the placeholders with credentials belonging to the actual WeChat public account:

```php
<?php
include "WeChatDeveloper/include.php";

$config = [
    'appid'     => 'your_wechat_appid',
    'appsecret' => 'your_wechat_appsecret',
    'cache_path' => '/path/to/cache'
];

try {
    $user = \We::WeChatUser($config);
    $userList = $user->getUserList();
} catch (Exception $e) {
    echo "错误：" . $e->getMessage();
}
```

The expected direct result is the array returned by `getUserList()`. The broader user example indicates that the returned structure can contain a `data` list with `openid` values, but the README does not document pagination parameters, empty-list behavior, or the complete response schema. A first integration should therefore avoid assuming that one response contains every account user.

For development-branch installation, the README gives a separate Composer command. It is intended for consumers who explicitly want `dev-master`, not for an application that should follow the stable package channel:

```bash
composer require zoujingli/wechat-developer dev-master
```

The direct-download path uses the documented repository URL and a manual include. That approach gives the application the source tree directly, but it leaves dependency handling to the integrator. Composer is the clearer option when the surrounding project already manages PHP dependencies.

## WeChat Pay V2, V3, and Alipay credential boundaries

Payment support is broad, but it is split across interfaces with different configuration and call shapes. The V2 example creates `\We::WePayOrder($config)` and passes order fields such as `out_trade_no`, `total_fee`, `openid`, `trade_type`, `notify_url`, and `spbill_create_ip`. It then calls `createParamsForJsApi()` with the returned `prepay_id`. The documented payment modes include JSAPI, APP, H5, Native, and Mini Program.

The V3 example instead obtains an instance from `\WePayV3\Order::instance($config)` and supplies the transaction type as the first argument to `create()`. Its payload uses V3 names including `mchid`, `description`, `payer`, `amount`, and `currency`. This difference is significant. Application code cannot treat V2 and V3 as interchangeable methods with different versions in a comment; their instance construction, field names, and result handling differ.

Alipay is exposed through classes selected by payment context, including `\We::AliPayWeb($config)` for the documented web example. The README also lists RSA and RSA2 signature support and certificate mode. It does not give a complete Alipay key configuration array, certificate installation procedure, or gateway selection guide, so those details must be established before treating an Alipay checkout as production-ready.

Order creation is only part of a payment system. The examples define `notify_url`, but they do not document signature verification, callback idempotency, replay handling, reconciliation, or settlement checks inside this project. The application must not treat a returned order object as proof that payment completed.

## Operational limits of caches, retries, and undocumented vendor behavior

The README claims automatic AccessToken refresh, configurable cache drivers, retry handling, and automatic cleanup of CURL temporary files. This is useful for a long-running PHP service because an expired token or retained temporary file can otherwise require application intervention. However, the repository documentation does not state the retry count, retry conditions, backoff policy, cache key format, cache expiry, or supported cache implementations. The suggestion that Redis can be used describes extensibility, not a documented Redis setup.

The writable `cache_path` is therefore a real deployment dependency. A read-only container, restricted hosting account, or ephemeral filesystem can prevent expected cache writes or remove state between processes. The documentation does not say whether that failure raises an exception, falls back to another storage mechanism, or disables a feature. Test the configured path under the same permissions used in production.

There is another limitation around maintenance. The repository is not archived, and its last push was on 2026-08-27. The listed stable releases are `v1.2.78` from 2026-03-07, `v1.2.77` from 2026-03-03, and `v1.2.76` from 2025-09-15. These dates indicate recent repository activity, but they do not establish compatibility with every current WeChat or Alipay endpoint.

The README's security statements, including XSS filtering, file checks, SHA-256 use, and deserialization validation, are project claims rather than independent audit results. It does not publish a security policy, audit report, supported-version matrix, or upgrade procedure. Maintainers adopting payment code should review the actual call paths handling callbacks, serialized values, files, and signatures rather than relying on the summary.

## WeChatDeveloper compared with direct vendor API clients

The real alternative is to integrate the documented WeChat and Alipay HTTP endpoints directly with a general HTTP client and application-specific adapters. That approach keeps vendor protocol construction visible in the codebase. It can also make callback validation, logging, and error mapping easier to inspect when the team has strict internal standards. The tradeoff is that the application team must implement token acquisition, signature construction, request encoding, response interpretation, and endpoint updates itself.

WeChatDeveloper takes the opposite approach. It supplies named classes and a common `\We::` factory, while `callApi()` covers endpoint calls that do not have a dedicated convenience method. This can reduce repetitive glue for an application already written in PHP and already using WeChat or Alipay products. It also introduces an abstraction layer: debugging may require understanding how the SDK maps configuration and parameters to the vendor request, and an endpoint change may be tied to the SDK rather than a direct request in application code.

Direct clients are the better choice for a single endpoint, a team that deliberately wants no payment abstraction, or an architecture with mandatory HTTP instrumentation and dependency approval. WeChatDeveloper is more relevant when the same application uses several modules and values the README's stated backward-compatible API and common configuration pattern. The README does not provide migration instructions from an existing `wechat-php-sdk` installation, so backward compatibility should be confirmed for the methods the application actually uses.

Under the MIT license, both options allow use and modification with preservation of the applicable copyright and license notice. That licensing fact does not settle operational suitability, payment compliance, or which current vendor APIs an application is entitled to use.

## Conclusion

Adopt WeChatDeveloper when an existing PHP application needs several WeChat or Alipay interfaces behind the documented `\We::` factory and can accommodate its PHP extension and cache-directory requirements. Do not adopt it merely because its README lists a feature, since API availability varies by account type and current vendor requirements are not documented. Verify the required PHP version, the exact endpoint class, callback handling in your application, and the relevant payment credentials before migration; under the MIT license, retain the copyright and license notices when redistributing the code.

## FAQ

### How do I install WeChatDeveloper for PHP?

The recommended command is `composer require zoujingli/wechat-developer`. The runtime needs PHP 5.4 or later, the `curl`, `json`, `xml`, `openssl`, `mbstring`, and `bcmath` extensions, and a writable cache directory.

### How do I create a WeChat user service with WeChatDeveloper?

Include `WeChatDeveloper/include.php`, prepare a configuration array, and call `\We::WeChatUser($config)`. The README then shows calling `getUserList()` on that instance.

### Does WeChatDeveloper support both WeChat Pay V2 and V3?

The README lists both and shows separate examples. V2 uses `\We::WePayOrder($config)`, while V3 uses `\WePayV3\Order::instance($config)` and has a different payload structure.

### Does WeChatDeveloper support Alipay?

Yes. The README documents `\We::AliPayWeb($config)` and lists App, Web, Wap, QR-code, card-payment, transfer, billing, RSA, RSA2, and certificate-related capabilities.

## Sources

- [License: MIT](https://github.com/zoujingli/WeChatDeveloper/blob/master/LICENSE)
- [Project website](https://www.kancloud.cn/zoujingli/wechat-developer/content)
- [README](https://github.com/zoujingli/WeChatDeveloper/blob/master/README.md)
- [Releases](https://github.com/zoujingli/WeChatDeveloper/releases)
- [zoujingli/WeChatDeveloper on GitHub](https://github.com/zoujingli/WeChatDeveloper)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zoujingli-wechatdeveloper