Find and review payment transactions

Start with the payment record

Use Lexoh transaction records to investigate a payment, respond to a receipt request or trace a reporting difference. Identify the site and transaction before changing a payment or sharing its details. A customer name or amount alone may match several records.

This guide covers the review workflow. Available filters, fields, exports and payment actions depend on the deployed software, your permissions and the payment configuration. Confirm the controls in your installation with its administrator.

Check your site and access

The list may rearrange on a smaller screen. Read field labels and open the detail view to inspect omitted information. Do not rely on colour, icon position or a gesture described for another software version.

1. Open the transaction view for the intended site or organization. Check whether your account can see every site relevant to the enquiry.
2. Locate the search controls, active filters, result count and record-detail action available in your version.
3. Check the last update or reload the list using the available control. Wait for loading to finish before interpreting an empty result.
4. If information or an action is unavailable, ask the administrator to verify your role and the transaction’s eligibility. Do not infer a payment outcome from a hidden button.

Find one transaction reliably

A name, card brand or amount may not be searchable in every version’s general search box. Use the dedicated field where available. An empty search result does not establish that the customer was never charged.

1. Start with a known transaction, receipt or invoice reference and use the search field documented for that reference. Preserve the original identifier exactly.
2. If no reference is available, narrow the period and site, then use the available amount, customer or device filters.
3. Check active filters when a search returns nothing. Remove unnecessary restrictions one at a time and record which change revealed the record.
4. Open the candidate and confirm several details, such as time, amount, currency and device. Distinguish multiple attempts from the final payment.

Keep the filter meanings distinct

Dates and amounts

Confirm the time zone, period boundaries and which event date is filtered. Check currency and whether the amount includes taxes or uses a signed refund value. Enter numbers in the format accepted by the field and verify the applied value.

Status, type and source

Status describes the recorded processing state. Type distinguishes operations such as a payment or refund. Source identifies the channel or device. A payment method or card brand is a separate attribute.

People and associations

A customer, staff user, company, access credential, zone and tag can describe different relationships. Read each filter label and check the actual association on a sample result. An unassigned field does not necessarily mean an anonymous payment.

Combining filters

Confirm whether multiple choices within a filter are alternatives and how separate filters combine. Add criteria gradually, then check the result count and a known record. Do not assume a reset clears both free-text search and every filter.

Read the result without assuming the outcome

Confirm the exact status definition for your application and payment provider. The checks below describe an investigation, not a complete list of Lexoh status labels. A successful payment and a bank payout are separate events.

A record marked pending or unknown

Check its reference, age, last update and provider response. A delay or unclear status does not establish failure. Resolve the existing attempt before starting another charge or refund.

A record marked completed

Verify the amount and payment reference. Check settlement records separately if the question concerns funds reaching the bank.

A record associated with a refund

Check the refund’s own reference, amount and processing result. Determine whether it is partial or full and whether other refunds or disputes already exist.

A cancelled or failed attempt

Read the provider result and any related records. Confirm what was cancelled or failed before telling the customer that no payment or refund occurred.

Review details before a payment action

Match the transaction reference, timestamp, site, currency, amount and available device or customer association. Distinguish an invoice number from a provider payment reference. Keep both when they are available. For a receipt request, verify the recipient and use the approved delivery process.

For a refund or cancellation, confirm that your role permits the action and that the payment is eligible. Use the provider-supported process and destination. Do not assume that a refund can be redirected, undone or treated as successful immediately after submission.

1. Review the original payment and all prior refunds, pending requests and disputes.
2. Confirm the intended full or partial amount, currency and treatment of taxes. Check the available refundable amount in the provider-supported workflow.
3. Record the reason and any approval required by your organization. Review the final amount and transaction reference before confirming.
4. After submission, record the result and reference. If the response is unclear, verify the existing request before trying again.
5. Communicate the confirmed status to the customer and follow up on pending or failed processing.

Provider reference

Stripe’s refund documentation illustrates why these checks matter: refunds can have pending or failed states, and destination and cancellation rules depend on the payment process. Follow the rules of the provider configured for your installation. Reference: Stripe, Refund and cancel payments — docs.stripe.com/refunds. This is not evidence of a particular Lexoh integration.

Verify the scope of an export

A transaction export is a report, not proof that the complete system has been backed up. A completed-payment filter alone also does not establish a reconciled revenue total; refund, date and settlement rules still matter.

1. If export is available, apply the intended site, period and filters. Note the sort order and selected rows.
2. Check whether the export includes the current page, selected records or all matching records. Use the formats and columns actually offered.
3. Open the file and compare its row count and a few references with the filtered view. Preserve identifiers as text when importing them into a spreadsheet.
4. Check currency, amount signs, taxes and transaction states before adding amounts. Keep refunds and excluded states identifiable.
5. Save the file with its scope and extraction time using approved storage. Share only the fields needed for the task.

Distinguish a page from the full result

Read the result counter and page controls available in your version. Changing the number of displayed rows does not change the underlying number of matching transactions. After changing filters, check the counter and current page again.

Illustrative example: a list showing records 26–50 of 247 contains 25 records on that page, with 247 matching records overall. At 25 records per page, the result spans 10 pages and the final page contains 22 records. These values demonstrate pagination, not a fixed Lexoh setting.

Document the finding and next step

For a reporting difference, compare equivalent periods, currencies and transaction populations before calculating totals. Use the revenue guide to trace provider settlement differences. For a terminal issue, compare transaction times with the relevant device events.

Keep the reference, observed status, verified result, action taken and follow-up owner together. Use approved support channels and avoid including full payment-card details in screenshots or notes.

If the record remains ambiguous, preserve the available evidence and escalate the specific question. A repeat payment or refund is an action with its own consequences, not a way to test whether the previous request succeeded.