remove the REFUNDED card transaction status from the spec - #909
remove the REFUNDED card transaction status from the spec#909ls-bolt[bot] wants to merge 1 commit into
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
|
|
@greptile review |
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-typescript studio · code · diff
✅ grid-openapi studio · code · diff
✅ grid-ruby studio · code · diff
✅ grid-kotlin studio · code · diff
✅ grid-go studio · code · diff
✅ grid-python studio · code · diff
✅ grid-php studio · code · diff
✅ grid-cli studio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
A card transaction's status tracks the settlement lifecycle only. A merchant return is reported through direction and refundedAmount, so REFUNDED double-encodes a fact two fields already carry — and the server has no code path that emits it. Drops REFUNDED from CardTransactionStatus and CARD_TRANSACTION.REFUNDED from WebhookType, and corrects the prose that described the flip. The return-reversal simulator's stated precondition was actively wrong: it gates on a non-zero refundedAmount, not on a REFUNDED parent. Co-Authored-By: aaryamanbhute <aaryamanbhute@users.noreply.github.com>
84dcf10 to
5d26886
Compare
|
⚡ Revision log — updated in place, latest first. Revision 1
|
|
⚡ Review ledger Round 1
|
|
@greptile review |
|
That revision addresses the ambiguity: “every lifecycle update” no longer implies that each delivery is a state transition, and it explicitly documents repeated |
|
📌 Bolt Status 2026-09-08 18:36:00 UTC — ⚡ Agent |

Summary
CardTransactionStatuscarried aREFUNDEDvalue the server has no code path to emit,and
WebhookTypecarried a matchingCARD_TRANSACTION.REFUNDEDevent that is neverfired. A card transaction's status describes the settlement lifecycle only — a merchant
return is already reported by
directionandrefundedAmount, so aREFUNDEDstatuswould double-encode a fact two fields carry.
This removes both values and corrects the prose that described the removed behavior.
What changed
Enums
CardTransactionStatus— droppedREFUNDED; four values remain (AUTHORIZED,PARTIALLY_SETTLED,SETTLED,EXCEPTION). The status table'sSETTLEDrow nowstates that a later
RETURNkeeps the transactionSETTLEDwith the returned valuein
refundedAmount.WebhookTypeandCardTransactionWebhook.type— droppedCARD_TRANSACTION.REFUNDED.Corrected prose
"the parent transaction must be in
REFUNDEDstate", a state that cannot occur, so anintegrator following it would test against something unreachable. It now says the
parent must have a posted return (non-zero
refundedAmount), which is what theendpoint actually gates on.
SandboxCardReturnRequest— a full return no longer "flips theparent to
REFUNDED"; full and partial both keep itSETTLEDwithrefundedAmountset.
CARD_TRANSACTION.REFUNDEDfrom theevent list. It now describes the webhook as firing on every lifecycle update rather
than every state transition, since a return changes no status: a repeated
CARD_TRANSACTION.SETTLEDis a new update, not a duplicate, andrefundedAmount/refundSummaryare what distinguish a return from the original settlement. Theexample payload previously carried
type: CARD_TRANSACTION.REFUNDED/status: REFUNDEDand now carries the settledshape with a non-zero
refundedAmount.CardTransaction.directionsaid "card transactions debit the customer's account",which is not true of a standalone merchant refund. It now describes both directions.
Changelog — new September 2026 entry.
Scope note
TransactionStatus.REFUNDEDis a different enum for cross-border payments and is stilllive; it is untouched, as is the incoming-payment webhook note that references it.
Breaking-change check
oasdiffreports 17 errors, allrequest-property-enum-value-removedfor the twointended values. The count is inflated by fan-out:
CARD_TRANSACTION.REFUNDEDlives onthe shared
BaseWebhook.type, so its removal is reported once per webhook path. Thereare no other findings, and no warnings.
Removing a value a server never emits does not change any response a client has
received. Card issuance is gated per-platform, there is no production card history, and
status was never a stored column — it is re-derived on every read — so transactions
written before the redesign already report
SETTLEDrather than a staleREFUNDED.Test plan
This is a spec + docs repo with no application code, so verification is the spec
toolchain:
npm run lint:openapi— exit 0. 901 problems / 0 errors / 179 warnings, byte-identicalto the pre-change baseline, so nothing new was introduced.
npm run build:openapi— rebundledopenapi.yamlandmintlify/openapi.yaml; the twoare identical, and the bundle diff contains exactly the source edits (no stale-base
drift).
markdownlinton every touched.mdx— same 5 pre-existing findings as onmain,none from this change.
oasdiff breakingagainstorigin/main— reviewed all 17 findings; each is one of thetwo intended enum removals.
REFUNDEDacross the repo and confirmed every remaining hit belongs to thecross-border
TransactionStatusenum.No client SDKs are checked into this repo —
sdks/grid-typescriptandsdks/grid-kotlinare empty, and clients are generated by Stainless from the spec, which the
previewCIcheck builds on this PR.