Merchant Payment Support Dashboard: Data and UX Requirements

A merchant support dashboard should help an operator make one correct decision: wait, verify, fulfil, escalate, or communicate. Showing every database field creates noise, while hiding payment evidence pushes staff toward screenshots, informal messages, and direct database edits.

Design the screen around a single tenant-scoped case. Never let a customer-submitted order ID select data across merchants; resolve tenant identity from the authenticated operator context.

Start With the Support Decision

The first viewport should answer:

• Which merchant and environment own this case?
• What order reference can the customer safely quote?
• What amount did the server expect?
• What is the current local payment state?
• What authenticated evidence exists?
• Has fulfilment already happened?
• When was the state last verified?
• What should the operator do next?

Use distinct labels for Awaiting customer, Checking payment, Verified paid, Failed, Expired, and Needs review. Avoid a generic red “error” badge for every unresolved situation.

Order Evidence Panel

Group evidence by purpose:

Group	Useful fields
Merchant order	Safe reference, expected amount, created time, current state
Payment attempt	Gateway order ID, provider, final evidence state, verified amount
Customer journey	Surface shown, return time, last status refresh
Fulfilment	Queue state, completion time, business action reference
Support case	Category, owner, next follow-up, customer message history

Do not show API keys, webhook secrets, provider credentials, UPI PINs, OTPs, or full bank data. Mask customer contact information unless the operator role and support purpose require it.

Screenshots can be attached as customer context under restricted access, but the UI must label them not payment proof. Link staff to the merchant verification checklist.

Event and Delivery Timeline

Display one chronological trail:

1. Local order created.
2. Payment surface returned.
3. Signed event received or backend status checked.
4. Signature and replay result.
5. Event deduplication result.
6. Order state transaction committed.
7. Fulfilment queued and completed.
8. Operator action or provider escalation.

Every row should carry a timestamp, safe actor or component, event/request reference, and result. Group delivery attempts under one event ID so a retry is not mistaken for a second payment. Link authorized engineers to the delivery monitoring guide.

Safe Operator Actions

Prefer actions that gather or reconcile evidence:

• Refresh authenticated status for this known order
• Retry failed fulfilment without changing payment state
• Assign exception category and owner
• Create a provider escalation reference
• Send an approved customer status message
• Copy a safe case summary

A manual paid transition, refund decision, or duplicate-resolution action should require elevated permission and a reason. Show the evidence being relied on before confirmation, then write actor, previous state, resulting state, references, and timestamp to an append-only audit trail.

Never offer a generic “sync everything” button. Broad actions are difficult to authorize, observe, and reverse.

Privacy and Measurement

Record support-screen access and sensitive actions. Apply tenant filters in the backend query, not only the frontend. Time-bound exported case data and avoid exposing internal diagnostics in customer-facing links.

Measure paid-but-pending case count, median resolution time, cases reopened, manual transition rate, duplicate fulfilment, cases without a stable order reference, and top root causes. Do not reward operators only for fast closure; an incorrect paid decision can look fast while creating financial loss.

A good support dashboard converts payment evidence into a controlled next action. It should make the safe path easier than screenshots, guesswork, or privileged database access.

Define role views instead of one universal admin screen:

Role	Typical access
Customer support	Safe order status, approved messages, case ownership
Payment operations	Evidence comparison, reconciliation category, provider case
Engineering	Delivery diagnostics, version, safe technical errors
Finance or approver	Refund and exceptional financial decision evidence
Security administrator	Access review, secret events, audit investigation

An operator should see why an action is unavailable rather than receiving a generic failure after clicking. Permission checks must still run on the backend for every read and mutation. Temporary elevated access needs an expiry, reason, approver, and review trail.