Payment review: evidence before action
Applying experience with internal billing tools to one workflow: investigating a payment problem. Connected records, status evidence and the next review step in one workspace.
Payment operations · Real internal-tool experience + independent design study · 2026
A customer says they paid for a subscription, but access has not appeared. Finding a red row in a table is not enough. The operator needs to know whether payment completed, which attempt is current and what can happen next.
At Semrush, I worked on internal billing interfaces: the payment list, suspicious-payment checks, trial-abuse review and chargeback workflows. In this study, I developed one workflow—investigating a payment problem—into an interactive prototype. My professional experience provides the context; the new workspace and comparison below are independent work.
These numbers describe the implemented prototype model. Changes in investigation time and recovered payments have not been measured.
Open the interactive demo · Русская версия
Experience behind the design
Billing-interface work provided several views of a payment problem: finding operations, reviewing risk, analyzing refund reasons and handling customer-facing states. This study connects them around the operator’s task.
| Previous work | How it informs this study |
|---|---|
| Payment-list and internal payment-operations work | Choosing an operator workflow |
| Fraud review, trial abuse, chargebacks, bulk actions and reusable filters | Separating finding a set of operations from investigating one operation |
| Refund-reason analysis using Python, API export and clustering | Attention to explanation and the limits of interpretation |
| Processing, error and card-replacement designs | Separating waiting for an outcome, a decline and the next action |
Payment Investigation View is a new prototype informed by that experience. Its rollout and effect on operators remain to be evaluated.
The problem: having data still leaves a conclusion to make
The working hypothesis is that operators lose context when payments, customers, invoices and provider events appear as separate technical records. Checking each record does not yet answer whether payment has failed.
For comparison, I built a reconstruction with four panels: Payment details, Customer, Invoice and Provider events. They show the same synthetic case through separate views.
I limited the scope to one investigation. Payment search, bulk review and fraud scoring remain adjacent workflows. Testing the context model does not require rebuilding the entire admin system.
Decision 1. Organize evidence around the payment problem
The proposed view shows the amount, current states, related invoice and subscription, latest attempt outcome, explanation and next review step. Technical fields remain available in a disclosure below.
The reading order follows the decision: what is known → whether the sources agree → what needs checking or explaining next.
A payment cannot be reduced to its last error row. An earlier attempt might have failed while the next one is processing or has succeeded. The attempt outcome is therefore separate from the current payment object.
Decision 2. Separate states that answer different questions
| Object | Question | Demo example |
|---|---|---|
| Payment | What does the provider currently report? | Requires action / Processing / Succeeded |
| Invoice | Does the internal ledger confirm payment? | Unpaid / Paid |
| Subscription | What is the access state? | Awaiting payment / Active / Pending sync |
| Attempt | What happened in this specific attempt? | Declined / Action required / Succeeded |
The model is informed by public provider documentation, rather than a reconstruction of a company’s private API. Stripe, for example, distinguishes requires_action and processing; a declined attempt can return the object to requires_payment_method. PaymentIntent lifecycle.
The prototype labels operational uncertainty as Needs reconciliation. This describes agreement between sources, rather than an additional Stripe status.
Decision 3. Expose conflicts while limiting actions
The most important example is a successful provider payment with an unpaid internal invoice. A single Failed badge would hide the discrepancy and might encourage another attempt.
The proposed first release covers diagnosis and context preparation. It creates no charges, refunds or payment links. The summary button works locally without sending data.
For future financial commands, permission shown in the UI would be insufficient. The server must check authorization, current state and repeated requests. Idempotency belongs to that server contract. Stripe’s idempotent requests.
Decision 4. Separate delivery order from current state
In the seventh scenario, an old failure event arrives after success was confirmed. The current state comes from a separate object snapshot; the timeline explains the delivery history.
Stripe does not guarantee webhook delivery order. Timestamps alone also do not establish a complete order and cannot be the sole basis for current state. Event delivery behavior.
The demo has no real provider reconciliation mechanism. The scenario supports checking whether someone understands why the last received message should not automatically overwrite the payment state.
Seven scenarios rather than one ideal screen
| Scenario | What an operator must distinguish |
|---|---|
| Authentication required | Customer action from final failure |
| Declined attempt | Available decline information from an unknown bank reason |
| Processing payment | Waiting for an outcome from failure |
| Conflicting sources | Provider evidence from internal accounting |
| Confirmed payment | Reconciled payment, invoice and access |
| Partial refund | The original successful payment from its refund |
| Delayed event | Message delivery from the current object snapshot |
The trade-offs serve the workflow: a short explanation for Support with detail available to Billing; an honest unknown reason instead of confident invented text; diagnosis before adding money-moving actions.
What is implemented and checked
The working prototype has two presentations and seven synthetic datasets. It passed automated verification of 42 combinations: 7 scenarios × 2 presentations × 3 widths—1440, 960 and 390 px. It checks displayed states, switching, evidence disclosure, summary preparation and the absence of financial requests.
This verifies the prototype implementation. User understanding, diagnosis time and the quality of the next action need a separate study.
The next-stage plan is six participants and four comparable cases in both presentations: 48 task executions, with counterbalanced order. Measures should include median time to a supported conclusion, correct next steps, use of other panels and interpretation of uncertainty. Fewer escalations are useful only if decision quality is preserved.
Outcome
The initial error-card idea became a testable investigation model: connected objects, separate states, evidence provenance and action limits. The prototype makes cases visible where waiting for confirmation or requesting reconciliation is the appropriate outcome.
Payment-operations experience provided the domain foundation. The independent study adds a working interface and scenarios for evaluation. Observing operators is the next step before claiming an effect on their work.