Order Status Audit - Admin Operations Guide

Published by Give.Gives · Updated April 2, 2026

Order Status Audit - Admin Operations Guide

1. Purpose and Business Context

Recommended review frequency: The operations team should review this page whenever a refund issue, payment-status inconsistency, or Stripe reconciliation concern appears, and should also run it periodically during the month as part of finance and order hygiene.

Why does this page exist?
Order Status Audit is an admin-only review page used to compare local order status in Give.Gives with the current Stripe state for the same order.

Its purpose is very specific:

1. Check only current-month orders that are linked to Stripe.

2. Compare the platform's saved order status against Stripe's current result.

3. Show only the orders where the two sides do not match.

This page is an audit tool, not a general order management page and not an automatic sync process.

Why are the actions on this page important?

• Mismatch detection: It helps operations quickly identify orders where local data and Stripe are no longer aligned.

• Refund repair: It provides a controlled repair path for a specific high-risk case: Stripe shows a refund, but the local order was never updated to refunded.

• Manual review discipline: The page is designed to surface problems without silently rewriting local orders, which reduces the risk of incorrect status changes.

2. How to Access It

In the admin sidebar, go to Orders > Order Status Audit.

[Placeholder: Full-page screenshot of the Order Status Audit page, including the top summary cards and mismatch table]

3. What This Page Checks

This page audits:

• orders created in the current calendar month

• orders that have either a Stripe Checkout Session ID or a Stripe Payment Intent ID

This page does not:

• review historical orders from older months

• automatically update local orders during the audit itself

• replace normal order operations or refund handling workflows

The audit is manual trigger only from this page. It does not run automatically just because the page is opened.

4. How to Read the Page

Top Summary

The top summary cards show:

• Month Scope: The current month being audited

• Last Run: When the latest audit report was created

• Checked: How many current-month Stripe-linked orders were checked

• Mismatches: How many orders had a status mismatch

These cards help you understand the freshness and size of the latest audit run.

[Placeholder: Screenshot of the top summary cards highlighting Month Scope, Last Run, Checked, and Mismatches]

Mismatch Report Table

Only mismatched orders appear in the table.

Each row shows:

• Order: Internal order reference and creation date

• Customer: Customer email, if available

• Local: The status and payment status currently stored in Give.Gives

• Stripe: The status and payment status currently derived from Stripe

• Reason: A plain-language explanation of the mismatch

• Actions: Links or repair actions, depending on the mismatch type

• Amount: The order amount

If the latest run finds no mismatch, the table will show an empty-state message instead of rows.

[Placeholder: Screenshot of the mismatch table with one example row highlighted]

5. Standard Workflow

Step 1: Run the Audit

Click Run Audit at the top of the page.

The system will:

1. check current-month Stripe-linked orders

2. compare local status against Stripe status

3. save the audit result for this month

4. display only the mismatched orders

If mismatches are found, the system also sends an alert email to admins.

[Placeholder: Screenshot of the Run Audit button]

Step 2: Review the Latest Report

After the audit completes, check:

• how many orders were reviewed

• how many mismatches were found

• whether the mismatches follow a pattern, such as refund-related issues or Stripe lookup failures

Use the Reason column first. It usually tells you whether the row is:

• a real status mismatch

• a Stripe lookup problem

• a refund mismatch that may be repairable from this page

Step 3: Open Stripe When Needed

If a row includes a Stripe button, use it to open the payment directly in Stripe Dashboard.

This is useful when you need to verify:

• whether the payment was actually refunded

• whether the Stripe status is final or still in progress

• whether the refund exists but local order data failed to catch up

Step 4: Decide Whether to Repair or Escalate

This page supports a built-in repair action for only one specific case:

• Stripe status is refunded

• Local status is not refunded

If that condition is met, the row shows a Fix button.

For all other mismatch types, use the report as an investigation tool and escalate through the appropriate order, payment, or engineering workflow instead of trying to force a change from this page.

6. What the Fix Button Does

When Fix is available and clicked, the system repairs a refund mismatch by doing the following:

1. sets the local order status to refunded

2. sets the local payment status to refunded

3. updates refund-related fields from Stripe

4. records an order event showing the repair source

5. creates a missing refund ledger entry if one does not already exist

6. removes that order from the latest mismatch list

This means the button is not a generic “sync from Stripe” action. It is a targeted refund repair tool.

[Placeholder: Screenshot of a mismatch row that shows the Fix button and Stripe button]

7. How to Handle Common Cases

Case 1: Stripe Shows refunded, Local Order Does Not

This is the main case designed for direct repair on this page. Review the row, optionally confirm in Stripe, then click Fix.

Use this when you are confident the refund already succeeded in Stripe and the local system simply failed to update.

Case 2: Stripe Lookup Failed

If the Reason indicates that Stripe lookup failed, do not guess the correct status from this page.

First confirm:

• whether the Stripe ID is valid

• whether Stripe data is temporarily unavailable

• whether the order record is missing or malformed

This usually requires further investigation rather than an immediate page action.

Case 3: Local and Stripe Status Differ, but No Fix Button Appears

If there is no Fix button, the mismatch is not one of the supported repair cases from this page.

Use the row as an audit signal:

• verify the status in Stripe

• review the order timeline and related events

• route the issue to the correct workflow or engineering follow-up

Do not treat this page as a manual override tool for all order states.

Case 4: The Latest Audit Shows No Mismatches

This means the latest current-month audit found no status differences between local orders and Stripe for the orders it checked.

That is a healthy result. No action is needed unless you are investigating a specific order that falls outside the current audit scope.

8. Operating Principles

When using Order Status Audit, follow these rules:

1. Treat the page as a comparison and exception queue, not as the source of truth by itself.

2. Use Run Audit to generate a fresh report before making decisions.

3. Use the Fix action only for Stripe-confirmed refund mismatches.

4. For all other mismatch types, investigate first and escalate through the proper workflow.

The most important principle is simple:
this page is meant to reveal inconsistencies safely, not to silently rewrite order history.

9. Day-to-Day Operations Suggestions

• Run this audit whenever refund timing or Stripe sync issues are suspected.

• During month-end finance review, use this page as one of the checks for Stripe-to-local consistency.

• If multiple rows show the same mismatch pattern, treat it as a system-level issue rather than a one-off order problem.

• If the page repeatedly shows Stripe lookup failures, escalate that pattern quickly because the audit result may be incomplete until Stripe access is stable.