Automate a weekly Stripe refund report with reasons and failures

Refunds are easy to issue and hard to see in aggregate. A scheduled agent reads your Stripe refunds each week, totals them by status and reason, flags failed or pending ones, and drafts a report that its department head reviews and you approve.

What you’ll set up

Connections

Stripe read access (refunds) · Required

The team requests read access to your Stripe refunds when you add the job.

Upgrades

Report delivery (channel or inbox)

Delivers the approved report to your channel or inbox.

Inputs

Where to send the report · Optional

Email, defaults to your account email

Flag refund rate above (%) · Optional

Number, default 3

Ready by · Required

Time, default 08:00

Brief · Required

Text, prefilled and editable during setup.

Runs

Runs every Monday at 08:00

Done by Business analyst

You approve before anything goes out.

Set up this job

You approve every report · Free to start

How it runs

One agent does the work. Its department head reviews it, then you approve.

  1. 1Business analyst

    Runs every Monday at 08:00 and prepares the report from your connected sources.

  2. 2COO · Review

    The department head reviews the report before it reaches you.

  3. 3You

    You approve before anything goes out.

What you get

Sample, not live dataSample weekly refund report (Sample, not live data)

Sample, not live data. The amounts, reasons and counts are invented.

Refunds, week of 3 Nov (sample)

9 refunds, 412.00 total, 2.1% of payments.

ReasonCountAmount
requested by customer5230.00
duplicate298.00
fraudulent149.00
none given135.00

Needs attention: 1 refund failed (expired card), 1 pending.

For your decision

  1. Arrange another way to return the failed refund.

Why a weekly refund view helps

Stripe lets you refund all or part of a payment from the Dashboard or the Refunds API. In the Dashboard you can select several payments and refund them together, but as full refunds; partial refunds must be issued individually. Refunds therefore scatter across weeks, reasons and payment methods. A single monthly number hides what matters: whether one product drives most of them, whether duplicates are creeping up, and whether a refund failed and left a customer unpaid.

What each refund status means

Stripe's API reference lists refund statuses of pending, requires_action, succeeded, failed and canceled. For card refunds, Stripe holds a refund as pending when your available balance cannot cover it, until the balance is sufficient. A requires_action refund carries a note on what it needs to continue processing. A failed refund can carry a failure_reason such as lost_or_stolen_card, expired_or_canceled_card or insufficient_funds. Stripe says the bank returns a failed refund to Stripe, and you then need to arrange another way to pay the customer. The report lists each of these with its reason so nothing sits unnoticed.

How the scheduled job works

You add the job and grant read access to your Stripe refunds; the team requests the access when you add it. Each week a scheduled agent lists refunds created in the last seven days through the list endpoint, which accepts a created date range and returns up to 100 refunds per page. It groups them by status and reason, totals amounts by currency so currencies are never mixed, and compares the week with the one before. A partial refund counts as its own refund, so the report shows amounts as well as counts.

Review and approval

The COO agent, as department head, reviews the report before it goes out: do totals match the refund list, is each currency kept apart, is any failed refund missing. Stripe says customers see a refund as a credit approximately 5-10 business days later, so the report also helps you answer "where is my refund" with a real status rather than a guess. Then you approve, edit or skip it, and nothing is sent until you do.

Questions

Start with one report

Set up this job

You approve every report · Free to start