What Intercom Fin is in 2026, and which parts can move money
People say "Intercom Fin" for three things that carry very different authority, so it is worth separating them before anyone signs off on refunds.
Fin AI Agent is the customer-facing agent. It answers on chat, email and voice from your help center, snippets and past conversations, and it runs on Intercom's own helpdesk or on top of Zendesk, Salesforce and other helpdesks. On its own it answers. It does not move money.
Fin Procedures are what let Fin act. A procedure is written in plain language, with steps for conditions, data connectors, sub-procedures and a human approval step. On 12 March 2026 Intercom stopped new Fin Task creation and moved every new build to Procedures. Intercom's own example of what a procedure does is to collect the order number, check eligibility and process the refund automatically.
Data connectors are the API calls a procedure makes. Intercom ships templates grouped by app. The Stripe connector page says Fin "can take actions like refunds and cancellations" with Stripe write templates, and that live use in production requires JWT or email OTP user authentication. The Shopify Storefront templates read and update carts, and Shopify order templates read order details. Anything else, such as a credit in your own billing system, is a custom connector pointed at an API you choose.
So the question for a finance or support lead is narrow. The answering part of Fin is safe to switch on. The part that can move money is the procedure, and a procedure is software you author.
How we measured the Intercom MCP server
On 30 September 2026 we probed Intercom's MCP hosts with no account and no credentials, so anyone can repeat it. Intercom runs one shared host per region: https://mcp.intercom.com/mcp for US workspaces and https://mcp.eu.intercom.com/mcp for EU workspaces, each with a legacy /sse endpoint. We requested both endpoints, fetched the OAuth protected resource document at the root and at /mcp, fetched the authorization server metadata, tried an Australian hostname, and sent randomly generated control paths at the root and under /.well-known/. The control paths keep a probe honest: several payment companies we measured earlier run catch-all servers that answer 200 to anything.
Both regional MCP endpoints returned 401 with a JSON error and a proper WWW-Authenticate: Bearer realm="OAuth" header. The authorization server metadata returned 200 with a registration endpoint, PKCE S256, the authorization code and refresh token grants, and none among the token endpoint auth methods, so public clients such as Claude, ChatGPT and Cursor can register themselves. Both control paths returned 404, so the host is not a catch-all.
Two results differ from the other vendors in our series. First, the OAuth protected resource document returned 404 at both locations, and the authorization server metadata lists no scopes_supported. Zendesk and Brex both publish their scope lists to anyone who asks. Intercom does not, so its permission model has to be read from the documentation rather than the wire. Second, the Australian hostname did not answer at all, which matches Intercom's note that AU-hosted workspaces are not yet supported.
Fourteen Intercom MCP tools, three writes, and none of them touch money
Intercom's developer documentation lists 14 tools on the MCP server. Eleven read: search, fetch, search_conversations, get_conversation, search_contacts, get_contact, list_companies, get_company, list_articles, search_articles and get_article. Three write: create_article, update_article and add_internal_note, and Intercom notes that internal notes are visible to teammates only.
The permissions it asks for are equally contained: read users and companies, read conversations, write conversations for internal notes, and read and write articles. There is no tool that replies to a customer, closes a conversation, changes a subscription or touches a payment. For a support lead asking "is it safe to connect Claude to Intercom?", that is a genuinely conservative design, and more conservative than a helpdesk that gives an assistant one broad write switch.
That also means the Intercom MCP server is not where your refund risk lives. The money path runs the other way: Fin, the customer-facing agent, calling out through data connectors to Stripe, Shopify or your own billing API. The Stripe connector page describes prebuilt MCP and data connector templates. In our measurement of payment MCP servers the Stripe MCP tool surface is a single generic stripe_api_write that covers any POST, refunds included. Whatever caps the refund has to sit on that path.
Where the refund limit lives in Intercom Fin Procedures
We read Intercom's help center articles on Fin Procedures, human-in-the-loop approvals, data connector templates, the Stripe connector and the Procedures FAQ. Here is what actually governs an AI refund.
The approval step is real, and it is per procedure. Intercom's "Loop in teammate / agent" step pauses a procedure and asks a teammate to decide before Fin continues. Intercom lists "refund or exception approvals" as the first example. The teammate answers in the inbox or in Slack, either by submitting a response so Fin resumes, or by taking over the conversation. You must configure at least one field to collect, and Intercom recommends a True/False field for approval decisions. A timeout and an escalation message are required before the procedure can go live.
The dollar threshold is a condition you write. To act on the decision, you add a Read attribute step and then an IF/ELSE condition: if Approved is True, proceed; if False, tell the customer. The same condition logic, including code conditions, is how you would say "only ask a human above 200 dollars". Nothing in Intercom sets that number for you.
No workspace-wide ceiling. The documentation we read describes no refund cap across procedures, no daily or monthly total, and no limit tied to the Stripe connector itself. The Procedures FAQ also notes that procedures cannot enforce a hard gate on escalation in chat. A second procedure written by a different admin, or a refund step added to an existing procedure, inherits none of the first one's limits.
Authentication is about the customer, not the amount. The Stripe templates require JWT or email OTP user authentication in production. That proves the person asking owns the account. It says nothing about how much Fin can return to them.
This is the same shape we found at Zendesk AI agents and Salesforce Agentforce: the platform governs which actions an agent may take and who may approve them, and leaves how much money those actions move to you.
Intercom Fin pricing, and the cost the outcome meter does not count
Intercom's pricing page, read 30 September 2026, charges 0.99 dollars per Fin outcome on every plan, on top of helpdesk seats at 29, 85 and 132 dollars per seat per month for Essential, Advanced and Expert. Fin Voice is 1.99 dollars per voice outcome through sales, Copilot is 29 dollars per teammate per month, and teams running Fin on another helpdesk contact sales. Since 12 March 2026 a procedure bills as an outcome when the conversation reaches a resolution or a procedure handoff to your team, and Intercom says you are never charged when a procedure fails. We work through a full budget in our Intercom Fin pricing guide.
Look at what that meter counts. A refund conversation that ends with Fin returning 400 dollars through Stripe costs 99 cents on the Intercom invoice. The 400 dollars appears on your Stripe balance, not on Intercom's bill, and no Intercom setting caps it. A refund is also the fastest way to resolve a refund request without a human, which is exactly the behavior an outcome meter rewards. None of that makes Fin a bad product. It means the outcome fee is the small, predictable number and the refund value is the large, uncapped one. Our AI agent cost breakdown shows the same split across vendors.
A rollout checklist for Intercom Fin refund procedures
- Start every refund procedure with a Loop in teammate step. Run it with a human deciding every refund for a few weeks, then read the decisions before you automate any band of them.
- Put the threshold in the refund service, not only in the procedure. An IF/ELSE condition in one procedure protects that procedure. A check in the service the connector calls protects every procedure, including the ones written next quarter.
- Set a per-refund cap and a daily total. A per-refund cap alone allows an unlimited number of small refunds, which is how a looping or manipulated agent leaks money.
- Refund only to the original payment method and never above the charge. That keeps a refund from becoming a payout to a new destination.
- Use a restricted Stripe key. Give the connector refund and read permissions only, never a full secret key that can create payouts or change bank details.
- Set the approval timeout to your support hours. Intercom lets you pause the timer outside office hours, so a refund request at midnight waits for a person instead of escalating into a queue nobody is watching.
- Log the decision with the conversation. Record the procedure, conversation, charge, amount, rule applied and approver, so a refund audit does not start from a processor export.
How AgentsPay fits alongside Intercom Fin
AgentsPay does not replace Intercom, Stripe or Shopify. It sits between the Fin procedure and the money. Your data connector calls AgentsPay instead of calling the Stripe refund endpoint directly, and AgentsPay applies the policy you set for that agent: a per-refund ceiling, a daily and monthly total, a match against the original charge, and an approval threshold that pauses larger refunds for a one-tap human decision. The connector's credentials cannot change that policy, and a new procedure cannot bypass it.
Every refund lands in an audit trail tied to the agent and the conversation. The same controls cover goodwill credits and account credits. For the general pattern, see our AI agent refunds use case, and for approval mechanics, human approvals for agent payments. You keep Fin's outcome meter for what it measures well and add a spend limit for the part it was never built to measure.