Make the invoice-verification fraud and manual-review thresholds configurable per tenant

[mikewheeleer]

Make the invoice-verification fraud and manual-review thresholds configurable per tenant

Description

src/services/invoiceVerification.js hardcodes the fraud-rejection amount ceiling (~10,000,000) and the manual-review amount (~1,000,000). These literals cannot adapt to different currencies, tenant risk appetites, or limit changes without a code change and redeploy. The thresholds should come from configuration with optional per-tenant overrides.

Requirements and context

• Repository scope: Liquifact/Liquifact-backend only.
• Move the fraud-ceiling and manual-review thresholds into config (env-backed) with documented defaults preserving current behavior.
• Allow a per-tenant override map so individual tenants can have stricter/looser limits.
• Emit a machine-readable reason code alongside any rejection/manual-review decision so downstream handlers can branch reliably.

Suggested execution

• Fork the repo and create a branch
• git checkout -b enhancement/verification-configurable-thresholds
• Implement changes
  • Write code in: src/services/invoiceVerification.js.
  • Write comprehensive tests in: tests/invoiceVerification.service.test.js — assert config-driven thresholds and tenant overrides.
  • Add documentation: document the threshold config and override format.
  • JSDoc the decision function and reason codes.
  • Validate security: ensure overrides cannot be set by untrusted input, only by config/admin.
• Test and commit

Test and commit

• Run npm test and npm run lint.
• Cover edge cases: at-threshold amounts, override present/absent, and invalid config.

Example commit message

feat: make invoice-verification thresholds configurable with tenant overrides

Guidelines

• Minimum 95 percent test coverage for impacted modules.
• Clear, reviewer-focused documentation.
• Timeframe: 96 hours.

Community & contribution rewards

• 💬 Join the Liquifact community on Discord for questions, reviews, and faster merges: https://discord.gg/JrGPH4V3
• ⭐ This is a GrantFox OSS / Official Campaign task and may be rewarded. When your PR is merged you'll be prompted to rate the project — if this issue and the maintainers helped you ship, we'd be grateful for a 5-star rating. Clear questions in Discord and tidy, well-tested PRs are the fastest path to a merge and a reward.

[ayomideaccess]

@ayomideaccess has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I would love to work on this. I'm a backend developer

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ayomideaccess to this issue.

[extolkom]

@extolkom has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Please assign me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @extolkom to this issue.

[drips-wave]

Congratulations, @extolkom! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @extolkom: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊