Inline QR payment success leaves /purchase for standalone result page
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Domain
- frontend
Research direction
Start in frontend/src/views/user/PaymentView.vue around lines 488-496 and trace the PaymentStatusPanel success handler. Add the named regression test for an inline success event, verifying that router.push is not called while recovery cleanup and refresh behavior remain intact. Done means successful inline QR payments stay on /purchase with the success card visible, while other result-page flows still work.
Written by the indexing model from the issue text.
Description
Description
When an order paid through the inline PaymentStatusPanel on /purchase reaches a successful state, the panel already renders its built-in success card. However, the parent onPaymentSuccess handler then unconditionally calls redirectToPaymentResult, so the app leaves /purchase and opens the standalone /payment/result page without the normal layout.
The redirect was introduced in 7914433 together with mobile Alipay precreate deep-link support, but it currently affects every inline status-panel success path. This is reproducible in v0.1.166 and current main.
Relevant code: PaymentView.vue
Steps to reproduce
- Open
/purchase. - Create an inline QR-code payment.
- Complete the payment.
- Wait for polling to report
COMPLETED,PAID, orRECHARGING.
Actual behavior
The route changes to /payment/result, replacing the page with a standalone result view.
Expected behavior
Keep the user on /purchase and leave the existing inline success card visible until the user clicks Confirm.
The dedicated /payment/result route should remain available for flows that actually leave the page, including WeChat JSAPI and payment-provider return/recovery flows.
Proposed fix
Remove the generic status-panel success redirect while retaining recovery-snapshot cleanup, balance refresh, and subscription refresh. Add a regression test asserting that an inline success event does not call router.push.
- Dominant language
- Go
- Stars
- 42.1k
- Forks
- 9k
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 343
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Wei-Shaw/sub2api
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
All issues in Wei-Shaw/sub2api
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100