Someone prepares a refund. A reviewer replies “approved” by email. The refund runs in another system. Later, an operator has to piece together the requested values, the review and what actually happened.
Four-eyes control requires independent review before the sensitive action runs. Moving the reply onto a ticket helps preserve the discussion. The next step is to test whether the system enforces the boundary around the action itself.
Put the review beside the request
For a refund, keep the original request, target transaction, proposed amount, reason and supporting evidence together. The reviewer should inspect the submitted action values and the ticket context without reconstructing them from several tools.
Latch keeps notes, evidence, plugin actions and execution history on the ticket. An integration connects the action to the payment service; that service remains responsible for processing the refund. A refund example does not imply a built-in connection to every payment provider.
The current gate applies to the selected plugin action. Administrators choose maker-checker by default for a plugin or override individual actions. Monetary thresholds require connected business logic; they are not a native amount-rule editor.
Define which two people must be different
In Latch, the action requester cannot approve, reject or execute that same maker-checker request. The requester may be different from the person who created the ticket. Another eligible operator must review it.
Approval and execution are separate steps. The reviewer may also execute if permitted; the product does not require a third person. If your policy separates preparation, review and execution across three people, evaluate that as an additional requirement.
Saved submitted fields are used for approved execution. Current ticket context and action availability are checked again. Request expiry and optional ticket-change invalidation help stop an old approval from being used after the work has changed, but they do not freeze every part of the external system's state.
Use an acceptance checklist before replacing the inbox
Run these checks with synthetic data and a test integration. The expected result describes the control you should verify, not a claim that your deployment or payment connection has already passed.
| Check | What to do | Evidence to keep |
|---|---|---|
| Requester independence | Submit an action request, then try to approve, reject and execute it as the requester. | Denied responses and the identity used; check separately which denials appear in ticket history or operational logs. |
| Reviewer eligibility | Try review with an ineligible account, then with an eligible account holding the required action permission. | Observed permission result and reviewer identity. |
| Saved values | Compare the review dialog with the submitted amount, transaction reference and reason. | Saved request and the form values sent during approved execution. |
| Rejection | Reject a pending request and inspect it from the requester account. | Retained decision and confirmation that the downstream action did not run. |
| Changed work | Enable ticket-change invalidation, change the ticket and try to use the old request. | Superseded request and fresh-request path. |
| Expiry | Use a short request lifetime in the test environment and wait until it expires. | Refused review/execution and the expiration time. |
| Execution authority | Change action eligibility or execution permissions after approval and try to run it. | Refused execution when the current authorization check fails. |
| Reported outcome | Execute against a test service that returns a known reference. | Execution attempt, response and any successfully applied ticket effects. |
| Uncertain result | Simulate a timeout or lost response after the test service receives the operation. | Blocked replay path and evidence needed for provider reconciliation. |
The approvals feature guide shows the review and gate screens using clearly labelled synthetic replay data. Use those screens to plan a test; use your own observed results to accept the workflow.
Keep the decision and the outcome separate
An approval proves that an eligible person agreed to the request. It does not prove that the payment succeeded.
Preserve the execution attempt and the outcome reported by the integration. If the response is lost, check the payment service's authoritative state before deciding what to do next. Latch retains uncertain approved execution attempts and does not automatically replay them.
The ticket history helps follow the work. Legal retention, independent immutable storage and recovery policy remain separate operating requirements.
Start with one refund path
Choose one action that already requires review. Agree on the requested fields, eligible reviewers, integration owner and reconciliation procedure. Accept the flow only when a success, a rejection and an uncertain result each leave evidence another operator can follow.
See how ticketing with approvals works, or bring one action to a workflow review.