Skip to content

Strengthen payment security (iteration 11) #1186

Description

@dev-stephenx

Context

Ongoing strengthen payment security initiative for AgenticPay, tracked as one of several planned iterations to keep scope manageable and reviewable.

Proposed work

Deliver the next increment of: Strengthen payment security. Break the work into a focused, reviewable change set.

Acceptance criteria

  • Scope is clearly defined in the PR
  • Tests added or updated
  • Documentation updated where relevant

Activity

  1. innocentharuna commented on Oct 17, 2026

    @innocentharuna

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

    hey maintainer, please kindly assign this to me, i can surely fix it

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

  2. Obaara293 commented on Oct 17, 2026

    @Obaara293

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

    Hi maintainer, I've reviewed the issue and I've recognized the solution, kindly assign this to me to get the best result.

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

  3. SagaciousBoss commented on Oct 17, 2026

    @SagaciousBoss
    Contributor

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

    I would love to apply for this issues , I can handle it .

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

  4. drips-wave commented on Oct 17, 2026

    @drips-wave

    Congratulations, @SagaciousBoss! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on October 22, 2026.

    🧑‍💻 @SagaciousBoss: 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 🌊

  5. SagaciousBoss commented on Oct 17, 2026

    @SagaciousBoss
    Contributor

    Delivered in #1290 (merged).

    Payment security work in that PR:

    • Every /api/v1/payouts route — including the read routes — now requires an authenticated principal holding finance_approver or admin. The check runs before any lookup, so an unauthenticated caller cannot use the status code to probe which batch ids exist.
    • The approver role is enforced twice: once in the route and again inside PayoutEngine on every decision, so a caller that reaches the engine by another path is not less protected.
    • Idempotency-Key on every money-moving route. Reusing a key with a different body is rejected with 409 idempotency_key_reuse_mismatch instead of silently replaying the earlier response, and the rejected request is not applied.
    • The response cache is bounded (DEFAULT_MAX_CACHE_ENTRIES = 10_000, oldest evicted first), so a flood of unique keys cannot exhaust memory.
    • Strict input allowlists on the new API: assets restricted to USDC / USDT / XLM / EURC, schedule cadence restricted to daily / weekly / monthly / threshold, amounts positive/finite and capped at 1_000_000, identifiers non-empty and bounded to 128 characters.
    • The asset allowlist and the amount ceiling are enforced in the engine as well as the route, so a caller that reaches PayoutEngine directly cannot pay an unlisted asset or an unbounded amount.
    • Route-scoped rate limits on top of the global /api limiter: 120 requests/minute for the router, 30 requests/minute for approve / reject / retry / release. evaluate and retries fan out to the settlement rail, so an unthrottled caller could turn a rail hiccup into a payout stampede.
    • Engine sentinel errors are mapped to sanitised HTTP responses; rail error text never reaches the client and the stack is only attached outside production by the shared errorHandler.
    • Fiat conversion hardening: conversions are capped at MAX_FIAT_CONVERSION_AMOUNT, settlement destinations must match the Stellar address format, and settlement references are now derived from hash(destination | amount | asset) instead of Math.random() so they reconcile against the chain.

    Tests: new routes/__tests__/payouts.test.ts asserts authentication on every route including reads, role enforcement, validation, idempotency replay vs mismatch, the approve/reject lifecycle, and that the rate limiter is wired. Additional fingerprint and cache-eviction tests in middleware/__tests__/idempotency.test.ts.

    Docs: docs/security/payment-security.md.

  6. drips-wave commented on Oct 17, 2026

    @drips-wave

    This issue has been completed by @SagaciousBoss as part of the Stellar Wave Program's 10th Wave 🥳

    😎 @SagaciousBoss: You earned 200 Points for completing this issue! Once the Wave's rewards are finalized, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

    🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.

  7. added a commit that references this issue on Oct 17, 2026
    bbdef79
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave program

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions