You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rebuild payment verification as a multi-step pipeline with typed stages #441
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
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. 🙏
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.
Activity
Okorie2000-code commentedon Sep 14, 2026
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. 🙏
guptakumarranjeet150 commentedon Oct 3, 2026
Hi maintainers,
I reviewed this issue and would like to contribute the fix.
Proposed steps:
Let me know if this aligns with the repository guidelines and assign when convenient.
Rodrigoue9 commentedon Oct 7, 2026
Hi @maintainers! I'd like to work on this issue. Here is my proposed technical approach:
Proposed Technical Approach:
close_time.Key Files:
src/**(pipeline handlers and invoice monitors)tests/**Verification & Testing:
cargo test/npm testwith 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!
woahwhattheheck commentedon Oct 9, 2026
/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.