Why
Card rails bake refunds into the protocol: reverse the charge, the network handles the money. Crypto rails bake in the opposite: nobody can reverse anything, ever. Products read this as refunds are impossible — but the customer promise never went away, so what actually happened is that the refund moved up a layer: it is now a second payment, flowing the other way, that your application must create, fund, authorize and account for.
That relocation raises exactly the questions card networks answered internally: who approves (support agent, policy rule, second signer), within what window, from which pool of money (refunds need a funded balance — the original payment may already be swept), and how the pair is linked so accounting sees one net event rather than two unrelated transfers. An on-chain reference from refund to original makes the link auditable by anyone — one small advantage the transparent rail adds over the card networks it is imitating.
How it works
A payment, a linked counter-payment, a policy gate, and one reconciled ledger.
PoC
On anvil: a merchant contract (or plain transfers plus a server ledger) where checkout records { paymentId, payer, amount }. Refund path: a support action creates a refund intent referencing paymentId; policy engine checks window (≤ 14 days), amount (≤ original, cumulative across partial refunds), and approver role; the refund pays from a dedicated refund-budget wallet and emits or memos the original paymentId. Ledger view joins the pair and shows net. Tests: double-refund blocked, partial refunds sum-capped, empty refund budget fails loudly before promising the customer, and the x402-settlement-retry boundary — a refund of a payment whose settlement later failed.
What it proves
Irreversibility is a property of the rail, not of the business. The product re-creates reversal as composition — new payment plus reference plus policy — and the hard parts are the ones card networks hid: funding the refund pool and defining who may say yes. This card is the support-desk face of receipt-is-not-settlement.
Where it lands in Jayverse
- Verex: model a refund as its own payment, not a chargeback, in the Stripe-onboarding path. Give it a reference to the original paymentId, an approval policy (window, cap, approver role) and a funded refund-budget wallet, since settlement on Verex's rails can't be reversed the way a card network reverses a charge.
- Wallet: add a reconciliation ledger view that joins a payment and its refund into one net event. Test double-refund blocked and partial refunds sum-capped before a real refund request happens, the same way the card's PoC does.
- Auditor: write down who may approve a refund and from which balance, before it's needed. The same authority-matrix question card networks answered internally has to be answered explicitly for any Jayverse product that takes payments on irreversible rails.
Key expressions
| Expression | 뜻 · 쓰이는 자리 |
|---|---|
| bake in | (특징을) 처음부터 내장시키다 · 프로토콜 설계에 기능이 포함되어 있을 때. "Card rails bake refunds into the protocol" |
| reverse the charge | 결제를 취소·역행시키다 · 카드망의 환불 처리 방식을 설명할 때. "reverse the charge, the network handles the money" |
| sweep (verb) | (자금을) 쓸어가다, 이체해 비우다 · 원래 결제금이 이미 옮겨졌을 때. "the original payment may already be swept" |
| relocation | (문제·책임의) 위치 이동 · 환불 책임이 다른 계층으로 옮겨갔을 때. "That relocation raises exactly the questions" |
| sum-capped | 합계에 상한이 걸린 · 부분 환불 총액을 제한할 때. "partial refunds sum-capped" |
| fail loudly | 조용히 묻히지 않고 명확하게 실패를 알리다 · 잔액 부족을 즉시 드러낼 때. "an empty refund budget fails loudly" |
| cumulative | 누적된 · 여러 번의 환불을 합산해서 볼 때. "amount... cumulative across partial refunds" |
| support-desk face of | ~의 고객지원 창구 버전(같은 원리의 다른 적용) · 앞선 개념이 다른 맥락에 적용될 때. "the support-desk face of receipt-is-not-settlement" |