Interaction flows (A–H)
Screen-level flows for Payment Reconciler UX—aligned with domain language (incoming/expected transactions, merchant, matches).
These flows complement user journeys. Legend: [Admin] can change data; [Viewer] read-only.
Vocabulary: Use incoming transaction, expected transaction, merchant, match, accept / reject in UI (see overview).
Flow A — Resolve one incoming transaction (core)
Intent: Move one incoming from “needs work” to matched or clearly unmatched.
Entry: Incoming queue (e.g. pending / needs review).
| Step | Screen / action | Roles |
|---|---|---|
| 1 | Incoming detail — amount, currency, merchant, transaction date, reference, description, source (manual, Stripe, CSV, EBICS), direction if shown. | Admin, Viewer |
| 2 | Run matching (if not automatic). | Admin |
| 3 | Match suggestions — ranked links to expected rows; confidence + explanation. | Admin, Viewer |
| 4 | Accept or reject (optional reason). | Admin |
| 5 | Return to queue; status matched / pending / unmatched. | Admin, Viewer |
Empty states: No suggestions → point to expected data or field mapping; several strong candidates → emphasise review.
Diagram — Flow A
Flow B — Go live with Stripe (card data source)
Entry: Data sources — add Stripe.
| Step | Screen / action | Roles |
|---|---|---|
| 1 | Create data source — API key, optional webhook secret. | Admin |
| 2 | Field mapping for source stripe → incoming fields. | Admin |
| 3 | Sync now or via schedule. | Admin |
| 4 | Sync log — fetched count, created rows, errors. | Admin, Viewer |
| 5 | Incoming list — new rows pending. | Admin, Viewer |
Exit: Flow A per row.
Diagram — Flow B
Flow C — Go live with bank (EBICS-style)
| Step | Screen / action | Roles |
|---|---|---|
| 1 | Start EBICS init (IDs, bank, security inputs). | Admin |
| 2 | Download bank letter → offline bank step. | Admin |
| 3 | Waiting state with clear next steps. | Admin, Viewer |
| 4 | Complete init after bank activation. | Admin |
| 5 | Import / sync; field mapping for ebics if needed. | Admin |
| 6 | Incoming queue → Flow A. | Admin, Viewer |
Diagram — Flow C
Flow D — CSV upload → incoming rows
| Step | Screen / action | Roles |
|---|---|---|
| 1 | Confirm field mapping for csv. | Admin |
| 2 | Upload file (delimiter, size limits, preview if available). | Admin |
| 3 | Result — rows created, parse errors per line if any. | Admin, Viewer |
| 4 | Incoming list → Flow A. | Admin, Viewer |
Flow E — Expected transaction lifecycle
| Step | Screen / action | Roles |
|---|---|---|
| 1 | List with filters (date, merchant, reference, status if any). | Admin, Viewer |
| 2 | Create or edit — merchant, amount, currency, expected date, reference, description. | Admin |
| 3 | Delete or deactivate per product rules. | Admin |
| 4 | Optional import / bulk. | Admin |
| 5 | Done: Pool stays clean for matching. | — |
Flow F — Field mapping maintenance
| Step | Screen / action | Roles |
|---|---|---|
| 1 | Pick source (stripe, csv, ebics, …). | Admin |
| 2 | Map to incoming targets (merchant, amount, currency, date, reference, description, direction). | Admin |
| 3 | Save; optional test with sample payload. | Admin |
| 4 | Done: Next sync/upload uses new rules. | — |
Flow G — Webhook lifecycle
| Step | Screen / action | Roles |
|---|---|---|
| 1 | Create webhook (URL, headers/secrets, event types as you define). | Admin |
| 2 | Test send; inspect response. | Admin |
| 3 | Delivery list — success/failure, retries. | Admin, Viewer |
| 4 | Edit or delete when endpoints change. | Admin |
Flow H — API key for automation
| Step | Screen / action | Roles |
|---|---|---|
| 1 | Create key for tenant + environment; copy secret once. | Admin |
| 2 | Document required headers for integrators. | Admin |
| 3 | Rotate / revoke when people leave or scripts change. | Admin |
Flow I — Job operations
| Step | Screen / action | Roles |
|---|---|---|
| 1 | List jobs by type and status. | Admin, Viewer |
| 2 | Open job — error text, timestamps. | Admin, Viewer |
| 3 | Trigger ad hoc, cancel running, or wait for schedule. | Admin |
Journey ↔ flow map
| Journeys (stories doc) | Flows |
|---|---|
| 4 Data sources | B, C, D |
| 5 Field mappings | F (also inside B, C, D) |
| 6 Expected transactions | E |
| 7 Manual incoming | D (partial), plus create incoming step in journeys §7 |
| 8–10 Matching & matches | A; browse matches = journey §10 |
| 11–12 Automation & jobs | I |
| 13 Webhooks | G |
| 14 API keys | H |
Figma / workshop tip
Use one row per flow (A–I) in a matrix: Entry → Steps (bullets) → Exit → Primary unhappy paths. You do not need a Mermaid diagram for every flow—tables above are enough to start screens.
See Figma handoff for personas and swimlanes.