Wechat Pay Bundle Laravel Package

Product Decisions This Supports

• China market entry / checkout expansion: supports the build-vs-buy call on accepting WeChat Pay (JSAPI, Native/QR, H5, Mini Program, App) without hand-rolling signing, certificate rotation, and callback verification.
• Feature scope for CNY payments: informs whether to ship WeChat Pay as a first-class payment method at launch versus a phase-2 add-on behind a feature flag.
• Refunds, reconciliation, and order lifecycle: helps decide whether refund automation and settlement/statement pulls are in-scope for v1 or deferred to ops tooling.
• Roadmap for cross-border and multi-channel commerce: a lightweight integration now keeps the door open for Alipay Pay and UnionPay later without re-architecting the checkout abstraction.
• Build vs buy: this is a thin OSS wrapper — the decision is less "buy" and more "adopt + wrap" versus "build an internal WeChat Pay SDK layer." Adopting shifts effort from protocol plumbing to merchant onboarding, compliance, and UX.
• Vendor/lock-in risk budgeting: because it is a pre-1.0 community package (0.0.3 → 0.1.0), it supports a decision to isolate the dependency behind an internal payment port so it can be swapped for the official WeChat Pay SDK or another wrapper.

When to Consider This Package

Consider it when:

• You are a PHP/Laravel (or Symfony-component-friendly) team and WeChat Pay is a required payment method for a Chinese or China-facing user base.
• You want to avoid maintaining signature generation, platform-certificate handling, AES-GCM callback decryption, and API v3 request signing in-house.
• You need standard merchant flows quickly: prepay/order creation, payment notification handling, query, close, and refund.
• You are comfortable owning the operational side — merchant ID, API v3 key, serial numbers, cert lifecycle — and just want the transport/protocol layer.
• You can pin the version and accept pre-1.0 API churn (0.1.0 is still 0.x; expect breaking changes).

Look elsewhere when:

• You need a vendor-backed SLA, security disclosure process, or long-term support commitment — prefer the official WeChat Pay PHP SDK or a commercially supported gateway.
• Your stack is not PHP, or you want a managed payments orchestration layer (Stripe/Adyen/Airwallex) that already covers CNY and WeChat Pay.
• You require advanced merchant-platform features (profit sharing/分账, compound payments, cross-border settlement, multi-merchant routing) — plan for bespoke work regardless of package.
• You need out-of-the-box Laravel idioms only: this is a bundle-style package, so expect to write your own service-provider wiring, config publishing, and facade/DI glue.
• The 0.1.0 changelog does not document the 0.0.3 → 0.1.0 delta — treat undocumented pre-1.0 bumps as potentially breaking and require an upgrade spike before committing.

How to Pitch It (Stakeholders)

For executives: WeChat Pay is non-negotiable for reaching Chinese customers, and integrating it directly is slow, error-prone, and security-sensitive. This package lets us add WeChat Pay in days rather than weeks by handling the cryptographic protocol for us, while keeping our checkout layer vendor-neutral so we are not locked in. Cost is effectively zero in licensing; the real investment is merchant onboarding and compliance, which we would pay either way. Given it is a pre-1.0 community package, we recommend a bounded pilot behind our payment abstraction rather than a company-wide standard.

For engineering: Small, focused dependency that covers WeChat Pay API v3 signing, certificate handling, and notification verification — the parts most likely to be subtly wrong if written from scratch. We will wrap it in an internal PaymentGateway port, pin the version, and add contract tests around order creation, callbacks, and refunds. The 0.1.0 release notes are a bare changelog link with no described changes, so we will diff 0.0.3 against 0.1.0 and run our contract suite before upgrading. Treat the public API as unstable until 1.0; no direct calls from domain code.