Skip to content

Rebuild payment verification as a multi-step pipeline with typed stages #441

Open

Description

@CemAyyildiz

Context

Verification logic is spread across handlers, Horizon reads, amount helpers, and rejection codes. Partial failures and stage ordering are hard to reason about when one piece changes in isolation.

Goal

Refactor payment verification into an explicit multi-step pipeline (fetch transaction → match destination → match asset → match amount → match memo → attribute → persist PAID) with typed stage results shared by the API, payment monitor, and frontend error mapping.

Work

  • Define stage interfaces and ordered execution with short-circuit on hard failures
  • Map each stage failure to the shared rejection codes (extend only when necessary)
  • Route both monitor auto-PAID and manual verify through the same pipeline entrypoint
  • Update the pay page to consume stage-aware errors without parallel copy
  • Add fixtures for failure at each stage and for full success

Areas involved

Backend verification and routes, shared rejection/stage types, storage paths, payment monitor, pay-page UX, and tests.

Done when

  • Manual verify and monitor call the same pipeline
  • Stage failures are covered by unit tests
  • Pay page still shows correct labels for amount, memo, and destination rejects
  • No duplicate happy-path verify implementations remain

Activity

  1. added
    enhancementNew feature or request
    help wantedExtra attention is needed
    Maybe RewardedIssue may be eligible for a GrantFox reward
    GrantFox OSSIssue tracked in GrantFox OSS
    on Sep 14, 2026
  2. Okorie2000-code commented on Sep 14, 2026

    @Okorie2000-code
    Contributor

    The issue description is crystal clear, and I’d be glad to work on it. I’ll ensure the implementation is clean, tested, and submit a clean PR. Kindly assign it to me. 🙏

  3. guptakumarranjeet150 commented on Oct 3, 2026

    @guptakumarranjeet150

    Hi maintainers,

    I reviewed this issue and would like to contribute the fix.

    Proposed steps:

    1. Audit storage layout and state invariants ensuring strict auth guards.
    2. Implement deterministic state transitions with safe checked arithmetic.
    3. Add hermetic unit and regression tests covering authorized, unauthorized, and boundary edge cases.
    4. Profile instruction and CPU/gas limits under Soroban host environment.

    Let me know if this aligns with the repository guidelines and assign when convenient.

  4. Rodrigoue9 commented on Oct 7, 2026

    @Rodrigoue9

    Hi @maintainers! I'd like to work on this issue. Here is my proposed technical approach:

    Proposed Technical Approach:

    1. Pipeline Architecture: Implement multi-step typed payment verification and late settlement classification using Horizon close_time.
    2. Terminal Invariants: Guarantee durable state transitions without stranded funds or race conditions.
    3. Integration Tests: Provide unit and integration suites testing timeout, cancellation, and settlement branches.

    Key Files:

    • src/** (pipeline handlers and invoice monitors)
    • tests/**

    Verification & Testing:

    • Run cargo test / npm test with 100% clean check.

    Relevant Track Record:

    I have successfully implemented and merged multiple production PRs across the Stellar ecosystem and Web3 open-source projects (e.g., cybermax4200/stellar-did-credit #898 & #900, Bitcoindefi/OpenAO #218, and FindMalek/sonaraem #416).

    Please feel free to assign this issue to me so I can proceed with the implementation. Thank you!

  5. woahwhattheheck commented on Oct 9, 2026

    @woahwhattheheck
    Contributor

    /claim #441

    Original contributor @woahwhattheheck claims the existing typed payment-verification pipeline implemented in PR #575 for issue #441. I request the applicable GrantFox OSS reward review and conditional compensation for my original source contribution. Please confirm acceptance and actual reward allocation, sponsor/platform approval, payout route and expected payment date. The 'Maybe Rewarded' issue label does not establish an award or paid amount. PR #575 remains my existing code carrier; no duplicate submission is requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardenhancementNew feature or requesthelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions