Omnipay Wechatpay Laravel Package

Technical Evaluation

• Architecture fit: Omnipay is a framework-agnostic payment gateway abstraction (the PHP analogue of ActiveMerchant). This package is a driver, not an application module — it exposes Omnipay::create('WechatPay') with purchase(), completePurchase(), refund(), and query(). It slots in cleanly as an infrastructure adapter beneath a domain-level payment service, but it brings no Laravel service provider, config file, migration, facade, or webhook route. All Laravel glue is yours to write (the laravel-omnipay wrappers are equally stale).
• API generation gap — the decisive finding: The last release is 2019-11-30, which places this driver on WeChat Pay API v2 (XML payloads, MD5/HMAC-SHA256 signing, a 32-char merchant API key). WeChat has been steering merchants toward API v3 (JSON, SHA256-RSA2048, platform certificates, AES-256-GCM-encrypted callback resources). v2 still works for grandfathered merchants, but it is not where a new integration should start.
• Integration feasibility: The surface area is small — a gateway class, a set of request classes, and a signing helper trait. A competent engineer can audit it end-to-end in a day, which makes it forkable rather than merely dependable.
• Technical risk: This code path moves money. Signature verification, notify (callback) authenticity, retry idempotency, and integer-分 (cent) amount handling are correctness-critical. Most orgs' dependency-review processes will flag a six-year-old payment library as a blocker requiring an explicit exception.
• Runtime compatibility: No release since 2019 means no declared PHP 8.x support. Expect Composer resolution conflicts against modern league/omnipay and symfony/* constraints, plus PHP 8 deprecations and simplexml hardening work in a small private fork.
• Ecosystem signal: 0 reported Packagist dependents. Few downstream users means few eyes on the code, few issue threads, and no third-party security review to lean on.
• Key questions:
  • Are we a Chinese legal entity holding a 商户号 (merchant ID) and settlement bank account, or is this cross-border/offshore?
  • Which product surfaces are in scope: Native (QR), JSAPI (in-WeChat browser), H5, App, Mini Program?
  • Is our merchant account on v2 or v3, and does WeChat's current onboarding force v3?
  • Do we need refunds, partial refunds, profit-sharing (分账), or settlement reconciliation exports?
  • Do we have an ICP-filed domain and the JSAPI payment directory configured?

Integration Approach

• Stack fit: Omnipay is PSR-friendly and works inside Laravel, but it is not Laravel-idiomatic. The correct shape is ports and adapters: define a PaymentGateway interface in your domain (create charge, verify callback, refund, query) and treat Omnipay + this driver as one swappable implementation. This preserves optionality if you later migrate to wechatpay/wechatpay (official v3 SDK) or yansongda/pay.
• Migration path: (1) Wrap, never leak — no Omnipay\WechatPay\* types in controllers or Eloquent models. (2) If you are on v3, treat this package as a reference implementation for v2 semantics and build on the official SDK instead. (3) If you already hold a v2 merchant account, this package is a legitimate shortcut to first charge.
• Compatibility gate: Before committing, resolve constraints against PHP 8.1–8.3 and Laravel 10/11. Then exercise the full flow against WeChat's sandbox, which is itself thin — plan for real-money smoke tests at ¥0.01.
• Sequencing: merchant-account discovery → adapter interface → driver PoC on one product (Native or JSAPI) → notify handler with signature verification and replay protection → refund/query → daily reconciliation job → load test → production with a kill switch. Do not attempt all five product surfaces in phase one.
• Callback plumbing: Laravel needs a CSRF-exempt, public, idempotent POST route. WeChat retries failed notifications with backoff, so the handler must key idempotency on out_trade_no and return the WeChat-specified ack body — not a generic HTTP 200.

Operational Impact

• Maintenance: Effectively you are the maintainer. Single-maintainer project, no security advisory process, six-year release gap. Plan a fork under your own namespace with a documented divergence and upgrade strategy.
• Support: Community-only and Chinese-language-first — WeChat's canonical docs and the practical knowledge base are largely in Chinese blogs and forums. Staff accordingly.
• Scaling: Negligible compute; this is an HTTP client. Real constraints are WeChat's: unified-order rate limits, platform certificate rotation, and callback concurrency. Comfortable at thousands of orders/day.
• Failure modes to instrument:
  • Signature verification failures (API key or cert drift)
  • Missed notifications causing silent order-state divergence — always pair callbacks with a polling/query job
  • Duplicate notifications and double-fulfillment
  • Refund state divergence between your ledger and WeChat's
  • Clock skew on request timestamps
  • TLS/certificate expiry
  • Merchant-account-level events (settlement holds, risk-control freezes) surfacing as opaque error codes
• Reconciliation: Build a daily settlement-file (对账单) ingest regardless of package choice. Integrations that trust only push callbacks drift; this is the most common operational gap in thin-gateway adoptions and the one that costs finance teams weeks.
• Ramp-up: An Omnipay-literate engineer is productive on the driver in ~2–3 days, but needs 2–4 weeks to be genuinely safe on WeChat Pay semantics (signing, notify, refunds, reconciliation). This package does not shorten that curve — it only shortens the first day.
• TPM read: High fit for a narrow, well-understood case — existing v2 merchant account, Native/JSAPI only, team willing to fork and own it. High operational risk otherwise. The 2019 release date is the deciding factor; the low opportunity score reasonably reflects a region-locked, fast-decaying, niche integration.