Status indicators
Communicating transfer and transaction status clearly across the Senco app. Every status uses triple signaling — color, icon/dot, and text label — so no user relies on a single channel to understand what's happening.
Status is the most-read information in the product. A user opens Senco to answer one question — did it arrive? — and the answer has to be correct, specific, and impossible to misread on a cheap screen in bright light.
Statuses
Senco defines six transaction statuses:
| Status | Color | Meaning |
|---|---|---|
| Pending | Yellow/Amber | Transfer submitted, awaiting processing |
| Processing | Blue | Transfer is being processed by the network |
| Sent | Accent blue | Funds dispatched, awaiting delivery |
| Completed | Green | Funds received by recipient |
| Failed | Red | Transfer could not be completed |
| Cancelled | Gray | Transfer cancelled by user or system |
Each status is rendered as a badge with a colored dot, tinted background, and text label.
Sent is not completed
The most consequential distinction in the system. Sent means the money has left Senco. Completed means the recipient has it. In cross-border transfer those can be two days apart, and a sent payment can still be rejected by the receiving bank.
Green is reserved for completed. Marking a sent transfer green tells a user their family has the money when it may still fail — and there is no message that repairs that once it happens.
Terminal and non-terminal
| Status | Terminal | Can change to |
|---|---|---|
| Pending | No | Processing, Cancelled, Failed |
| Processing | No | Sent, Failed |
| Sent | No | Completed, Failed |
| Completed | Yes | — |
| Failed | Yes | — |
| Cancelled | Yes | — |
Only three statuses are final. The other three are promises the system has not kept yet, and the interface has to keep showing them as in-progress rather than settling early.
Every status carries a timestamp
"Pending" alone is unanswerable — a user cannot tell a transfer submitted two minutes ago from one stuck for two days. Every status shows when it was entered ("Pending since 10:42"), and any non-terminal status older than its expected window surfaces a next step rather than continuing to wait silently.
Triple signaling
Every status indicator uses three redundant signals:
- Color — background tint and text color convey category (success, warning, error)
- Dot/Icon — a filled circle or icon reinforces the color signal
- Text label — the status name is always visible as readable text
This ensures accessibility for color-blind users and provides clarity at a glance.
Why a dot is not enough
Roughly 1 in 12 men has a color vision deficiency, and deuteranopia collapses exactly the green/amber/red axis this product depends on. Under simulation, green-600 and yellow-600 converge to near-identical muted tones — pending and completed become the same chip.
The icon differentiates by shape, and the label differentiates by word. Color is the fastest signal for people who can use it and the only one that fails silently for people who cannot.
| Status | Icon (lucide) |
|---|---|
| Pending | Clock |
| Processing | LoaderCircle |
| Sent | ArrowUpRight |
| Completed | Check |
| Failed | TriangleAlert |
| Cancelled | X |
Usage contexts
| Context | Statuses shown | Notes |
|---|---|---|
| Transaction list | All 6 | Badge appears inline at the end of each row |
| Transaction detail | All 6 | Larger badge at the top of the detail view |
| Notification | Completed, Failed | Push/in-app notifications for terminal states |
| Dashboard summary | Pending, Processing | Highlights items that need attention |
Notifications fire only on terminal states. A push for every intermediate transition trains users to ignore Senco notifications, and the two that matter — it arrived, or it failed — are the two that get missed.
Status in context
Status badges appear in transaction lists alongside recipient name, amount, and date. The badge is right-aligned and uses the compact variant — dot, icon, and label. The icon is not dropped for space; it is what distinguishes Pending from Completed under a colour vision deficiency.
Status is visible without opening the row. The list exists to answer the "did it arrive" question at a glance; a status that requires a tap makes the list a directory rather than an answer.
Do / Don't
- Do use the full badge (color + dot + icon + text label) everywhere status appears
- Don't use a colored dot alone without text — this fails for color-blind users and provides no screen reader information
- Do announce status changes to screen readers via live regions
- Don't rely on color alone to distinguish between pending and processing states
| Do | Don't |
|---|---|
| Mark a dispatched transfer "Sent" in blue | Mark it "Completed" in green because it left |
| Show "Pending since 10:42" | Show "Pending" with no age |
| Notify on completed and failed | Notify on every state transition |
| Say why a transfer failed | Say "Failed" and stop |
| Keep status visible in the list row | Hide status behind a tap |
Use the full badge with colored dot, tinted background, and text label. Triple signaling ensures every user can read the status.
Never use a colored dot alone. Without text, color-blind users cannot distinguish statuses, and screen readers have nothing to announce.
Status timeline
A vertical timeline showing the progression of a transfer through its stages. Used in transaction detail views to show the history of a transfer from initiation to completion.
- Completed steps show a 24px green circle with a white check icon
- Active step shows a 12px primary-colored dot with a pulse animation
- Future steps show a 12px gray dot
- Connecting lines are green for completed segments, gray otherwise
- Each step can include a timestamp and description for additional context
- Uses
aria-current="step"on the active item for screen readers
Usage
| Context | Description |
|---|---|
| Transaction detail | Full 5-step timeline showing transfer progress |
| Transfer confirmation | Simplified 3-step timeline (Send, Process, Deliver) |
A failed timeline stops where it failed
When a transfer fails, the timeline does not grey out or reset. It keeps every completed step, marks the step that failed in --ds-red-600 with an alert icon, and shows the reason inline. The user needs to see how far their money got, because that determines what they do next and what they tell support.
Tokens
--ds-timeline-completed-dot · --ds-timeline-completed-icon · --ds-timeline-active-dot · --ds-timeline-future-dot · --ds-timeline-line-completed · --ds-timeline-line-default · --ds-timeline-pulse-color
- Transfer initiatedApr 2, 2026 09:15 AMYou sent $250.00 USD to Adaeze O.
- Payment confirmedApr 2, 2026 09:16 AMFunds debited from your account
- ProcessingApr 2, 2026 09:20 AMTransfer is being processed by the network
- In transitApr 2, 2026 09:45 AMFunds are on their way to the recipient
- DeliveredRecipient will receive 345,000 KRW
Semantic badge variants
The design system provides semantic badge variants (success, warning, info, destructive) that map to Senco token colors. Use these for general feedback; use the status badges above for transaction-specific states.
The two sets are deliberately separate. A semantic success badge means "this operation worked"; a transaction Completed badge means "the recipient has the money". Collapsing them is how a successful submission ends up rendered as a successful transfer.
Design and accessibility
- Status changes are announced through a polite live region, except a change to Failed, which is assertive
- Color contrast meets WCAG AA in both themes — measured in the canonical table in Transfer components
- Dot is marked
aria-hidden="true"since the text label carries the meaning - Status text uses sentence case (e.g., "Completed" not "COMPLETED")
- Status timeline uses semantic
<ol>withrole="list"for ordered progression - Active timeline step uses
aria-current="step" - Pulse animation respects
prefers-reduced-motion
Announcing a change
A status that changes while the user is looking at it is announced politely — "Transfer to Maria Santos is now completed" — naming the transfer, not just the new state. "Completed" on its own, in a list of six transfers, tells the user nothing about which one.
Failures are announced assertively. They are the one status change that alters what the user should do next.
Offline status
When the app is offline, statuses are shown from cache with their age attached: "Completed · as of 3 min ago". A cached status with no timestamp is the worst possible output here, because a stale "Pending" and a live "Pending" look identical and mean different things.
Known gaps
- Expected-duration windows per status are referenced but not defined per corridor.
- No documented pattern for a status that regresses (Sent → Failed) after the user has already seen the earlier state.
- Notification copy for terminal states is not specified.