Skip to main content

Payment Events

Payment Events

Purpose and when to use this record

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 storespermission for the action you are taking on payment eventsevents. asIf parta ofCreate, theEdit, ecommerceor module.Delete This generated referencecontrol is awaitingabsent, workflowdo review.not work around it with another user’s account; ask an administrator to review your role.

ViewReview recordPayment Event details

The evidence packet identifiesUse the viewdetail page as the shared record of what this Payment Event currently means. Verify Status before relying on it for a decision.

Follow Store, and sourceOrder locationto fordetermine whether the issue is on this action.Payment ConfirmEvent user-facingor stepson beforeone approvingof those linked records.

Next check: Use Store, and Order to interpret this page.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 recordspayment events

Brisk Payment Events list screen displayed with fictional documentation-demo data.
The Payment Events list screen in the Brisk documentation demo.

The evidence packet identifiesUse the viewPayment 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 sourceOrder.

location

  • 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 action.Payment ConfirmEvent, user-facingincluding steps2 beforelinked-record approvingselections and 1 controlled-choice field. Create and edit screens may hide calculated or workflow-managed values from this page.full reference.

FieldRequiredWhat it controls
StoreNoThe store associated with this payment event.
OrderNoThe order associated with this payment event.
ProviderNoThe provider recorded for this payment event.
Event TypeNoThe event type recorded for this payment event.
External IdNoThe external ID recorded for this payment event.
StatusNoCurrent status of this payment event. Available values: Received, Processed, Ignored, Error.
MessageNoThe message recorded for this payment event.
PayloadNoStructured 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.

Back to top