Audit payment-provider events associated with an ecommerce order, including processing status and failure detail.
## At a glance
- **Identify it by:** **Status**.
- **Check its business context:** **Store**, and **Order**.
- **Why care:** Store, publication, consent, payment, and fulfillment states affect what customers see and what staff must act on; check the correct store before saving.
- **Why care:** Status communicates workflow progress to other staff. Change it only when the underlying work, approval, payment, or handoff has actually occurred.
## Before you begin
You need the Brisk permission for the action you are taking on payment events. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Review Payment Event details
Use the detail page as the shared record of what this Payment Event currently means. Verify **Status** before relying on it for a decision.
Follow **Store**, and **Order** to determine whether the issue is on this Payment Event or on one of those linked records.
Next check: Use **Store**, and **Order** to interpret this Payment Event. If it records a failure or exception, correct the source process and create a new successful event rather than rewriting the audit trail.
Find and review payment events
The Payment Events list screen in the Brisk documentation demo.
Use the Payment Events list to find the correct record before opening or changing it. Compare **Status**. Records with similar names or numbers can still belong to different **Store**, and **Order**.
- Keyword search checks **Provider**, **Event Type**, **External Id**, **Status**, and **Message**.
- Narrow the list with **Store**, and **Order** filters.
- The initial order emphasizes **Created At**. Select a column heading when you need a different comparison.
Open the Payment Event whose **Status** match the task. If it is missing, clear the list filters and recheck **Store**, **Order**, and **Status** rather than creating a replacement immediately.
## Fields and business rules
Brisk stores 8 user-relevant fields for this Payment Event, including 2 linked-record selections and 1 controlled-choice field. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---:|---|
| **Store** | No | The store associated with this payment event. |
| **Order** | No | The order associated with this payment event. |
| **Provider** | No | The provider recorded for this payment event. |
| **Event Type** | No | The event type recorded for this payment event. |
| **External Id** | No | The external ID recorded for this payment event. |
| **Status** | No | Current status of this payment event. Available values: Received, Processed, Ignored, Error. |
| **Message** | No | The message recorded for this payment event. |
| **Payload** | No | Structured payload data stored for this payment event. |
## What happens next
Use **Store**, and **Order** to interpret this Payment Event. If it records a failure or exception, correct the source process and create a new successful event rather than rewriting the audit trail.
## Common mistakes and troubleshooting
- **The record saved but is not available where expected:** Recheck **Status**, then clear the filters on the destination list. A saved record can still be inactive, unpublished, locked, unapproved, or in the wrong workflow state.
- **The values look right but the result is wrong:** Open **Store**, and **Order** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.
