A payment is approved for one destination. A saved beneficiary profile changes before the queued job runs. If the worker reads the latest profile, it can send a different instruction under the original approval.
Approval belongs to a version
Preserve the significant details shown to the approver: amount, currency, beneficiary, destination, funding source, payout method, corridor, and applicable commercial terms. Record the approver, time, and policy version.
A material edit should supersede an unsent instruction and require a fresh approval. An already dispatched instruction needs the provider's in-flight resolution process, rather than an in-place rewrite.
Close the check-to-send gap
Validate the current authority, version, expiry, and policy. Claim the approved version atomically. Commit the state and fixed request to a durable outbox. The worker sends that fixed request.
The final gate must block invalid dispatch, not quietly become an override.
Test the business rule
- Change the destination after approval.
- Change the amount or let the approval expire.
- Run an edit and worker concurrently.
- Deliver the queue job twice.
- Lose the provider's response after it processes the payment.
Keep approval evidence, the exact dispatched request, attempt references, and the financial outcome together. The useful audit question is whether the payment sent was the payment approved.