What should happen when tax, tip or shipping pushes an AI agent's charge above the amount a human approved?

What should I check, step by step?

1. Pick the overage policy per workflow: a pre-approved ceiling (quote plus a percent or a fixed amount) for routine buys, or hard re-approval for anything above the quote on high-value or one-off purchases.

2. Have the agent get the full price before asking: item subtotal, tax, shipping, fees, and whether a tip or gratuity can be added later. If tax or shipping isn't known yet, it says so instead of guessing.
3. Put the numbers in the approval action: quote_id, merchant, currency, quote_amount_minor, max_total_minor and the overage rule in words. request_human_approval hashes the canonical action, so the ceiling is part of what was approved.
4. Show the approver the quote and the ceiling side by side (for example: quote 84.00 USD, approving up to 95.00 USD for tax and shipping), not one blended number.
5. At checkout, compare the final total to max_total_minor in code. At or under: call authorize_spend with the final amount and the approval id in reference. Over: stop, and open a new request_human_approval with the new total.
6. Set the agent's per_tx_max_minor (set_spend_policy) no lower than the approved ceiling, or authorize_spend will deny a charge the human approved; and no higher than you'd accept without a person looking.
7. Set the card's per-authorization limit at the ceiling. On Stripe Issuing, captures for approved authorizations always succeed and over captures can't be blocked, so a tip added at capture shows up after the fact: catch it in reconciliation and dispute it if it wasn't legitimate.
8. Reconcile each capture against the approved ceiling. A capture above max_total_minor is an exception to investigate, with the approval record as evidence.

Why does an AI agent's final charge differ from the approved quote after tax, tip and shipping?

Many carts are priced before tax and shipping are known, and the final total appears only after the address is entered. That's normal, but it means a yes for the subtotal doesn't cover the total.

• Some categories finalize later. Stripe Issuing's docs say businesses such as restaurants, vehicle rentals and ground transportation may authorize one amount and capture more, for example a restaurant capturing the bill plus tip. Stripe's merchant-side overcapture docs list card-brand limits by category: Visa allows +30% for US restaurants, +20% for restaurants elsewhere and +15% for most other categories on cardholder-initiated payments; American Express allows +30% for restaurants.
• Where Strong Customer Authentication applies, Stripe notes merchants generally need to authenticate and authorize the highest amount they expect to capture, so the authorization can be higher than the quote from the start.

Should an AI agent purchase over the quote use a pre-approved overage or a new approval?

A pre-approved overage is a ceiling the human agrees to up front: quote plus 10%, or quote plus a fixed 15.00 for shipping. It keeps routine purchases moving and is still bounded, because the ceiling is in the approved action.

• Hard re-approval means anything above the quote goes back to a person. Use it for large or unusual purchases, new merchants, or when the overage could hide a different item or a price change.
• Either way, the agent doesn't decide the overage. If its instructions say about 50 and it pays 58, the approval didn't cover 58. The rule has to be written before the yes, and the comparison has to run in code at checkout.

How do I stop an AI agent from widening an approved payment amount on its own?

request_human_approval stores the SHA-256 of the canonical action plus a summary and an expiry. verify_human_approval with the action fails if any field changed, so the agent can't raise max_total_minor and reuse the old approval. A higher total needs a new request and a new decision.

• authorize_spend checks the final amount against the agent's spending policy (per-transaction and daily caps, merchant and category allowlists) and returns a signed allow or deny. Put the approval id in reference so the two records point at each other.
• Rightshold doesn't read carts, calculate tax or shipping, see card captures, or automatically compare authorize_spend amounts to an approval. Those checks run in your checkout step and in reconciliation; the Rightshold records show who approved which ceiling and what was authorized.