Payment evidence

Payment Analyst reviews provider events linked to customer orders. An event has a provider event ID and reference, type, amount, date and verification flag. Authorization, Capture, Refund and Void remain distinct event types. The analyst can therefore inspect what the provider reported without replacing an earlier event when a later refund or void arrives.

• Collect the event. Retain the provider event ID, reference, amount and date against the order.
• Check verification. Use the verification flag to find events requiring analyst attention.
• Read the sequence. Compare authorizations, captures, refunds and voids in time order.

The Payment Evidence Attention Queue identifies payment events needing attention. The event record gives the analyst the provider reference needed to investigate it. An operation receipt may separately show that an attempted action failed or needs review; that receipt describes the action result, while the payment event describes provider evidence.

A verified event remains a dated provider fact even if a later event changes the payment picture. Review a refund against the earlier capture by provider reference and order rather than changing the capture record.

Agree which provider supplies each reference and how duplicate provider event IDs are handled. Decide who may mark an event verified and what source evidence they must inspect. Define how staff match a provider event to a customer order when the external order ID differs from the provider reference. Preserve the event’s original amount and type when resolving a discrepancy.

Use a confirmed order with an authorization followed by a capture. The Payment Analyst checks both provider IDs and confirms the capture’s reference and amount. Now add an unverified refund event. The attention queue should show the refund until the analyst resolves its verification state. The order’s net amount gives context, but the event sequence remains the evidence of what the provider sent.

Repeat with the same provider event ID arriving again. Staff should identify the existing event instead of treating the duplicate as new money. If an operation receipt says Failed, investigate its failure reason and key before retrying a payment-related action.

The analyst should be able to move from an attention item to the underlying order without losing the provider identity. When the provider sends a later event, retain that event separately. This makes a refund review possible even when the earlier capture has already been verified.

• Unverified payment evidence — Provider events that need verification.
• Failed operation receipts — Actions whose result or failure reason needs investigation.

Review payment and operation exceptions and plan connections.