Payment and attachments

Payment evidence records a provider event ID, event type, amount, occurrence date, verification state and provider reference against a customer order. Authorization, Capture, Refund and Void are distinct event types. A refund request after a physical return should be checked against the original provider evidence and the returned quantity. The verified state helps reviewers separate an observed provider event from an item still awaiting confirmation.

Order attachments record a title, file, upload date, visibility, evidence type, order and uploading team member. Internal and Shared visibility are explicit choices. Supporting files may explain a package inspection, customer correspondence or an exception review, depending on the team’s operating policy. Keep the attachment with the order it supports so a reviewer can follow the decision without an unrelated file search.

• Match provider identity. Check the provider event ID and reference before treating a payment event as new.
• Review the money event. Keep authorization, capture, refund and void amounts distinct when explaining an order.
• Set visibility deliberately. Choose Internal or Shared for each attachment and check the audience before upload.

The Finance Reviewer uses the payment evidence and order history together. A provider event may arrive after a delay; its occurrence date and provider identity should still show the sequence. The Operations Reviewer may need to inspect related evidence when a return, cancellation or uncertain execution crosses operational and financial work.

Decide which provider messages count as verified and who is allowed to mark a record that way. Define how refund evidence references the inspected physical return and how a duplicate provider event is handled. Agree which documents belong as order attachments, which are Shared and who may see Internal files. Test a provider message replay and a changed visibility choice with the actual access rules.

The payment provider remains the authority for execution. The order record stores evidence and review context; it should not be used to infer that an unverified local refund request has paid money out. Reconciliation should compare provider references and amounts to the event history.

An order ships and is later returned in part. The operator records a Returned fulfillment event against the product and quantity. Finance Reviewer inspects the original capture evidence and the return record, then checks the authorized refund request. The provider’s refund event arrives with its own event ID and reference. The team records its amount and verification state against the same order.

The provider sends the same event again. Staff match the event ID and avoid recording another refund. A supporting inspection file stays attached to the order with the intended visibility. Ask a reviewer to explain the money sequence from the order, events, payment evidence and attachment without relying on an unlinked message.

• Unverified payment evidence — Provider events awaiting confirmation.
• Shared order attachments — Supporting files marked for the shared audience.
• Order review decisions — Recorded reasons behind related review outcomes.

Return and reconciliation connects return and refund evidence. Order confirmation establishes the source order. Review integrations before connecting a payment provider.