AI in Commerce1 min read
Explaining a declined transaction with an LLM
A merchant asking "why was this declined?" is a common support ticket. What a well-designed LLM assist looks like — and where it must refuse.
"Why was this transaction declined?" is one of the most common merchant support tickets. It also has one of the most consistent shapes. This makes it a good candidate for an LLM-assisted response — with narrow guardrails.
Written January 2026 from an internal pilot.
What the assist can do
- Explain the decline code in plain English. Every scheme's decline codes have documented meanings. The LLM produces a merchant-friendly explanation with the code and the source.
- Cross-reference against the transaction context. "This decline typically happens when the AVS check fails. In this transaction, the postal code the customer entered didn't match the issuer's record."
- Suggest a next action. "The customer should verify their billing address with their card issuer, or the merchant can re-attempt with a corrected address."
What the assist must not do
- Speculate about issuer decisions the merchant can't verify. The exact reason an issuer declined is usually not disclosed; the LLM should not invent one.
- Reveal fraud signals the merchant shouldn't see. If the platform declined for fraud reasons, the message to the merchant should be generic, not diagnostic.
- Advise the customer directly. The LLM produces content for the merchant to relay; not content that goes to the customer.
The refusal path
When the transaction context is ambiguous, the LLM should say so and route to a human. "This transaction has an unusual decline pattern I can't confidently explain. I've flagged it for support review."
The design decision that matters is what the LLM is not allowed to do. That list is longer than the list of what it does.