Repo context. accensa-app is the off-chain half of Accensa — the merchant back-office for x402 sellers on Stellar. Three workspace packages matter: apps/web (Next.js dashboard and the indexer at src/app/api/sync), packages/sdk (@accensa/sdk), and apps/demo-merchant. The Soroban contracts live in accensa-contracts.
🟢 Unblocked. Nothing depends on this landing first, but several other frontend issues become far easier to verify once it exists.
Problem
apps/web has no browser-level test of any kind. The existing suite is Vitest over pure modules — lib/money.test.ts, lib/revenue-analytics.test.ts, lib/payments-csv.test.ts and peers — plus two API route tests. There is no Playwright or Cypress configuration anywhere in the workspace.
The pure logic is well covered. Everything that only exists in a browser is not covered at all: rendering, polling, the payment modal, keyboard interaction, the CSV download, the refund flow's phase transitions, offline handling, theme switching.
That gap is why several defects in this audit — a refund button that stays live mid-submission, rows that cannot be opened with a keyboard, a page that renders nothing while loading — are invisible to CI. They are all trivially detectable in a real browser and undetectable in the current suite.
What to build
Establish the harness and prove it on the highest-value flows.
- Add Playwright to
apps/web with a config that runs against a local build, and wire an e2e script consistent with the existing script naming.
- Decide how backend state is supplied. Mocking
/api/payments at the network layer keeps tests fast and deterministic and avoids a database dependency in CI; a seeded test database is more faithful but heavier. Pick one, justify it in the PR, and make the choice easy to reverse.
- Cover a first set of flows rather than aiming for breadth: dashboard loads and renders payments; a payment opens and closes; the empty state; the error state; CSV export triggers a download; the sync button's cooldown.
- Wire it into CI as a job that can fail the build, and keep it fast enough that people do not learn to ignore it.
- Document how to run and debug it locally — headed mode and trace viewer — in the app README.
Out of scope: the refund flow, which needs a wallet extension and deserves its own issue; and visual regression snapshots.
Acceptance criteria
Contact & Support
Problem
apps/webhas no browser-level test of any kind. The existing suite is Vitest over pure modules —lib/money.test.ts,lib/revenue-analytics.test.ts,lib/payments-csv.test.tsand peers — plus two API route tests. There is no Playwright or Cypress configuration anywhere in the workspace.The pure logic is well covered. Everything that only exists in a browser is not covered at all: rendering, polling, the payment modal, keyboard interaction, the CSV download, the refund flow's phase transitions, offline handling, theme switching.
That gap is why several defects in this audit — a refund button that stays live mid-submission, rows that cannot be opened with a keyboard, a page that renders nothing while loading — are invisible to CI. They are all trivially detectable in a real browser and undetectable in the current suite.
What to build
Establish the harness and prove it on the highest-value flows.
apps/webwith a config that runs against a local build, and wire ane2escript consistent with the existing script naming./api/paymentsat the network layer keeps tests fast and deterministic and avoids a database dependency in CI; a seeded test database is more faithful but heavier. Pick one, justify it in the PR, and make the choice easy to reverse.Out of scope: the refund flow, which needs a wallet extension and deserves its own issue; and visual regression snapshots.
Acceptance criteria
apps/weblocally with one documented command.pnpm lintpasses inapps/web.pnpm testpasses, including new tests covering this change.pnpm buildsucceeds forapps/web.Closes #<this issue>.Contact & Support
SUPPORT.md— contribution help, Wave process, and the full list of channels