UX & product overview
Non-technical overview for designers and product—who uses Payment Reconciler, what they need, and links to journeys and flows.
Who this is for
These pages are written for UX, product, and content design. They describe behaviour and intent in plain language, without API or implementation detail.
Domain vocabulary (use consistently in copy)
Terms below match how the product and API describe data. Prefer these in UI labels, empty states, and help text.
| Domain term | Meaning | Avoid / use only if you add a glossary |
|---|---|---|
| Expected transaction | A payment the organisation expects to receive (amount, merchant, date, reference, description, currency). | Generic “expected payment” is OK in marketing if you define it once. |
| Incoming transaction | A payment that actually arrived (same core fields; source = manual, Stripe, CSV, EBICS). | “Received payment” as a subtitle is fine; keep incoming in tables and filters. |
| Merchant | Name of the other party / payee label on the transaction. | Don’t use “counterparty” unless your compliance team requires it. |
| Match | A proposed link between one incoming and one expected transaction, with a confidence score. | — |
| Accept / reject | Human confirms or declines a match. | — |
| Data source | A configured connection (e.g. Stripe, EBICS) that brings in incoming transactions. | “Integration” only if you standardise on that word everywhere. |
| Field mapping | Rules that map raw provider or file columns into incoming fields (merchant, amount, date, etc.). | — |
| Tenant | The organisation’s isolated space in the product. | “Workspace” is OK in onboarding if you map it to tenant once. |
| Environment | Scope within a tenant (e.g. development, staging, production). | Always visible when it changes behaviour or data. |
Statuses you may surface: incoming — pending, matched, unmatched; match — pending, accepted, rejected (align exact labels with engineering).
The product in one sentence
Organisations record expected transactions and ingest incoming transactions from banks, cards, or files. Payment Reconciler proposes matches between them; people accept or reject those proposals (or use automation where policy allows).
Who uses it
| Person | Plain-language role |
|---|---|
| Super-admin | Platform / internal support: works across tenants; must select tenant + environment before acting; wider user provisioning than a single-tenant org admin. |
| Org admin | Sets up their tenant, environments, data sources, field mappings, matching rules, schedules, webhooks, API keys, and user access for that organisation. |
| Reconciliation user | Day-to-day: maintains expected rows, reviews incoming queues and matches, resolves exceptions. |
| Read-only user | Same visibility, no changes (audit, leadership, support). |
| Automation | Scripts and jobs using API keys—humans need sync logs, job status, and clear errors. |
Your UI can combine org admin and reconciliation user into a single operator role if that fits your customers. Super-admin usually stays separate because scope and risk differ.
Where to go next
- User journeys — Story-style scenarios (broad coverage).
- Interaction flows — Screen-level flows A–H with diagrams where helpful.
- Figma handoff sheet — Personas, swimlanes, and flow index for workshops.
Related technical docs
When you need exact behaviour or field names, use Reconciliation overview, Incoming transactions, Matches, and Match flow.