Workflow design · Payment systems · Operational controls
What should a payment workflow prove before it marks work complete?
Give matching, internal approval and provider processing separate evidence. Preserve unresolved states and verify how late or repeated events change the recorded outcome.
Define the evidence behind each state
Describe the facts each status establishes. A document can be recognized, its amounts checked and its recipient identified while internal approval remains outstanding. Record which system supplies each fact and what evidence allows the workflow to advance. Avoid one completion flag spanning all these responsibilities.
Microsoft’s invoice-matching documentation distinguishes comparisons of totals, prices, quantities and charges. Each comparison answers a different question. Specify which checks your workflow requires and retain the discrepancies that remain, even when another comparison passes.
Keep internal permission to proceed distinct from a payment provider’s authorization status. Use labels that identify the actor and event. Have the responsible financial-operations owner define approval requirements and the treatment of unmatched amounts or remaining balances before implementing transitions.
Follow the provider’s actual processing lifecycle
Adyen documents intermediate states in which a request has arrived but its final outcome is unavailable. It also warns that a returned result can change and should not directly determine order-management state. Map the provider’s documented lifecycle to the evidence your application displays.
For the selected payment method, define what accepted, pending, authorized and completed mean. Specify the event that confirms each transition, including any separate capture step. Keep an unknown outcome visible when the required confirmation has not arrived. A timeout needs investigation rather than an invented success or failure.
Adyen’s webhook guidance addresses message integrity, event ordering and duplicate delivery. Apply the integration’s documented processing rules and retain the provider reference and relevant event history. Repeated notification of one event should not create a second business action.
Test disagreement and recovery explicitly
Build non-production tests for a matching discrepancy, changed input after approval, delayed confirmation and conflicting local status. For each case, identify which fact remains established, which transition must wait and who can resolve it. Check individual items within a batch rather than inferring every item succeeded.
Replay duplicate and out-of-order provider events in the test environment. Confirm that the recorded state converges to the supported outcome and that retries preserve the intended transaction identity. Inspect the customer-facing message alongside the internal record.
Make the record explainable after processing: the checked input version, internal decision, provider events and unresolved follow-up should agree. Financial-operations specialists should resolve accounting treatment separately. The software’s completion claim should extend only as far as its recorded evidence.