EWAで勤務日の重複計算と二重支払を防ぐ方法
Preventing duplicate calculation and duplicate payment in Earned Wage Access requires two controls: work data must not be counted twice, and money must not be sent twice. The system needs stable identity keys, duplicate-record rules, used-value tracking, unique transaction IDs, concurrency control, and a fail-closed response when payment status is unclear.
There are two different kinds of duplication
Duplicate work data
A workday or shift appears more than once. Causes may include two source feeds, re-importing a file, two codes for one shift, duplicated client data, or a worker at several workplaces connected with the wrong key.
Duplicate money transaction
One request is sent for payment more than once. Causes may include a second click, unsafe retry, a bank timeout, two processes running together, or an unstable transaction ID.
Stopping only one type still leaves the system exposed to incorrect calculation or lost money.
Layer 1: Use stable identity keys
The system must identify the worker, client, date, shift, data source, and period uniquely. The key must be strong enough to determine whether two records are actually the same.
Using only a worker name creates a high risk of duplicates or wrong matching.
In the Earned Wage Access model, the worker national ID is the worker key; the client has a company_id and a timekeeping code for each workplace.
Layer 2: Check duplicate records before calculation
Before a workday enters the formula, check the same worker, date, shift, workplace, source or equivalent source, and whether a primary record has already been selected.
When two sources provide the same workday, define a priority source or merge rule. Do not add both simply because they came from different systems.
Layer 3: Only approved work creates value
Even when data is not duplicated, unapproved work should not create an available amount.
Available amount = (approved workdays × daily rate) − amount already received in the period − amount retained under the employer policy.
Approved work reduces the chance that an incorrect or duplicate record enters the money flow.
Layer 4: Mark value that has already been used
After a successful transaction, the system must remember which work value created the paid amount.
This prevents the same workday from being calculated as new, the received amount from being carried into the next period as unused, and final payroll from paying the full value as if nothing had been received.
This layer connects work data to the transaction ledger.
Layer 5: Give every request a unique transaction ID
When a worker submits a request, create an immutable transaction ID. If the same request is sent again because of a network error, the system recognizes it as the same transaction.
This is commonly called idempotency.
The goal is: one business request, even if sent many times, creates only one valid financial result.
Layer 6: Control concurrent processing
Two processes may read the same available amount at almost the same time and both decide that the worker is eligible.
For example, with an available amount of 1,000,000 VND, two requests of 800,000 VND could both see the same balance and both pay if there is no lock.
The system needs a lock or concurrency control so only one process updates the balance at a time.
Layer 7: Make timeouts fail closed
If a payment order was sent to the bank but the system did not receive a clear response:
- do not conclude automatically that it failed;
- do not reopen the amount immediately;
- do not send another order for the same value;
- keep the transaction pending;
- investigate until there is evidence.
The principle is: slow confirmation is safer than paying twice.
Why can automatic retry be dangerous?
Retry is useful for many APIs, but money transfer needs conditions. If the first payment actually succeeded and the response was lost, retry can create a second order.
Before retrying, confirm whether the bank supports an idempotency key, whether the reference stays the same, whether the old status was investigated, and whether there is evidence that the first order failed.
Never retry blindly.
How does reconciliation detect duplication?
At the end of the day or cycle, compare the EWA transaction ledger, bank statement, and payroll or amount received.
Warning signs include two statement lines for the same worker and amount near the same time, a transaction ID appearing more than once, a bank payment without a system record, a system success without a statement entry, or a workday linked to value above its eligibility.
Keep exceptions separate and assign an owner.
What should a duplicate-control dashboard show?
Track suspected duplicate work records, excluded work records, repeated requests, transactions blocked by idempotency, pending transactions, retries, confirmed duplicate payments, EWA-bank differences, workdays used above eligible value, and exception handling time.
Without measurement, the employer cannot know whether the controls work.
What should happen when duplicate payment is found?
Do not delete a transaction just to make a report appear balanced.
Keep both transactions, identify the original and duplicate, reconcile with the bank, identify the technical cause, handle recovery or offset under the approved policy, record the audit trail, fix the system, and review similar transactions.
The goal is to correct the cause, not only the final number.
What should happen when duplicate work is found?
Identify the primary record, exclude the suspected duplicate from calculation, check for related transactions, correct and recalculate if no money moved, reconcile if money moved, and retain the before and after history.
Do not manually erase the evidence.
Conclusion
Duplicate prevention in EWA is a multi-layer chain: use the right identity key, exclude duplicate work, use approved work only, track used value, assign an immutable transaction ID, control concurrency, and fail closed when status is unclear. Combined with reconciliation, these layers greatly reduce the chance that one workday or request creates money more than once.
Author: Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.
Earned wage access advice for employers: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned wage access for employers
よくある質問
Is idempotency enough to prevent duplicate payment?
No. Concurrency control, fail-closed handling, reconciliation, and available-balance controls are also needed.
Is one worker at several clients considered a duplicate?
No, when the data is correct and client or workplace keys are separated. Duplication must be assessed in the full context.
Should a timeout transaction be sent again after a few minutes?
Not before confirming that the first transaction failed. Investigate it first.
Can final payroll detect every duplicate payment?
Do not depend on period end. Duplicate prevention starts when work and transactions are created.