Refund request reviews: policy, payment and prior refunds

THE RESULT

Check the input, then compare the complete deliverables

Explore the original materials, item-by-item outcomes and full report below. Attempt the input independently before using the reference to find omissions or disagreements.

Demonstration scope

Policy/payment records are fictional and do not determine legal rights. No Stripe/inbox access, refund, cancellation or reply sending occurred.

Refund request reviews practice

5 requests · 1 partial refund

Original synthetic material. Try the input independently, then compare the reference results.

Original synthetic input

{
  "synthetic": true,
  "case": "stripe-refunds",
  "data": {
    "policy": [
      {
        "id": "POL1",
        "text": "Within 7 days and unused may be submitted for human review; a human makes the final decision."
      },
      {
        "id": "POL2",
        "text": "Check existing refunds; do not refund the same amount twice."
      }
    ],
    "requests": [
      {
        "id": "R01",
        "days": 3,
        "unused": true,
        "paid_minor": 10000,
        "currency": "USD",
        "refunded_minor": 0
      },
      {
        "id": "R02",
        "days": 12,
        "unused": true,
        "paid_minor": 10000,
        "currency": "USD",
        "refunded_minor": 0
      },
      {
        "id": "R03",
        "days": 4,
        "unused": true,
        "paid_minor": 10000,
        "currency": "USD",
        "refunded_minor": 2000,
        "prior_refund_state": "succeeded"
      },
      {
        "id": "R04",
        "days": 2,
        "unused": null,
        "payment_id": null
      },
      {
        "id": "R05",
        "days": 3,
        "unused": true,
        "paid_minor": 10000,
        "currency": "USD",
        "refunded_minor": 10000,
        "prior_refund_state": "succeeded"
      }
    ]
  }
}

Processing rules

Prepare human review evidence under fictional rules, not a final approval, rejection or legal decision. Retain currency and minor units. Verify previous refund status. A partial balance is arithmetic only, not an approved refund. Missing payment/usage information must be requested. Execute no financial action.

Complete reference results under this tutorial’s rules; nothing was written to a third-party service.Scroll horizontally within the table if needed.

Request	Policy comparison	History / gaps	Human next step
R01	3 days; unused	USD 100 paid; no refund	Meets listed evidence conditions; human decides
R02	12 days; outside POL1	Not a final legal conclusion	Review policy differences/exceptions
R03	4 days; unused	USD 20 succeeded; arithmetic balance 80	Verify history/request; avoid duplicate
R04	2 days; usage unknown	Payment id missing	Request evidence, do not guess order
R05	3 days; unused	USD 100 already fully refunded	Check duplicate request; no new refund

Partial-refund arithmeticR03

USD 100−20=80 is an arithmetic balance, not an approval or executed transfer.

Reply draftNot sent

R04: Please provide your order identifier and usage information for review. Do not send full card numbers or account passwords.

Refund review — fictional policy
R01 meets listed evidence conditions; final human decision pending.
R02 outside POL1 window; review policy/exceptions without legal conclusions.
R03: USD 20 already succeeded; arithmetic unrefunded balanceUSD80, pending request/history check.
R04 missing payment identity/usage. R05 fully refunded; check duplicate request.
One R04 evidence-request draft only. No approval, refund execution or sending.

This shows complete inputs and expected outputs. Switching tabs runs no task; verify real connections and writes separately in your environment.

BEFORE YOU START

Prepare the materials and check your tools

Start with the practice files

Read two policy clauses and five requests.
Meeting evidence conditions is not approval.
USD 10000 cents means 100.00, not 10000 dollars.

Before using real services

Specify authorized support queue and Stripe account.
Read only necessary payment identity, amount, state and refund history.
Keep final decisions and financial execution with the human operator.

Complete one file-based exercise first. For real services, verify the actual account, available tools and operation scope, then follow the acceptance check at each stage.

Download the original input and rules ↓

EXECUTION & TAKEOVER

Execution and takeover boundaries

The actions below require the agreed inputs, accounts and scope. Configuring a Routine does not expand that authorization.

Can run automatically

Read supplied requests, policy and transaction snapshots; calculate checkable balances and draft recommendations, exceptions and replies.

Requires confirmation

This tutorial prepares recommendations only. Live refunds, emails, order changes and discounts need per-item approval; an available balance is not authorization.

Take over after a failure

Stop for human review when payment ids, history or refund state are unclear. Inspect Stripe before any retry; submitted does not mean settled.

STEP 01

Inventory policy and evidence scope

Policy text has a scope; this fictional exercise cannot replace actual terms or determine legal rights.

Stage 01 · Inventory policy and evidence scope

Read POL1/POL2 and five requests. List conditions, visible fields and gaps. Use uploaded material only, without inbox/Stripe reads, final approval/rejection or financial action.

Expected output

A policy/request index.

Acceptance check

Every outcome is human-review material, not approval.

STEP 02

Check payment identity, state and minor units

A requester’s statement is not a verified transaction. Match exact payment identity and retain source units.

Stage 02 · Check payment identity, state and minor units

Normalize paid_minor/refunded_minor with currency and raw values. Keep missing payment_id unknown; do not match by guessed name/email. List evidence needed without reading card numbers or keys.

Expected output

Payment fields and gaps.

Acceptance check

10000 cents displaysUSD100; R04 identity is not invented.

STEP 03

Review previous refunds before a new recommendation

Pending, failed and succeeded refunds differ. An existing request must not trigger a duplicate action.

Stage 03 · Review previous refunds before a new recommendation

Check prior refund states. R03 has succeeded 20 and R05 succeeded 100. Calculate R03 balance 80 labeled not an approved amount. Send unknown status to human review; generate no execution request.

Expected output

A history/duplication table.

Acceptance check

No second refund for R05; R03 balance is not approved.

STEP 04

Prepare human guidance and a minimal draft

Explain satisfied conditions and missing evidence. Request only needed identifiers without promising an outcome.

Stage 04 · Prepare human guidance and a minimal draft

Compare all five requests to POL1/POL2. List differences/gaps without a final decision. Draft only R04’s request for order identity and usage. Do not promise refunds, send email or cancel subscriptions.

Expected output

A checklist and local draft.

Acceptance check

All five are accounted for without invented orders or executed money.

STEP 05

Run a small read-only real review

First verify account, payment identity and refund history. A generated report is not evidence of a platform operation.

Stage 05 · Run a small read-only real review

Verify <Stripe account/support queue> and read-only capability. Review at most 3 requests using exact payment ids and necessary fields/history. Deliver a human checklist only. Do not create refunds/cancellations or send messages. Stop at unmatched identity.

Expected output

A dated read-only review or blocker.

Acceptance check

Money, subscription and email state remain unchanged.

STEP 06

Track repeated requests and changing states

One payment may have multiple requests and state updates. Preserve request/payment identity and prior review time.

Stage 06 · Track repeated requests and changing states

Draft a refund-review Skill with policy version, request/payment ids, currency, history, gaps, human decision and recheck. Default to read-only files. Do not convert review approval into automatic refund permission or create financial Routines.

Expected output

A traceable review method.

Acceptance check

Reruns recognize the same request; humans retain financial execution.

TROUBLESHOOTING & ACCEPTANCE

Find the evidence before choosing the next action

Can it refund the remaining balance?

Verify state, request and human decision; arithmetic balance is not authorization.

Payment id is missing

Request it rather than guessing or browsing unrelated payments.

Does more than 7 days remove refund rights?

This exercise compares fictional conditions and leaves actual policy/legal judgment to humans.

A submitted refund has not succeeded

This tutorial executes none; real status requires readback, not a claim that funds arrived.

Check every item before finishing

These page-local checkboxes reset on refresh. Checking them does not verify a real service connection.

Every outcome is human-review material, not approval.10000 cents displaysUSD100; R04 identity is not invented.No second refund for R05; R03 balance is not approved.All five are accounted for without invented orders or executed money.Money, subscription and email state remain unchanged.Reruns recognize the same request; humans retain financial execution.

Checked 0 / 6 items

PRACTICE MATERIALS

Download the inputs separately from the reference answers

Start with input and rules without showing the reference answers. After acceptance, save the report and complete prompt set.

Original practice inputInputs only; attempt the exercise before opening the reference answers.
source-data.jsonRules and scopeDefinitions, exceptions and delivery requirements.
workflow-rules.mdItem-by-item reference resultsCompare every input with its outcome.
expected-results.csvComplete reference reportResults, evidence and missing information.
reference-report.mdAll stage prompts6 instructions with expected outputs and acceptance checks.
practice-prompts.txt

SOURCES & VERIFICATION

Check documented capabilities and exercise results separately

Content updated: 2026-10-18 · Editing a page does not reverify its sources or live workflow.

Documentation review: Reviewed within the recorded scope · 2026-10-18
Reviewed partial refunds, aggregate amount limits and pending/failed states. Documentation review establishes neither account access nor live refunds or customer notifications.

Documentation review evidence and limits ↗

Live workflow verification: Unverified
Unverified: refund-state and boundary documentation only. The current Bot tool catalog does not expose Stripe. A test-mode connection and specified test objects are needed for a later read-only check; real refunds require user takeover. No financial action occurred.

Execution attempt and blockers ↗

Policy/payment records are fictional and do not determine legal rights. No Stripe/inbox access, refund, cancellation or reply sending occurred.

Stripe: refunds ↗
Review refund history, partial amounts and status. This tutorial performs no financial actions.
Grok Bot: apps and the shared computer ↗
Check connected accounts, available tools, visibility and user takeover.
Grok Bot: Skills and Routines ↗
Validate a manual run before saving a method or scheduling it.

NEXT STEP

Try another small batch of your own material

Retain original input and operation records. Verify that each result can be traced before adding connections or recurring runs.

Return to Customers & support →

Learning path

Get started

Advanced

Recipes

Resources

Refund request reviews: policy, payment and prior refunds

Check the input, then compare the complete deliverables

Prepare the materials and check your tools

Start with the practice files

Before using real services

Execution and takeover boundaries

Can run automatically

Requires confirmation

Take over after a failure

Inventory policy and evidence scope

Check payment identity, state and minor units

Review previous refunds before a new recommendation

Prepare human guidance and a minimal draft

Run a small read-only real review

Track repeated requests and changing states

Find the evidence before choosing the next action

Check every item before finishing

Download the inputs separately from the reference answers

Check documented capabilities and exercise results separately

Try another small batch of your own material