Skip to main content

Merchant portal — screen specifications

Status: Proposed MVP UX contract. All data is merchant-scoped. Display financial status separately for bill, collection, settlement and payout.

Primary navigation: Dashboard, Customers, Bills, Collections, Payouts, Sparelane Invoices, Integrations, Team, Settings. Roles: OWNER, ADMIN, FINANCE, OPERATIONS, DEVELOPER, VIEWER. Exact RBAC permissions require approval; never grant access solely because a user knows a merchant ID.

M01 — Dashboard​

Purpose: Understand upcoming collections, failures and outstanding financial actions.

  • Cards: bills due in next 7/30 days; scheduled collection amount; collected amount; failed collection amount; funds awaiting settlement; funds awaiting payout; last completed payout.
  • Filters: date range, collection status, merchant entity if multiple are supported.
  • Table: recent exceptions with bill reference, customer reference, issue type, timestamp, assigned owner and action.
  • Actions: view bills, view collections, export permitted summary, open exception.
  • States: loading skeleton, empty/no bills, provider delayed, partially reconciled, stale data warning.
  • Acceptance: values have defined time basis and never label authorised but unsettled money as available for payout.

M02 — Customers​

  • Table: merchant customer reference, masked consumer name/contact, linking status, mandate status, next scheduled bill and last payment outcome.
  • Actions: invite/link, resend invitation subject to limits, open relationship detail, disable merchant customer link.
  • Validation: merchant external customer ID unique per merchant; invitation expiry; no identity matching by email alone.
  • Acceptance: a merchant cannot view methods or relationships belonging to another merchant.

M03 — Bills​

  • Table: external bill ID, customer reference, amount, due date, current bill version, collection status, payout status, created timestamp.
  • Detail: immutable bill versions, attempts, notices, settlement and payout references, event timeline.
  • Actions: create, upload/import if supported, cancel if eligible, view integration payload, export.
  • Form: merchant customer ID, external bill ID, amount in AUD, due date, description and optional metadata.
  • Validation: positive minor-unit amount; due date/cutoff; active merchant/customer; duplicate external ID; mandate and billing eligibility.
  • Acceptance: repeated submissions cannot produce duplicate collection; cancellation of in-flight payment must be reported as pending or unavailable, never falsely completed.

M04 — Collections and recovery​

  • Table: bill, payment attempt, method category (masked), outcome category, next action, retry eligibility and timestamps.
  • Detail: provider-safe status, chronological attempts, unknown-outcome hold, fallback decisions, exception owner.
  • Actions: view, download report, open support case. Manual retry is privileged, policy-constrained and audited.
  • Acceptance: a failed attempt and failed overall collection are visibly different.

M05 — Payouts​

  • Table: batch ID, eligible amount, reserved amount, submitted amount, completed amount, date, destination (masked), reconciliation status.
  • Detail: per-bill allocation, provider payout reference, fee treatment (separate invoice), returns/adjustments.
  • Actions: download remittance, export allocations, raise discrepancy.
  • Acceptance: only confirmed payout completion appears as paid; no card/bank credentials shown.

M06 — Sparelane invoices​

  • Table: billing period, subscription, success fees by method, GST, total, status and invoice download.
  • Detail: fee assessments linked to successful collections, effective-dated pricing agreement and adjustment history.
  • Acceptance: merchant collection payouts are not netted against Sparelane service fees under preferred Model 2.

M07 — Integrations​

  • Sandbox/production environments, credential issuance/rotation, webhook endpoints, event subscriptions, recent delivery logs, signature verification guide, test events and retry/replay tools.
  • Production credentials visible only at creation; store hashes or managed secrets rather than retrievable plaintext.
  • Acceptance: webhook replay never re-initiates financial collection.

M08 — Team and settings​

  • Invite/disable users; role assignment; MFA status; session revocation; legal/business profile; approved payout destination; notification settings.
  • High-risk payout destination changes require re-verification, step-up authentication, independent approval and audit.
  • Acceptance: a user cannot approve their own high-risk change if dual approval policy applies.

Shared screen rules​

Every list uses server-side pagination and scoped filters. Use accessible forms, clear Australian date/currency formatting, non-sensitive audit history, loading/error/empty states, export permissions and traceable request IDs. Confirm irreversible actions with explicit consequence language.