Claude Duet Can Issue Refunds. What Would You Let It Decide?

What arrived—and who can try it

On October 21, 2026, Stripe announced that Claude Duet integrates its Stripe MCP connection and Link’s wallet for agents. Stripe says the account connection can issue refunds, alongside tasks such as sending invoices. That is the material change for this story: a conversation can lead to an action in a business account. [1] (opens in a new tab)

Anthropic describes Duet as a proactive assistant that can work across connected apps and continue tasks while its user is away. It is a research preview available by waitlist, starting with US Pro and Max subscribers. During the preview it is included in those plans and shares their usage limits. A subscription is not a promise of immediate access. [2] (opens in a new tab)

As checked on October 22, Claude lists Pro at $20 a month when billed monthly and Max from $100 a month, before applicable tax. Those are plan prices, not the total cost of designing and maintaining a refund workflow. [3] (opens in a new tab)

There are two different payment connections in the announcement. Link pays for things the owner buys; Anthropic’s help page says each Link purchase needs approval of its maximum amount. The Stripe connector works in the merchant’s Stripe account. The Link purchase screen should not be assumed to be the approval process for a customer refund. [4] (opens in a new tab)

This article has not tested Duet’s refund interface. The shop example below explains the behavior an owner should look for or ask a builder to implement. It does not claim that every proposed control is already a setting in the preview.

One order, two very different instructions

Imagine a small linen shop. A customer bought two aprons at $48 each, a $96 order in this simplified example. One arrives with a problem. After checking the order and discussing the remedy, the owner and customer have already agreed on a $48 refund for that item. The example starts after that decision; it does not try to decide the customer’s legal entitlement.

An assistant could help by putting the relevant purchase and conversation together, identifying the agreed item and preparing a short reply. That is useful work even if the owner still makes the final click in the payment dashboard.

But “refund this customer” leaves important details open. Is it the whole order or one item? Is this the correct purchase? Has somebody already dealt with the request? A polite message and a confident summary do not answer those questions.

The second version would put the decision and its supporting details in one place. The owner can check the proposed action against the actual agreement. If the amount or order changes afterward, the proposed design would require another review rather than treating the earlier yes as permission for something else.

Stripe’s documentation allows partial refunds and more than one refund against a charge, up to the original charge amount. That provider limit is useful, but a $96 full refund on this order would still be more than the $48 the owner agreed to. The business decision needs its own check. [6] (opens in a new tab)

Give the assistant a smaller job first

For a first trial, I would let the assistant assemble a case for review: the authenticated customer’s order, their request, the relevant policy, any previous refund and a proposed next step. Missing or conflicting information would remain visible. The customer’s message can describe a problem; it should not be treated as authority to change the shop’s rules.

The owner would confirm the remedy and exact amount. A connected system could then submit only that approved action, or staff could use the existing dashboard. A reasonable first version may never need the assistant to move money itself.

Stripe’s MCP documentation describes access for live accounts and sandboxes, permissions for each environment and session revocation. It also recommends enabling the client’s tool-approval setting. In plain terms, check which account the assistant can reach, which actions it can perform and how you can stop its access. A written instruction in a chat is not the same as limiting the connected tool. [5] (opens in a new tab)

For a custom workflow, ask the builder to keep the permission narrow and to bind approval to the order and amount being reviewed. Do not assume that a generic connector supplies a per-refund spending limit or your shop’s eligibility rules. Those details need verification in the actual product and configuration.

Make the customer handoff humane as well. If the order cannot be matched or the request needs judgment, send it to a named person with the useful context already attached. Give the customer a clear way to reach staff. Avoid making them repeat their story because the automation reached the edge of what it can do.

Use only the customer information needed for the task, with access and retention appropriate to the business. Full card details do not belong in a chat summary. An attractive review panel is useful only when the records behind it are accurate and available to the right people.

The reply is not the payment result

Suppose the owner approves the $48 action, but the connection times out. The assistant should not guess that it failed and start a new refund. Nor should it reassure the customer that everything is complete merely because the owner said yes.

Stripe documents a mechanism called idempotency: a request identifier lets the service recognize a retry of the same operation. A builder should use that mechanism correctly and check the existing result when a response is uncertain. The owner’s requirement is simpler: one approved action should not turn into two because the network was slow. [7] (opens in a new tab)

Refunds can also remain pending or fail. Stripe says insufficient available balance leaves card refunds pending, while refunds for other payment-method types fail in that situation. Its refund documentation also specifies return to the original payment method. The assistant’s message should follow the actual status and the provider’s applicable guidance, including any follow-up needed. [6] (opens in a new tab)

Keep the approval and provider reference with the case. Someone must own unresolved results and customer updates. If a customer asks again tomorrow, staff should be able to see what was approved, what was submitted and what the provider currently reports.

Stripe says original processing fees are not returned and refunds may incur a fee. Check the applicable pricing before estimating savings; faster handling does not automatically mean a lower cost. [6] (opens in a new tab)

Try it on the cases that make staff pause

Begin with synthetic orders in a sandbox or a preparation-only process. Include an ordinary partial refund, an already-handled request, two orders for the same customer, a changed amount after approval and a response that never arrives. The question is whether the system stops, explains or reconciles correctly—not whether it can write a pleasant reply.

Then compare a limited set of comparable cases with the current process. Measure time spent gathering facts, time awaiting a decision, time to a correct resolution and the number of corrections or repeated customer contacts. Watch for excessive escalations as well as mistaken actions. A system that sends every case back to the owner may have moved the work rather than reduced it.

A low-volume shop with an easy dashboard may get little value from a new integration. More complex operations have to budget for identity checks, order matching, approval records, payment-status updates and maintenance. Start where there is a recurring problem you can actually observe.

The portfolio’s Kundan HQ project connects customer, payment, inventory and shipping records. That illustrates the kind of connected information a useful support workflow depends on. The AI refund process described here is a separate proposal, not a feature claimed for Kundan HQ.

Claude Duet’s announcement makes this worth examining now. For the linen-shop owner, a good first outcome is modest: the correct order is ready, the agreed $48 action is clear, and the customer hears what has actually happened. That is a useful delegation to prove before asking the assistant to decide more.