Omnipay Wechatpay Laravel Package

Product Decisions This Supports

• China market entry (payments): WeChat Pay is a de facto requirement for any consumer product selling into mainland China. This package is a candidate to unlock that payment method without building a WeChat Pay integration from scratch.
• Payment gateway abstraction strategy: Because it plugs into Omnipay, it lets you keep WeChat Pay behind the same GatewayInterface you use for Stripe/PayPal — a concrete argument for standardizing on an abstraction layer rather than bespoke per-provider code.
• Build vs. buy vs. adopt: A MIT-licensed driver is essentially a "free" v1. The real decision is adopt as-is, fork and maintain, or choose a maintained alternative (EasyWeChat, yansongda/pay) — this assessment frames that trade-off.
• Roadmap scoping for China features: Relevant to QR/Native pay, JSAPI (in-WeChat browser / mini-program), H5, and App payments. Knowing which flows the gateway covers determines whether China checkout can ship in one release or needs a phased rollout.
• Merchant/legal readiness gating: Weighs operational prerequisites (Chinese business license, WeChat merchant account, settlement currency) — often the actual blocker, not the code.
• Portfolio/risk review: Low opportunity score and a 2019 last release make this a data point for dependency governance: are we comfortable owning an unmaintained payment driver?

When to Consider This Package

Consider it when:

• You are already on Omnipay in a PHP/Laravel codebase and want WeChat Pay to look like every other gateway you support.
• You need the classic WeChat Pay v2 flows (Native/QR, JSAPI, H5, App) and can live with the legacy XML + MD5/HMAC signing model.
• Your China volume is early-stage or a secondary revenue line — i.e., the cost of forking and maintaining a driver is lower than the cost of a full custom integration.
• You accept that you will vendor/fork it: pin it, read the code, and treat it as a starting point rather than a supported dependency.
• You have in-house PHP capability to handle certificate rotation, notify/signature verification, and idempotency yourself.

Look elsewhere when:

• You need WeChat Pay API v3 (RSA certificates, JSON, newer product features). A 2019 release predates it; this is a hard functional gap, not a nice-to-have.
• You want an actively maintained dependency with security patching and current API coverage — six years without a release on a payments library is a material risk.
• You want Laravel-native DX (facades, config publishing, events, testing helpers) — EasyWeChat or yansongda/pay are the better fit and cover Alipay + WeChat Pay together.
• You need marketplace/split settlement, complex refunds/disputes, subscriptions, or cross-border multi-currency.
• You are not on Omnipay — adopting Omnipay plus a stale driver to get one gateway is more surface area than it's worth.
• Your compliance posture requires a supported vendor or an SBOM with current, auditable dependencies (also check compatibility with league/omnipay v3 vs. the older omnipay/common v2 line).

How to Pitch It (Stakeholders)

To executives: WeChat Pay is non-negotiable for Chinese consumers, and this is a free, MIT-licensed adapter that could get us there quickly if our stack already uses Omnipay. It is not a fully supported product — the last release was 2019, it covers the older v2 APIs, and we should assume we'll own and maintain a fork. Recommendation: treat it as a low-cost spike/prototype, validate the China checkout flow end-to-end, then make a deliberate call between funding a maintained fork and switching to a maintained Laravel payment library. The real gating items are commercial and legal (Chinese merchant account and business license), not engineering — those should be tracked as roadmap dependencies now.

To engineering: If we're on Omnipay, this gives us WeChat Pay v2 (QR/JSAPI/H5/App) behind the standard gateway interface for near-zero integration cost — but expect to fork it. Please assess: Omnipay major-version compatibility, whether v3 APIs are on our near-term path (if yes, this package is a dead end), signature/certificate handling and notify-verification correctness, and the security posture of an unmaintained payment dependency. Estimate the maintenance load as "we own this," not "we depend on this."

Bottom line: Good tactical accelerator for a China payment spike; not a strategic dependency. Decide fast, fork deliberately, and keep the abstraction layer so we can swap providers later.