When an EWA system must stop a transaction for review
An EWA system should stop or hold a transaction unless it has enough evidence that the request involves the right worker, approved work, the current amount, the verified account and no duplicate payment. The safe rule is fail-closed: do not guess when critical data is uncertain.
Stopping a transaction is not a failure
A sound financial system is not measured by always letting requests through. It should stop when work data conflicts or was edited without reapproval, the account is pending verification, the amount changed, an earlier payment is pending, a duplicate is suspected, the bank status is unclear, or a critical source is unavailable.
The purpose of a stop condition is to prevent uncertainty from becoming a real financial loss.
Group 1: Work data is not reliable enough
Stop when approved work is missing, work was edited, two sources disagree, a record may be duplicated, a timekeeping code does not match the worker, a shift or date is unresolved, or a transfer has left the assignment unclear. Work data creates earned value; uncertain work makes the amount uncertain.
Group 2: The requested amount no longer matches server data
The amount shown at time A may change before confirmation because work was edited, another payment succeeded, cycle-to-date withdrawals increased, a policy version changed, or the configured reserve changed. The server must recalculate. It must not honor a stale screen value above the new eligible amount.
Group 3: The receiving account is not eligible
Stop if the account awaits verification, the holder name does not match, the account was recently changed, related identity checks are pending, or the account is no longer valid. Sending first and correcting later can pay the wrong recipient.
Group 4: A previous transaction is still being processed
If the same worker already has a transaction against the same value in processing, pending or unknown status, a new request can duplicate payment. Lock that value so a second flow cannot reuse it. Concurrency control and idempotency must work together.
Group 5: Timeout or unclear bank status
A timeout is not a failure result; the bank may have processed the instruction before its response was lost. The safe sequence is:
- keep the transaction pending;
- do not create a new reference;
- do not release the value;
- investigate;
- verify independent evidence;
- conclude only when the evidence is sufficient.
Never retry movement of money simply to see what happens.
Group 6: Duplicate-transaction signals
Stop for the same request ID, the same idempotency key, an unusual same-worker/same-amount/time pattern, two processes reserving the same value, or a completed instruction submitted again.
A duplicate signal does not prove fraud, but it is enough to require review.
Group 7: The applicable policy version cannot be determined
The Eligibility Engine must identify the active customer policy, effective date, limit, reserve and usage right. It must not silently fall back to an unconfirmed default. An unknown policy is a stop condition.
Group 8: The worker is no longer in an eligible status
Stop when employment ended, the assignment expired, a transfer is incomplete, the profile is locked under procedure, or the relevant payroll cycle closed. Use time-effective status, not a generic current status.
Group 9: A critical source system is failing
Examples include unavailable work data, a nonresponsive Eligibility Engine, disconnected Payment Orchestration, interrupted account verification, or unverifiable bank data. Scope the stop to what is affected: one customer's faulty work source need not stop other customers.
Group 10: The emergency stop is activated
Serious duplicate-payment suspicion, a wrong recipient, widespread calculation errors, a security incident, or inability to determine transaction status may require blocking new instructions. Activation and release rights must be limited, logged, appropriately approved and tied to reopening criteria. Ordinary admins should not control money flows without an audit trail.
How do stop, hold and reject differ?
| Outcome | Use when | Example |
|---|---|---|
| Reject | A requirement clearly fails | No eligible approved work |
| Hold | Evidence is incomplete | Bank timeout |
| Stop flow | A broad system risk exists | Widespread duplicate-payment suspicion |
| Request data correction | Source data is wrong | Incorrect timekeeping code |
| Request reverification | Identity or account is uncertain | Account change |
Do not label every outcome as a failed transaction.
What message should the worker see?
State the truth without ambiguity, do not ask for an immediate resubmission while pending, provide a reference, and explain the next step. For example: “Your request is under review. Do not create another request for the same amount until a result is available.” Do not show “failed” while the status remains unknown.
Who may override a stop condition?
Very few stop conditions should be bypassable. Any manual exception needs elevated authority, a reason, an approver, logs, limited scope and post-action evidence. Avoid a universal superadmin override for money controls.
What should a stop-condition dashboard track?
Track held requests, hold reasons, transaction age, pending counts, duplicate signals, accounts awaiting verification, work edited after approval, manual overrides, emergency-stop use and reopening time. A sharp increase in one condition points to a root cause that needs correction.
Conclusion
An EWA system must know when not to continue. Key stop conditions include uncertain work data, a changed amount, an account awaiting verification, a pending prior transaction, duplicate signals, unclear bank status and system failures. Fail-closed is not weakness; it ensures money moves only when data and state are sufficiently certain.
Author: Do Huy Le — General Director, Nhan Kiet Manpower Supply Co., Ltd.
EWA consulting for businesses: Hotline 0937.022.655 · Email info@nhankiet.vn · Learn about EWA for businesses
FAQ
Does stopping transactions harm the experience?
It can add waiting time, but that is preferable to a wrong or duplicate payment. Clear status communication is essential.
Should a timeout be treated as failure?
No. Hold and investigate it.
Does every API error stop the entire system?
No. Isolate the affected service, customer or function.
Who can reopen after an emergency stop?
Only roles allowed by the approved process, with logs and review evidence before reopening.