Built from a full read of the WeavoPay-main repository on 2026-08-23, branch fix/apex-canonical-host-redirect, HEAD 55ff2d8. No code was modified.
Every note follows the same six sections: current implementation → important files/modules → architecture decisions → known limitations → open questions → evidence from the repository.
# | Note | Start here if you want to know… |
|---|---|---|
1 | How the system is shaped; the two-payment-path split | |
2 | Which selector actually runs, and why the others don't | |
3 | Hosted vs. WeavoPay-rendered UPI; the | |
4 | Why PhonePe is not routable, and the three senses of "PhonePe" here | |
5 | The primary acquirer, its three code paths, and what's blocked | |
6 | "ONE checkout, not two"; the three-tier fallback; CSP | |
7 | Fixed vs. Counter QR, risk caps, the concurrency claim | |
8 | All ten rails in one table: fees, currencies, shapes | |
9 | States, the ledger, the three sweeps, settlement inversion | |
10 | Why the browser SDK is real and the rest are stubs | |
11 | Health, cascade, prediction, shadow mode, model checking | |
12 | 1,882 tests, the CI gates, and the suite's own standards | |
13 | The synthesis. Read this one first if you only read one |
1. The sophisticated parts are not the parts handling traffic. Method-level capability routing, composite scoring, predictive approval, settlement inversion and the custom UPI panel are all built and tested, and all either flag-off or unwired. This is deliberate — every flag documents why it defaults OFF — but it means "what the code can do" and "what production does" are different questions with different answers.
2. The codebase documents its own gaps unusually well. Most of note 13 is an index, not a discovery. Module docstrings record the bug they exist to fix, the incident that produced them, and what would still be needed. Where this note set adds value it is mostly by connecting facts stated separately — e.g. that phonepe_uat.py lives in app/rails/ but implements no rail interface.
3. The recurring failure mode is "looks fine, moved nothing." Phantom revenue (PayU), a real charge reported as failed (missing passthrough), refunds accepted and never sent, a test printing PASSED without asserting. moves_real_money, rail_live, the connector error taxonomy and the test-removal guard are all structural answers to this one shape.
~50.5k lines of Python under app/; app/api/main.py alone is 10,169 lines
52 Alembic migrations, latest 0051_transaction_rail_live
177 test files, ~1,882 test functions
Ten routable rails; three of them India-focused (Cashfree, PayU, razorpay_route)
Deployed at weavopay.online on Railway
Authoritative in-repo docs: SPEC.md, CONTRIBUTING.md, docs/custom-upi-rollout.md, docs/settlement-inversion-rollout.md, docs/research/weavopay-orchestration-architecture-paper.md
Ask Claude Code to search Fabric for the area you're working in before starting — each note's evidence section gives file:line anchors to jump straight to, and the open questions sections are the live agenda rather than settled facts. Verify a named file or flag still exists before acting on it; this is a snapshot of 2026-08-23, and flags in particular live in Railway, not in the code.