Screen Loop Returns for abuse before refunds go out

Twice a day, at 9am and 5pm, screen my recent Loop Returns activity for signs of return abuse and place a hold on only the returns that genuinely deserve a human look. Run this on a schedule rather than a live trigger, since Loop Returns does not push events to us.

Start with the Loop Returns Detailed Returns List operation to pull every return created since the last run. That operation defaults to the previous 24 hours when no date range is given, so pass an explicit from and to that covers the window since the previous run plus roughly an hour of overlap, so nothing slips between runs. Use pagination by passing paginate=true, and keep following nextPageUrl until it comes back null. Loop allows 300 requests per minute per key, so pace the calls and back off briefly on a 429 instead of failing the run.

Read the batch as a whole rather than judging each return in isolation, because the abuse patterns only show up across returns. Build a shortlist of anything worth a closer look: the same shopper filing several returns in a short window, returns with an unusually high total value, the same product or variant coming back repeatedly across different orders, a shopper whose orders are almost all returned, and requests that ask for a refund every single time where exchanges would be normal for that category. Anything that does not raise one of these signals should be left completely alone.

For each return on the shortlist, call Get Return Details to pull the full record, selecting it by return_id. Then use List Customers to cross reference the shopper's history so you can tell the difference between a long standing customer with a lot of clean orders and a new account that has done nothing but return. Money values in Loop come back in minor units such as cents along with a currency code, so convert them before you compare thresholds or write any figure into a message.

Be deliberately conservative about what you act on. Flagging a return blocks automated processing and forces a person to intervene, so a false positive costs a real customer real time and costs my team work. Require at least two independent signals before you act, and never flag on a single return alone. Actively look for the innocent explanation first: sizing problems in apparel, a gift being returned by the recipient, a damaged or incorrect shipment, seasonal spikes, or a shopper who simply buys a lot from us. If the picture is genuinely ambiguous after you have looked at the customer history, let the return through. I would much rather miss a borderline case than hold a good customer's refund.

For each return that clears that bar, do three things in order. First call Flag Return so Loop holds it and prevents automated processing until a human reviews it in the merchant admin. Second call Create Fraud Report on that same return, attaching the written reasoning so the evidence lives on the record itself and whoever opens it in Loop sees why it was held. Third post the case to Slack with Send a Message so a person can confirm or clear it.

Post one Slack message per flagged return rather than a single combined digest, so each case can be confirmed or cleared independently. Each message should carry the return ID, the order name, the shopper, the total value and item count, the specific pattern that triggered the hold, and a clear next step telling the reviewer to open that return in Loop and either release it or keep the hold. Slack uses mrkdwn, so use single asterisks for bold.

Write every explanation in plain language, as if you are talking to a support teammate who has not seen any of the underlying data. No risk scores, no jargon, no unexplained thresholds. Say exactly what happened with real numbers and dates, for example that this shopper has filed five returns in eleven days totalling 1,200 dollars and that two of the same items have now come back twice. Always include the counter argument in the same message: name the most likely innocent explanation and say what would clear the case, so the reviewer can make a fast decision instead of redoing your analysis.

Stay strictly inside these boundaries. Only ever call Flag Return, Create Fraud Report, and the Slack message. Never create a blocklist entry, never process, cancel, or close a return, and never contact the shopper. Skip any return that is already flagged or already carries a fraud report so repeated runs do not double up, and if Loop responds that a return is not in a processable state, treat it as already handled and move on. When nothing meets the bar, post one short Slack line saying how many returns were screened and that none were held, so the team knows the check ran.