Make an unfinished cash payment step visible and resumable. After a card component has already been confirmed, a browser refresh, timeout or staff change must not lead to a new payment or an order that cannot be found. Retain progress against the order and show one clear next action.
Cash payment seems technically simple because there is no provider callback. That means the evidence rests on a human action. The interface must distinguish “not yet checked”, “received by an employee” and “payment fully processed”. An isolated checkbox without identity and timestamp is insufficient for a manageable counter process.
Store status outside the browser tab
Save the remaining amount, already confirmed components and current process step against the order on the server. The browser is only a view. If the tablet crashes, an authorised employee can reopen the same order and see what the provider has already confirmed.
Use an operationally understandable status name, such as “awaiting cash confirmation”. Do not let this status automatically release fulfilment, invoicing or order export while the total remains incorrect. Also make clear that “awaiting” does not mean the money has already been received.
Limit recovery actions
| Action | Condition | Result |
|---|---|---|
| Confirm cash received | Authorised employee and exact remaining amount | Check the total payment |
| Refresh provider status | Card component still uncertain | Current external status, no new attempt |
| Abort payment | No automatic order completion | Review route with visible components |
| Add a technical note | No status change | Context for the next employee |
| Start a new terminal attempt | Only once it is certain the previous attempt did not succeed | New unique payment reference |
Avoid a general “mark paid” button that bypasses every check. If an exceptional manual correction is necessary, give it a separate permission and require a reason. Software can audit the action, but the business must determine its own internal financial procedure.
Also protect the action against double-clicking and two open tabs. Have the server read the current order status, briefly claim the transition and accept cash confirmation only once. The second request receives the outcome already reached. A visually disabled button provides useful feedback but does not replace this server check.
Fictional example: handover between two shifts
Visitor centre Havenzicht sells a group package. The customer pays a deposit by card and wants to pay the balance in cash. Employee Eva starts the workflow just before her shift ends. The card payment is confirmed, but the customer still needs to withdraw cash. Eva closes the order without marking it paid and adds a short operational note.
An hour later, colleague Bilal opens the order. He sees the original total, verified card amount, exact cash balance and status “awaiting cash confirmation”. After receiving the cash, he confirms the step using his own account. The system records the time and employee, compares the sum and then processes payment once. The operational order remains open afterwards for as long as work is still required.
The shift handover contains no payment details in a separate chat message. Eva refers only to the order and outstanding step; Bilal reads the current state in the administration screen. Havenzicht thereby prevents amounts from diverging across channels. If there is a discrepancy, he can pause the workflow and involve an authorised colleague.
If Havenzicht sends the final status to administration or planning, it must pass on only the correct business event. Yindle Connect can help organise these statuses and recoverable exceptions between systems.
Recovery check for the workplace
- Close the browser immediately after terminal confirmation.
- Open the order on another device as another authorised user.
- Check that the amount already paid and the balance are unchanged.
- Try confirming the cash step twice.
- Have an unauthorised role open the recovery page.
- Test an order change while split payment remains open.
- Check that order export and fulfilment have not started.
- Practise the procedure with an unknown provider status.
Keep the instruction alongside the order short enough for a busy counter. A detailed manual can exist, but the screen itself must answer three questions: what is already confirmed, what remains open and which action can I take now? For more complex process logic, custom software can directly support the human workflow.
Include this intermediate status in operational reports. A list of orders awaiting cash confirmation longer than an agreed period helps find errors without the system assuming whether money was received. Assign that checklist to a specific role and deliberately close each exception.
Discuss with Yindle how unfinished counter payments can be resumed safely.