If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/go-pay/gopay shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 4w ago
• 21+ active contributors
• Distributed ownership (top contributor 40% of recent commits)
• Apache-2.0 licensed
• CI configured
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live go-pay/gopay repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/go-pay/gopay.

What it runs against: a local clone of go-pay/gopay — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in go-pay/gopay | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 57 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of go-pay/gopay. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/go-pay/gopay.git
#   cd gopay
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of go-pay/gopay and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "go-pay/gopay(\\.git)?\\b" \\
  && ok "origin remote is go-pay/gopay" \\
  || miss "origin remote is not go-pay/gopay (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 57 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~27d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/go-pay/gopay"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

GoPay is a unified Go SDK that aggregates payment processing for 8+ Chinese and international payment providers (WeChat Pay, Alipay, QQ Pay, Tenpay, LakaLa, PayPal, Apple Pay, Saobei). It abstracts away provider-specific API differences so developers write payment logic once and swap providers via configuration—currently ~2.2MB of Go code providing client implementations, request/response marshaling, and webhook verification across wechat/, alipay/, qq/, allinpay/, lakala/, paypal/, and apple/ subdirectories. Monorepo structure: root-level directories for each provider (alipay/, wechat/, qq/, etc.), each containing client.go (provider SDK client), *_api.go files (method groupings by feature—e.g., alipay/marketing_api.go, alipay/funds_api.go), *_test.go test files, and provider-specific subdirs (e.g., alipay/v3/ for v3-only APIs, alipay/cert/ for certificates). Root gopay/ package exports unified constants. .claude/skills/ contains onboarding guides.

Go backend engineers building e-commerce platforms, SaaS billing systems, or payment-enabled services in mainland China who need to integrate multiple payment gateways without reimplementing each provider's v2/v3 API specs, certificate validation, and signature verification logic.

Actively maintained production-grade SDK: supports Go 1.24.0, has comprehensive *_test.go files across all payment providers, GitHub Actions CI/CD pipeline configured in .github/workflows/go.yml, well-organized documentation in /doc/ folder (alipay_v3.md, wechat_v3.md, etc.), and provides real example implementations via examples/ and companion repo gopay-platform. Clear v2/v3 versioning strategy (e.g., separate alipay/v3/ paths) shows long-term maintenance pattern.

Low dependency risk: only 6 direct dependencies (crypto, errgroup, smap, util, xlog, xtime from go-pay org + golang.org/x/crypto), all maintained by either the same author or Google. Main risk is tight coupling to Chinese payment APIs which may change regulatory requirements; certificate validation in alipay/cert/ suggests manual cert updates needed periodically. Single-maintainer risk (iGoogle-ink primary) somewhat mitigated by active community (mentioned WeChat/Douyin communities in README). No breaking change notes visible in file list, suggesting stable API surface.

Active development on v3 API support (WeChat v3, Alipay v3 explicitly versioned in docs and separate client files). Recent additions include merchant fund transfer upgrades (doc/wechat_v3.md mentions 'new merchant transfer interface'). Shell scripts in .github/workflows/ indicate automated testing/release pipeline in use. No specific open PRs visible in file list, but continuous refinement across payment provider integrations suggests steady feature parity updates.

git clone https://github.com/go-pay/gopay.git
cd gopay
go mod download
go test ./...

Then read gopay/alipay/client_test.go or gopay/wechat/v3/client_test.go to see concrete usage patterns; these are referenced explicitly in the README as the canonical examples.

Daily commands: This is a library, not a service. To verify it works: go test -v ./alipay or go test -v ./wechat/v3 (requires test credentials in *_test.go). For local dev of payment integrations, reference examples/ folder or companion repo go-pay/gopay-platform which wraps GoPay in a runnable HTTP service.

• alipay/client.go: Core Alipay SDK client initialization, request signing, and response parsing—template for understanding how all providers wrap their APIs
• wechat/v3/client.go: WeChat Pay v3 API client (modern version); shows cert-based request signing and webhook verification patterns used across providers
• alipay/cert/cert.go: Certificate loading and validation for RSA signature verification; critical for Alipay's public-key infrastructure
• gopay/gopay.go: Root package constants and version info; entry point for consumers importing the SDK
• alipay/client_test.go: Comprehensive test examples covering Alipay client initialization, API calls, and response handling—referenced in README as canonical usage guide
• .claude/skills/add-payment-interface/SKILL.md: Structured onboarding guide for adding a new payment provider; documents exact steps and patterns expected
• doc/alipay_v3.md: User-facing documentation for Alipay v3 integration; mirrors code structure and explains real-world usage

Adding payment provider support: Study alipay/client.go + alipay/common_api.go as template; create newprovider/client.go with NewClient(), define API methods, add newprovider/client_test.go. Fixing a provider: Edit files in {alipay|wechat|qq}/ matching the broken feature (e.g., alipay/marketing_api.go for promo bugs, wechat/v3/client.go for WeChat v3 contract changes). Adding docs: Update /doc/{provider}.md following existing markdown format. Tests: Always pair code changes with *_test.go additions (see alipay/client_test.go at line ~40 for test patterns).

No hardcoded mocks or test fixtures: *_test.go files require live API credentials (Alipay AppID, WeChat MchID, PayPal API keys) set as constants or env vars—tests will fail silently or skip if credentials are missing. Certificate paths are relative/hardcoded: alipay/cert/ paths in cert.go may assume specific file locations; test runs may fail if certs are missing or paths change. Webhook signature verification is provider-specific: each provider (alipay, wechat) has different signature algorithms (RSA vs HMAC-SHA256)—passing a webhook body to the wrong provider's verify function will fail. V2 vs V3 API incompatibility: doc/wechat_v2.md is marked 'not recommended'—using v2 client for v3 endpoints or vice versa will fail (separate wechat/ and wechat/v3/ packages intentionally separate). Go version constraint: requires Go 1.24.0+ per go.mod; older versions may fail due to crypto library updates. No built-in retry logic: callers must implement retries themselves; network timeouts on payment APIs are not auto-retried.

• Public-Key Infrastructure (PKI) & Certificate-Based Signing — Alipay and WeChat Pay use RSA/HMAC signatures to authenticate API requests and webhook payloads; alipay/cert/cert.go and wechat/v3/client.go implement cert loading, parsing, and signature validation—misunderstanding this will cause all requests to be rejected
• Webhook Signature Verification — Payment providers send async notifications (payment completion, refund status) as HTTP webhooks with cryptographic signatures; each provider has different signing algorithms (Alipay: RSA, WeChat: HMAC-SHA256); GoPay provides verify helpers but consumers must correctly route webhooks to the right provider
• API Versioning (v2 vs v3) with Backward Compatibility — WeChat Pay and Alipay both published v3 APIs with breaking changes; GoPay maintains separate wechat/v3/ and alipay/v3/ packages to support both old and new integrations—choosing the wrong version in your import will expose incompatible methods
• Request/Response Marshaling & Custom JSON Tags — Payment APIs use varying JSON field naming (snake_case, camelCase); GoPay uses struct tags to map Go field names to provider-specific field names transparently—mismatched tags cause silent failures when the API receives unexpected field names
• Context Propagation in Concurrent Requests — GoPay imports go-pay/errgroup for concurrent batch operations (e.g., querying multiple refund statuses); understanding context cancellation and error aggregation prevents goroutine leaks and silent failures in batch payment operations
• Aggregation Pattern & Adapter/Facade Design — GoPay implements the Adapter pattern: each provider's SDK is wrapped in a consistent interface (NewClient, Execute, SetLogger) so swapping payment providers requires only configuration changes, not code rewrites—understanding this pattern clarifies how to add new providers
• Merchant Account & MchID Credential Management — Each payment provider requires distinct merchant credentials (WeChat MchID, Alipay AppID, LakaLa TerminalID); GoPay clients initialize with these creds; incorrect or missing credentials are the #1 cause of integration failures and are not caught at compile time

• go-pay/gopay-platform — Official companion monolithic web service that wraps GoPay SDK and exposes payment APIs via HTTP; reference implementation for production deployment patterns
• wechatpay-go/wechatpay-go — Official WeChat Pay Go SDK (WeChat's own implementation); alternative if integrating only WeChat v3—GoPay abstracts away differences
• smartwalle/alipay — Alternative pure-Go Alipay SDK; shows competing approach to aggregating Alipay APIs; GoPay combines Alipay + other providers in one import
• iGoogle-ink/gopay-docs — Extended documentation repo for GoPay; centralized docs reference for all payment provider integrations beyond root /doc/
• go-pay/crypto — Cryptographic utilities dependency (RSA, HMAC, etc.) shared across payment signature verification; maintained by same author for dependency consistency

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for alipay/error.go and error handling across payment providers

The alipay package has error.go and error_test.go, but there's no visible error handling test coverage for other payment providers (wechat, paypal, etc.). Given that this is a payment aggregation SDK where error handling is critical for production stability, adding systematic error parsing and validation tests across all providers would catch edge cases in error responses from different payment APIs.

• [ ] Review alipay/error_test.go to understand the current error testing pattern
• [ ] Create equivalent error_test.go files for other payment provider packages (wechat, paypal, lakalapay, etc.)
• [ ] Add tests for error code parsing, error message extraction, and error response marshaling
• [ ] Test edge cases: null errors, malformed responses, timeout errors, network errors

Add integration tests and examples for model validation (alipay/model*.go files)

The alipay package contains 13+ model files (model_payment.go, model_commerce.go, model_merchant.go, etc.) representing various API request/response structures. There's no visible validation test coverage for these models. Adding validation tests would ensure required fields are present, data types are correct, and serialization works correctly before making actual API calls.

• [ ] Create alipay/model_test.go to test struct marshaling/unmarshaling for all model types
• [ ] Add validation tests for required fields in payment models (model_payment.go)
• [ ] Add roundtrip serialization tests (JSON encode/decode) for each model_*.go file
• [ ] Include tests for edge cases: empty strings, zero values, special characters in Chinese text fields

Add GitHub Actions workflow for testing multiple payment provider integrations (mock API tests)

The repo has .github/workflows/go.yml but it likely only runs basic unit tests. Since gopay supports 8+ payment providers (WeChat, Alipay, PayPal, Lakalapay, etc.), adding a comprehensive CI workflow that tests each provider's client initialization, request signing, and response parsing would catch provider-specific issues early. This would include mock tests for each provider without requiring live API credentials.

• [ ] Review current .github/workflows/go.yml to see what's tested
• [ ] Create provider-specific test matrices in the workflow (wechat, alipay, paypal, lakalapay, etc.)
• [ ] Add mock HTTP server tests for each provider's client to verify request/response handling
• [ ] Test certificate loading and validation for providers that use certs (alipay/cert/ directory)
• [ ] Add code coverage reporting per provider to identify untested code paths

• Add integration tests for alipay/fee_api.go and alipay/goods_api.go (currently have test files but missing coverage for fee calculation and goods metadata endpoints; reference alipay/common_api_test.go for pattern)
• Document LakaLa v2 vs v3 API differences in doc/lakala.md similar to how doc/wechat_v2.md vs doc/wechat_v3.md are separated (currently only one doc exists, but lakala/ may support multiple versions)
• Implement standardized error mapping across all providers (create gopay/error_codes.go mapping provider-specific error codes to a unified enum; currently each provider has its own error.go with no cross-provider normalization)

• High · Outdated Go Cryptography Library — go.mod - golang.org/x/crypto v0.48.0. The dependency 'golang.org/x/crypto v0.48.0' is from 2024 and may contain known vulnerabilities. Go crypto packages are frequently updated for security patches. The project targets Go 1.24.0 but the crypto version should be regularly audited. Fix: Update golang.org/x/crypto to the latest stable version. Run 'go get -u golang.org/x/crypto' and verify compatibility. Implement automated dependency scanning using tools like Dependabot or Snyk.
• High · Hardcoded Certificate Files in Repository — alipay/cert/*.crt files. Alipay certificate files are stored directly in the repository at 'alipay/cert/' including alipayPublicCert.crt, alipayRootCert.crt, and appPublicCert.crt. While these may be public certificates, storing them in version control creates supply chain risks and makes them discoverable. Fix: Move certificate files to environment-based configuration or secure key management systems. Use certificate pinning at runtime. Never commit private keys or sensitive certificates to version control, even if they appear public.
• Medium · Potential Cryptographic Misuse in Sign Operations — alipay/sign.go, alipay/sign_test.go. The file 'alipay/sign.go' handles signing operations critical for payment transactions. Without code review, there's risk of improper signature verification, weak hashing algorithms, or salt reuse in cryptographic operations. Fix: Conduct thorough security audit of signature generation and verification logic. Ensure RSA signatures use PKCS#1 v2.1 (OAEP) or PSS padding. Verify SHA-256 or stronger hashing algorithms are used. Review all sign_test.go cases for comprehensive coverage.
• Medium · Payment Data Exposure Risk in API Handlers — alipay/*_api.go files, wechat/*, paypal/* payment handlers. Multiple payment API files (payment_api.go, funds_api.go, commerce_api.go) handle sensitive financial data. Lack of visibility into error handling and logging practices could lead to sensitive data (transaction IDs, amounts, user data) being logged unencrypted. Fix: Implement secure logging practices: exclude sensitive fields from logs, use structured logging with log levels, implement log rotation and encryption. Use HTTP security headers (X-Content-Type-Options, X-Frame-Options). Sanitize all error messages before returning to clients.
• Medium · Third-Party Authentication Integration Risks — alipay/third_auth.go, alipay/third_dev.go, alipay/client_request.go. Files like 'alipay/third_auth.go' and 'alipay/third_dev.go' handle OAuth/third-party authentication flows which are common attack vectors. CSRF, token leakage, and authorization bypass risks need verification. Fix: Implement CSRF protection for all state-changing operations. Use secure state parameters with cryptographic randomness. Implement token expiration and rotation. Validate redirect URIs against whitelist. Never store tokens in query parameters or logs.
• Medium · Notification Handler Vulnerability — alipay/notify.go. The 'alipay/notify.go' file handles webhook notifications from payment providers. Without proper signature verification and replay attack prevention, this could allow unauthorized transaction confirmation. Fix: Implement strict signature verification for all incoming notifications. Add timestamp validation to prevent replay attacks. Implement idempotency checks using transaction IDs. Log all notification received for audit trails. Use TLS 1.2+ for all webhook communications.
• Low · Internal Private Dependencies Without Version Pinning — go.mod - github.com/go-pay/* dependencies. Custom dependencies (github.com/go-pay/crypto, github.com/go-pay/smap, etc.) lack explicit security tracking. These private packages could introduce vulnerabilities if not properly maintained. Fix: Pin exact versions of all internal dependencies. Maintain a security policy for these packages. Conduct regular security audits. Document source and integrity of each dependency. Consider publishing security advisories for any findings.
• Low · undefined — undefined. undefined Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.