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/roncoo/roncoo-pay 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.

WAIT — Stale — last commit 3y ago

• 6 active contributors
• Distributed ownership (top contributor 32% of recent commits)
• Apache-2.0 licensed
• ⚠ Stale — last commit 3y ago
• ⚠ No CI workflows detected
• ⚠ 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 roncoo/roncoo-pay repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/roncoo/roncoo-pay.

What it runs against: a local clone of roncoo/roncoo-pay — 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 roncoo/roncoo-pay | 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 master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1254 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of roncoo/roncoo-pay. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/roncoo/roncoo-pay.git
#   cd roncoo-pay
#
# 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 roncoo/roncoo-pay and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "roncoo/roncoo-pay(\\.git)?\\b" \\
  && ok "origin remote is roncoo/roncoo-pay" \\
  || miss "origin remote is not roncoo/roncoo-pay (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "pom.xml" \\
  && ok "pom.xml" \\
  || miss "missing critical file: pom.xml"
test -f "roncoo-pay-app-notify/src/main/java/com/roncoo/pay/AppNotifyApplication.java" \\
  && ok "roncoo-pay-app-notify/src/main/java/com/roncoo/pay/AppNotifyApplication.java" \\
  || miss "missing critical file: roncoo-pay-app-notify/src/main/java/com/roncoo/pay/AppNotifyApplication.java"
test -f "roncoo-pay-app-notify/src/main/java/com/roncoo/pay/app/notify/core/NotifyQueue.java" \\
  && ok "roncoo-pay-app-notify/src/main/java/com/roncoo/pay/app/notify/core/NotifyQueue.java" \\
  || miss "missing critical file: roncoo-pay-app-notify/src/main/java/com/roncoo/pay/app/notify/core/NotifyQueue.java"
test -f "roncoo-pay-app-order-polling/src/main/java/com/roncoo/pay/AppOrderPollingApplication.java" \\
  && ok "roncoo-pay-app-order-polling/src/main/java/com/roncoo/pay/AppOrderPollingApplication.java" \\
  || miss "missing critical file: roncoo-pay-app-order-polling/src/main/java/com/roncoo/pay/AppOrderPollingApplication.java"
test -f "roncoo-pay-app-reconciliation/src/main/java/com/roncoo/pay/AppReconciliationApplication.java" \\
  && ok "roncoo-pay-app-reconciliation/src/main/java/com/roncoo/pay/AppReconciliationApplication.java" \\
  || miss "missing critical file: roncoo-pay-app-reconciliation/src/main/java/com/roncoo/pay/AppReconciliationApplication.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1254 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1224d)"
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/roncoo/roncoo-pay"
  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).

roncoo-pay is a Chinese open-source internet payment system that provides a complete payment infrastructure with independent account management, user system, payment gateway, transaction processing, and reconciliation/settlement modules. It integrates Alipay and WeChat Pay channels and offers both a payment gateway API (roncoo-pay-web-gateway) and an operations dashboard (roncoo-pay-web-boss) for managing merchants, fees, and transaction settlements. Multi-module Maven monorepo organized by function: roncoo-pay-service is the core business logic layer (used by all other modules), roncoo-pay-common-core provides shared utilities and DAOs, while specialized modules (roncoo-pay-app-notify, roncoo-pay-app-order-polling, roncoo-pay-app-reconciliation, roncoo-pay-app-settlement) handle async tasks via ActiveMQ. Web modules (roncoo-pay-web-boss, roncoo-pay-web-gateway, roncoo-pay-web-merchant) depend on roncoo-pay-service for business logic.

Payment platform operators, fintech companies, and e-commerce businesses in China who need to build unified payment collection systems without integrating each payment provider separately. System integrators and backend Java developers maintaining multi-tenant payment infrastructure.

Actively maintained production system (Spring Boot 2.1.2, Java 11). The codebase is well-structured with multiple specialized modules, comprehensive test database (database.sql), and documentation links. However, the most recent visible updates are from 2021-2022 based on dependency versions, indicating active development but not continuous daily updates. Production-ready for payment operations in a mature fintech context.

Core risk: dependency on external payment providers (Alipay SDK 3.4.49, WeChat integration) with potentially outdated versions and irregular patch cycles. Single language codebase (11.4MB Java) means maintenance burden concentrated. No visible CI/CD pipeline configuration files (no .github/workflows, no Travis/Jenkins config). Payment systems require PCI-DSS compliance considerations not obviously addressed in visible code. ActiveMQ message broker dependency requires separate deployment and operational knowledge.

Based on UPDATELOG.md and current structure: system is in maintenance mode with periodic updates. Recent work appears focused on Spring Boot 2.1.2 upgrade, stabilization of reconciliation/settlement batch processes, and ensuring notification reliability through ActiveMQ-backed queues. No visible ongoing PR activity or GitHub Issues in file list suggests issues are managed outside this repo or in community channels (QQ group 608537272).

git clone https://github.com/roncoo/roncoo-pay.git
cd roncoo-pay
mvn clean install
# Database setup required:
# mysql -u root -p < database.sql
# Configure application.yml in each module (roncoo-pay-app-notify/src/main/resources/application.yml, etc.)
# Start individual modules or use roncoo-pay-web-boss for operations dashboard

Note: Requires MySQL, Redis, ActiveMQ, and Java 11+ installed locally.

Daily commands: Each module has its own Spring Boot application class:

• Operations Dashboard: java -jar roncoo-pay-web-boss-2.1.2-SNAPSHOT.jar
• Payment Gateway: java -jar roncoo-pay-web-gateway-2.1.2-SNAPSHOT.jar
• Notification Worker: java -jar roncoo-pay-app-notify-2.1.2-SNAPSHOT.jar
• Order Polling Worker: java -jar roncoo-pay-app-order-polling-2.1.2-SNAPSHOT.jar Prerequisites: MySQL running with imported database.sql, Redis available, ActiveMQ broker running.

• pom.xml — Root Maven POM defining all project modules (notify, polling, reconciliation, settlement) and Spring Boot 2.1.2 parent dependency—essential for understanding the multi-module build structure.
• roncoo-pay-app-notify/src/main/java/com/roncoo/pay/AppNotifyApplication.java — Entry point for the notification service module; handles asynchronous merchant notifications via ActiveMQ queue.
• roncoo-pay-app-notify/src/main/java/com/roncoo/pay/app/notify/core/NotifyQueue.java — Core queue management for payment notifications; critical abstraction for message-driven architecture.
• roncoo-pay-app-order-polling/src/main/java/com/roncoo/pay/AppOrderPollingApplication.java — Entry point for order polling service; polls third-party payment gateways (Alipay, WeChat) to update order status.
• roncoo-pay-app-reconciliation/src/main/java/com/roncoo/pay/AppReconciliationApplication.java — Entry point for reconciliation service; downloads and parses payment provider statements for settlement matching.
• roncoo-pay-app-settlement/src/main/java/com/roncoo/pay/AppSettlementApplication.java — Entry point for settlement service; executes daily settlement calculations and payment flows to merchants.
• database.sql — Database schema definition; required for understanding data model across all payment operations and account systems.

Add Support for a New Payment Provider (e.g., PayPal)

1. Create a new parser class implementing the ParserInterface in the reconciliation module (roncoo-pay-app-reconciliation/src/main/java/com/roncoo/pay/app/reconciliation/parser/ParserInterface.java)
2. Implement statement download and parsing logic following ALIPAYParser or WEIXINParser pattern (roncoo-pay-app-reconciliation/src/main/java/com/roncoo/pay/app/reconciliation/biz/ReconciliationFileDownBiz.java)
3. Extend ReconciliationTask to call your new parser during the daily reconciliation workflow (roncoo-pay-app-reconciliation/src/main/java/com/roncoo/pay/app/reconciliation/ReconciliationTask.java)
4. Update database schema to add provider-specific reconciliation fields if needed (database.sql)

Add a New Notification Type or Channel (e.g., SMS)

1. Create a new NotifyTask variant or extend the existing task in the notify core module (roncoo-pay-app-notify/src/main/java/com/roncoo/pay/app/notify/core/NotifyTask.java)
2. Register your notification handler in NotifyQueue to route messages (roncoo-pay-app-notify/src/main/java/com/roncoo/pay/app/notify/core/NotifyQueue.java)
3. Create a new message listener if using a separate queue topic (roncoo-pay-app-notify/src/main/java/com/roncoo/pay/app/notify/message/ConsumerSessionAwareMessageListener.java)
4. Configure the listener in ActiveMQ config and application properties (roncoo-pay-app-notify/src/main/java/com/roncoo/pay/config/ActiveMqListenerConfig.java)

Customize Settlement Rules or Add Custom Fees

1. Extend or override SettBiz to customize settlement calculation logic (roncoo-pay-app-settlement/src/main/java/com/roncoo/pay/app/settlement/biz/SettBiz.java)
2. Modify DailySettCollectBiz to adjust how settlement data is collected from transactions (roncoo-pay-app-settlement/src/main/java/com/roncoo/pay/app/settlement/biz/DailySettCollectBiz.java)
3. Update the scheduled settlement implementation to call your custom logic (roncoo-pay-app-settlement/src/main/java/com/roncoo/pay/app/settlement/scheduled/impl/SettScheduledImpl.java)
4. Verify thread pool configuration supports your new settlement complexity (roncoo-pay-app-settlement/src/main/java/com/roncoo/pay/config/ThreadPoolTaskConfig.java)

1. ActiveMQ dependency: roncoo-pay-app-notify and roncoo-pay-app-order-polling require ActiveMQ broker running separately; application.yml must point to correct broker URL (default likely localhost:61616). 2. Redis caching: Ehcache and Redis both configured; session/cache configuration in roncoo-pay-common-core must match runtime environment. 3. Database initialization: database.sql must be imported before startup; schema includes merchant fee tables, account ledgers, and transaction history—missing tables cause cascade failures. 4. Fastjson 2.0.8 compatibility: version jump from 1.x to 2.x may have breaking serialization changes; custom JSON converters in roncoo-pay-common-core handle payment amount precision. 5. Alipay/WeChat credentials: Each module needs merchant credentials and API keys in application.yml for payment provider integration; these are environment-specific and not in git. 6. Shiro session management: Apache Shiro 1.9.1 configured for authentication; session persistence requires Redis backend configuration in individual module YAMLs.

• Payment Reconciliation (对账) — In roncoo-pay-app-reconciliation, daily batch processes compare internal transaction records against payment provider reports (Alipay/WeChat) to detect discrepancies, missing transactions, or fraud—critical for financial accuracy in money systems
• Settlement (清算结算) — roncoo-pay-app-settlement module calculates payouts to merchants and platform revenue based on reconciled transactions; requires understanding of fee structures, withholding, and batch payment processing
• Idempotent Payment Processing — Payment systems must guarantee exactly-once transaction semantics despite network retries; roncoo-pay uses ActiveMQ with transaction IDs to prevent duplicate charge attempts when merchant callbacks fail
• Multi-tenant Merchant Isolation — roncoo-pay-service manages multiple independent merchants with separate accounts, fee rates, and settlements; requires careful database foreign key design and query filtering to prevent data leakage
• Asynchronous Notification with Retry Strategy (ActiveMQ) — roncoo-pay-app-notify persists notifications in queue and retries delivery to merchant webhooks with exponential backoff—payment status must reach merchant despite temporary network failures
• Account Ledger Double-Entry Bookkeeping — roncoo-pay maintains account balances via ledger entries (debit/credit) to ensure money conservation—each transaction creates paired entries across merchant, platform, and provider accounts
• Order State Machine (支付订单状态转换) — Transactions progress through defined states (pending → paid → settled/failed); roncoo-pay-app-order-polling queries provider APIs to advance state and prevents invalid transitions

• heibaiying/spring-samples — Contains Spring Boot payment integration examples and MyBatis patterns used throughout roncoo-pay
• EasyQuant/EasyQuant — Alternative Java payment gateway supporting multiple Chinese payment providers with similar microservice architecture
• xuxueli/xxl-job — Distributed job scheduling system often paired with roncoo-pay for reconciliation and settlement batch jobs
• alibaba/spring-cloud-alibaba — Cloud-native extension for Spring Boot payment systems; roncoo-pay could migrate to this for Nacos service discovery
• wechat-sdk/wechat-sdk-java — WeChat Pay SDK integration library; roncoo-pay uses this internally for WeChat payment channel

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 integration tests for NotifyTask and PollingTask message processing

The roncoo-pay-app-notify and roncoo-pay-app-order-polling modules contain critical async processing logic (NotifyTask.java and PollingTask.java) that handle payment notifications and order polling. No test files are visible in the repo structure. These are core async flows that need integration tests with ActiveMQ to ensure message reliability and proper persistence via NotifyPersist.java and PollingPersist.java.

• [ ] Create roncoo-pay-app-notify/src/test/java/com/roncoo/pay/app/notify/core/NotifyTaskTest.java with embedded ActiveMQ testing
• [ ] Create roncoo-pay-app-notify/src/test/java/com/roncoo/pay/app/notify/message/ConsumerSessionAwareMessageListenerTest.java
• [ ] Create roncoo-pay-app-order-polling/src/test/java/com/roncoo/pay/app/polling/core/PollingTaskTest.java with mock order polling scenarios
• [ ] Create roncoo-pay-app-order-polling/src/test/java/com/roncoo/pay/app/polling/listener/PollingMessageListenerTest.java
• [ ] Add test dependencies to respective pom.xml files (spring-boot-starter-test, activemq-broker, h2-database)

Add comprehensive unit tests for ReconciliationTask business logic

The roncoo-pay-app-reconciliation module contains five critical business classes (ReconciliationCheckBiz.java, ReconciliationDataGetBiz.java, ReconciliationFileDownBiz.java, ReconciliationFileParserBiz.java, ReconciliationValidateBiz.java) that handle the entire reconciliation workflow. No test files are visible. These services are essential for financial accuracy and require thorough unit test coverage.

• [ ] Create roncoo-pay-app-reconciliation/src/test/java/com/roncoo/pay/app/reconciliation/biz/ReconciliationFileParserBizTest.java with sample file parsing scenarios
• [ ] Create roncoo-pay-app-reconciliation/src/test/java/com/roncoo/pay/app/reconciliation/biz/ReconciliationDataGetBizTest.java with mock payment gateway responses
• [ ] Create roncoo-pay-app-reconciliation/src/test/java/com/roncoo/pay/app/reconciliation/biz/ReconciliationValidateBizTest.java for data validation logic
• [ ] Create roncoo-pay-app-reconciliation/src/test/java/com/roncoo/pay/app/reconciliation/biz/ReconciliationCheckBizTest.java for discrepancy detection
• [ ] Add @MockBean annotations for external payment gateway clients (Alipay, WeChat)

Create GitHub Actions CI/CD workflow for multi-module Maven build and test

The project is a complex multi-module Maven build (11 modules listed in pom.xml) with no visible .github/workflows directory for automated testing. Given the financial-critical nature of payment systems, a robust CI pipeline is essential. This should validate all modules build correctly, run tests, and check for dependency vulnerabilities.

• [ ] Create .github/workflows/maven-build-test.yml with Maven build for all modules
• [ ] Add JDK 8+ matrix testing (given Spring Boot 2.1.2 base version)
• [ ] Include OWASP dependency-check step to scan for CVEs in fastjson 2.0.8, druid 1.1.13, and alipay-sdk
• [ ] Add test coverage reporting step (JaCoCo or Codecov integration)
• [ ] Create .github/workflows/code-quality.yml with SpotBugs analysis for roncoo-pay-service,

• Add Java unit tests for roncoo-pay-common-core utility classes (currently no src/test directory visible)—payment systems require high test coverage for money handling logic. Start with testing the amount/decimal precision utilities used by financial calculations.
• Create docker-compose.yml at repository root that spins up MySQL, Redis, and ActiveMQ containers with the correct database.sql pre-loaded—currently deployment requires manual service setup and is barrier to local testing. See application.yml files to identify exact broker/DB config.
• Document the exact flow between roncoo-pay-web-gateway payment API request → roncoo-pay-service business logic → ActiveMQ message → roncoo-pay-app-notify merchant callback with code examples; README only has architecture diagram. Add sequence diagrams under docs/ folder.

Failed to generate security analysis.

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.