Approval and audit tools are separating from AI payment assistants

The boundary of responsibility changed before payment did

When an AI work assistant acts through a business account, the operator—not the assistant—may be responsible for the result. Stripe made that direction clear in an update to its US business terms on September 28, 2026: actions initiated by AI work assistants with access to Stripe services are the account user’s responsibility. The change applied that day to new users and newly added service terms. Changes with a material effect on existing services apply to existing users from January 6, 2027.

The announcement covers the account broadly, but the revised terms directly state responsibility for AI work assistants in Stripe Atlas. Atlas is Stripe’s service for helping people form US companies and handle related paperwork. The terms say that actions an assistant starts or completes in Atlas have legal effect for the user, and that the user is responsible for them.

That does not mean every Stripe payment and refund received a new liability clause at once. But the direction is clear: when an assistant handles hard-to-reverse work involving company formation, payments, or customer data, Stripe places responsibility with the operator rather than the assistant.

Separate terms for AI-enabled purchasing and payments are more specific. Operators must keep verifiable records of the customer’s consent and the scope of authority, including spending limits, permitted merchants, and validity periods. If an assistant’s error or poor judgment creates a transaction outside that authority, the operator is responsible in its relationship with Stripe.

Stripe Console terms also require users to independently review proposed actions before execution. It is not enough for the account to retain only the transaction result. An operator needs to be able to explain, outside the account as well, who delegated what work and which rules and approvals governed its execution.

Records emerge that payment services cannot hold

Until now, it was usually acceptable for permissions and records to stay inside a payment service. The company moving money already knew user permissions, transaction time, and refund outcomes, so there was little reason for a separate approval tool.

Consider an operations lead at an international subscription company with 12 employees. The company lets an AI customer-support assistant look up orders and create refund requests when they meet the refund policy.

Today, the operations lead copies an order number posted by the assistant from the support screen into an internal messenger. After getting approval, they search for the customer and amount again in the payment screen. For an exceptional refund, they look up the policy in a shared document. After processing it, they write “complete” in the messenger.

The same order number and amount move across several screens. If a dispute happens later, it is hard to check in one place which customer request the assistant read, which policy applied at the time, and whether the approver saw the full context before approving it.

The piece that can separate is not payment itself. It is an approval-and-evidence screen. Placed between the AI assistant and the payment service, it stores the original request, the assistant’s reasoning, the policy applied, the amount, the approver, and the execution result as one package.

The same operations lead can then review only exceptional cases in a refund-request list. Pressing approve sends the request to the payment service within a defined limit. Rejecting it adds the reason to a draft customer response. The final result remains attached to the same order record.

Some work still belongs to people. A person must decide when delivery or service-use status is unclear, whether to offer an out-of-policy concession to a regular customer, or whether fraud is suspected. This tool does not take responsibility away. It brings the material and records needed to take responsibility into one place.

That is also why this piece can be sold separately. A payment company knows whether a transaction succeeded, but it does not know every company’s refund policy, internal seniority structure, or customer-conversation context. An approval screen that holds operating rules can therefore become an independent product connected to several payment services.

Controls were separated from execution first

Ramp, a US business-spend management service, combines vendor-specific cards and budget limits, invoice approvals, and accounting records in one place. Perplexity, which has an increasing number of subscriptions, used cards with merchant and budget restrictions for each vendor, and routed high-value invoices to designated approvers.

According to a Ramp customer story, Perplexity classifies more than 97% of roughly 7,000 to 9,000 monthly card transactions without manual re-entry and saves 163 hours a month. These are vendor-published figures and need independent verification. What matters here is that the company made merchant restrictions and approval routes into a product before handing payment over entirely to AI.

Tipalti, a US payment-management service, reads invoices and recommends the appropriate approver, while leaving the final decision to a person. Its public price starts at about KRW 140,000 per month for core features, with further costs based on invoice volume, payment volume, and additional features.

NEXT Insurance processed more than 1,000 invoices a month using the service. Tipalti says its approver-recommendation feature saved more than two hours each week. This too is a vendor case-study figure and needs separate verification.

Four products that can be separated out

1. Refund approval inbox

• What it does: Collects refund requests created by a customer-support assistant, and separates cases that match company policy from cases requiring human judgment.
• Who uses it: A small online service company where one or two support staff handle subscription cancellations and partial refunds for overseas customers.
• Why now: Because the operator can be responsible even when the assistant makes a wrong judgment, the original request, reasoning, and approval result need to remain together.
• First screen: A request list with customer name, order number, refund amount, applied policy, the assistant’s reasoning, and approve and reject buttons.

2. Spend-permission cards

• What it does: Gives each AI work assistant a card-like permission setting for the amount, merchants, period, and purpose it may use, and blocks requests outside that scope.
• Who uses it: A creative studio of around 10 people where staff and automation tools both pay for advertising and design-tool subscriptions.
• Why now: Account access alone no longer makes it easy to explain which purchases were delegated, creating a need for a screen that narrows authority before action.
• First screen: About four cards showing each assistant’s remaining limit, permitted merchants, expiry date, and recently rejected requests.

3. AI work receipt

• What it does: Organises the original request, reasoning, applied policy, human approval, and actual payment or refund result in chronological order for download.
• Who uses it: An implementation agency that builds customer-support assistants for several online stores and needs to share operational responsibility.
• Why now: A transaction record in a payment screen cannot show why an assistant acted, creating a need for separate evidence of the work.
• First screen: Search by transaction number to see a chronological record from request to completion, along with missing evidence.

4. Unusual-action stop board

• What it does: Stops execution and alerts a person when it finds predefined conditions, such as repeated refunds in a short period, a new bank account, or an amount larger than usual.
• Who uses it: An operations agency that handles overnight inquiries and refunds for several online stores with one assistant.
• Why now: As the range of actions performed without human review grows, a mechanism that stops an action before execution becomes more valuable than records found only after a problem occurs.
• First screen: Current stopped requests, the reason for each stop, expected amount, approver, and buttons for “approve one” and “stop all.”

What to check today

Call one operator who uses Stripe and ask where the requester, reasoning, approver, and outcome for their most recent refund each remain. If finding the answer requires opening more than two screens, or if any one of those four items cannot be verified, it is worth building and showing the first screen of a refund approval inbox.

Why this matters where you are

Check whether a recent refund or purchase can be explained from the original request through approval and final outcome without moving between several tools. Payment providers, policies, and approval structures may differ in your market, but the need to define authority and retain evidence can be tested with the same workflow.