(Medium) Vendor registration success screen: confirmation + next-step CTAs

[EmeditWeb]

Summary

When a vendor finishes registration, the app gives no real confirmation: src/pages/VendorRegister.tsx fires a toast and immediately navigate('/vendors') on success (lines 47–49), so the vendor is dropped onto the browse list with a fading toast as their only signal that anything happened — no confirmation of what they submitted, no next steps (set up products, view their public page), no recovery if they navigated away too fast. This epic replaces the silent redirect with a dedicated success screen that confirms the registration and routes the vendor to the obvious next actions.

Labels

area: web type: feature priority: medium

---

Workstream 1 — Vendor registration success screen

Objective

A clear post-registration confirmation with actionable next steps.

Problem

Success = toast.success(...) + navigate('/vendors') (lines 47–49); the vendor sees no durable confirmation and no path forward.

Scope

• src/pages/VendorRegister.tsx (success handling; render a success state instead of an immediate redirect)
• optionally src/components/vendor/RegistrationSuccess.tsx (new) for the success view

Implementation

1. On mutation.onSuccess, transition the page to a success view (local state or a routed /vendors/register/success) instead of navigating straight to /vendors.
2. The success view confirms the submitted business name/category and offers primary CTAs: "Set up products" (→ vendor dashboard) and "View my vendor page" (→ /vendors/:id when the id is returned), plus a secondary "Back to vendors".
3. Keep the existing toast.success as a lightweight echo; keep toast.error + inline field errors on the failure path unchanged.
4. Handle the case where the API response lacks the new vendor id (hide the "View my vendor page" CTA rather than link to a broken route).

Acceptance Criteria

• After a successful registration the vendor lands on a success screen, not the raw browse list.
• Success screen shows what was registered and at least two next-step CTAs.
• Failure path (validation + server error) is unchanged.
• No dead CTA when the vendor id is absent.

Testing

• Component: a mocked successful registerVendor renders the success screen with CTAs; a rejected mutation keeps the form + shows the error toast; missing-id response hides the vendor-page CTA.

Shared acceptance criteria (whole epic)

• npm run lint, npm test, npm run build all exit 0; test count does not drop.
• No API calls added in the page beyond the existing vendorsService.
• Icons from lucide-react; no hardcoded hex colors.
• Verified at 375px mobile; no console errors; success screen is keyboard-reachable.

Security & compatibility considerations

• Presentational; no funds or signing.
• Do not echo raw server error text into the success UI; keep server detail in the existing error toast/log path.
• Escape/sanitize the vendor-supplied business name before rendering it back on the success screen.

References

• src/pages/VendorRegister.tsx — current toast + redirect on success (lines 40–52), submit button (line 210).
• src/hooks/useToast.ts — existing toast used for the echo.
• src/services/vendors.service.ts — registerVendor(data).
• src/router/index.tsx — vendor routes (/vendors, /vendors/dashboard, /vendors/:id).

If you're solving this with AI

Give your AI assistant this entire issue and hold it to exactly this scope. A tight boundary is the difference between a mergeable PR and a rejected one.

In scope — the AI may create or modify only these:

• src/pages/VendorRegister.tsx, src/components/vendor/RegistrationSuccess.tsx (new), and a success route in src/router/index.tsx only if you choose the routed approach
• test files for the above

Out of scope — the AI must NOT touch:

• Any StepFi-Contracts / Rust / Soroban code, or StepFi-API code
• The vendor registration validation/submission contract (fields, service signature), auth/signing, or wallet flows
• Unrelated pages or .github/ workflows
• Introducing new dependencies, or any any types

The AI must: follow the PR template exactly, keep CI green (npm run lint, npm test, npm run build all exit 0), not reduce the test count, add tests, and reference this issue number in the PR. If the fix seems to need a file outside "In scope", stop and comment on this issue instead of widening the change.

---

Contribution requirements: Reference this issue number in your PR, follow the repo PR template exactly → https://github.com/StepFi-app/StepFi-Web/blob/main/.github/pull_request_template.md — keep CI green, and never commit secrets. Good first contribution? This is a single focused workstream.

[Shreya657]

Hi! I'd love to work on this issue. Could you please assign it to me if it's still available? Thanks!

[rupesh-kumar-sah]

Hi everyone,

I would like to resolve this issue. Here is my proposed execution plan:

• Implementation: Deliver a clean, modular solution for feat: add vendor registration success screen strictly following StepFi-app/StepFi-Web conventions.
• Testing: Cover changes with automated tests ensuring CI passes smoothly.

Excited to work on this—please assign to me and I'll submit a clean PR shortly!