PayChain Medium Series · 5 Parts

Part 2 of 5

프로토콜에서 체인으로 — Tx와 Receipt

From Protocol to Chain — Tx and Receipt

transaction hash는 왜 금융 기록이 아닌가

Why a transaction hash is not a financial record

Pay Protocol · PCI Network · PayChain · June 2026 · ~12 min read

1. 결제는 이벤트처럼 보이지만, 실제로는 상태 변화다

1. Payment looks like an event, but is a state change

사용자는 결제를 한 번의 이벤트로 경험합니다. 그러나 금융 시스템에서 결제는 끝이 아니라 시작입니다. Stripe의 PaymentIntent는 requires_payment_method → … → succeeded 같은 여러 상태를 거치고, Dispute는 needs_response → won/lost로 이동합니다. 성공한 결제도 이후 분쟁 lifecycle로 다시 들어갈 수 있습니다. 결제는 하나의 transaction이 아니라 lifecycle입니다.

The user experiences payment as a single event. But in a financial system, payment is a beginning, not an end. Stripe's PaymentIntent moves through states like requires_payment_method → … → succeeded, and a Dispute moves needs_response → won/lost. Even a successful payment can re-enter a dispute lifecycle. Payment is a lifecycle, not a single transaction.

2. 결제 네트워크의 가치는 정산 구조에서 나온다

2. A payment network's value comes from its settlement structure

Visa(FY2025 14.2조 달러·2,575억 건)와 Stripe의 본질은 결제 처리가 아니라 신뢰 가능한 금융 네트워크와 운영 추상화입니다. 사용자는 결제 성공 메시지를 보지만, 가맹점은 언제 얼마가 입금되는지, 플랫폼은 수수료를 어떻게 나눌지, 회계팀은 어떤 근거로 장부에 반영할지, 감사인은 어떤 기록을 제출할지를 봐야 합니다. transaction hash는 이 정보의 일부일 뿐입니다.

The essence of Visa (FY2025: $14.2T, 257.5B) and Stripe is not payment processing but a trustworthy financial network and operational abstraction. The user sees a success message, but the merchant must see when/how much arrives, the platform must split fees, accounting must book it on a basis, and the auditor must later produce records. A transaction hash is only part of that.

3. Transaction hash는 금융 기록이 아니다

3. A transaction hash is not a financial record

같은 100 USDC 전송도 상품 구매·파트너 정산·급여·상환·escrow 해제·환불일 수 있습니다. 온체인에서는 동일하지만 금융적으로는 전혀 다른 사건입니다. transaction은 실행을 기록하고, Receipt는 금융 행위의 의미를 설명합니다. PayChain의 핵심 질문은 “어떻게 더 빠르게 처리하나”가 아니라 “어떻게 transaction을 금융적으로 해석 가능한 record로 바꾸나”입니다.

The same 100 USDC transfer can be a purchase, partner settlement, payroll, repayment, escrow release, or refund. Identical onchain, entirely different financially. A transaction records execution; a Receipt explains the meaning of the financial act. PayChain's core question is not “how to process faster” but “how to turn a transaction into a financially interpretable record.”

4. Receipt는 영수증이 아니라 금융 행위의 기본 객체다

4. A Receipt is the base object of a financial act

Receipt는 단순 결제 확인서가 아니라, 하나의 금융 행위가 어떤 주문·payer·merchant·수수료 정책과 연결되는지, 현재 어떤 상태인지, 어떤 Batch에 포함되는지, 환불·분쟁 가능성이 있는지를 담는 business primitive입니다. 기업은 transaction hash가 아니라 거래의 근거(invoice·승인·정산·감사 자료)를 필요로 합니다.

A Receipt is not a payment slip but a business primitive capturing which order, payer, merchant, and fee policy a financial act connects to, what state it is in, which Batch it joins, and whether refund/dispute remain possible. Businesses need the basis of a transaction (invoice, approval, settlement, audit material), not a transaction hash.

5. 금융은 event log가 아니라 state machine이다

5. Finance is a state machine, not an event log

PayChain의 Settlement State Machine에서 각 상태는 enum 값이 아니라 책임·증빙·복구·회계가 달라지는 지점입니다. 기술적 finality(되돌릴 수 없음)와 운영적 finality는 다릅니다. 환불은 원거래를 되돌리는 것이 아니라 새 상태를 만들고, 분쟁은 의미를 재검토하며, 회계 수정은 장부 해석을 조정합니다.

In PayChain's Settlement State Machine, each state is not an enum value but a point where responsibility, evidence, recoverability, and accounting change. Technical finality (irreversibility) differs from operational finality. A refund creates a new state rather than reversing the original, a dispute reexamines meaning, and an accounting fix adjusts ledger interpretation.

Mechanics: 요약

Mechanics: summary

• POST /api/receipts → Receipt (멱등 requestId / Idempotency-Key)
• 전이: Authorized → Committed → Batched → Anchored → Settled (+ Refunded/Disputed)
• COMMITTED → 결정론 Batch → payloadHash
• GET /api/receipts/proof/:receiptId → batch·anchor 바인딩 (Merkle 필드 opt-in)

• POST /api/receipts → Receipt (idempotent requestId / Idempotency-Key)
• Transition: Authorized → Committed → Batched → Anchored → Settled (+ Refunded/Disputed)
• COMMITTED → deterministic Batch → payloadHash
• GET /api/receipts/proof/:receiptId → batch/anchor binding (Merkle fields opt-in)

다음: Part 3 — 하이브리드 신뢰

Next: Part 3 — Hybrid Trust

Receipt와 상태를 정의했다면, 그 상태는 어디에서 운영되어야 할까요? Part 3은 퍼블릭과 퍼미션드 사이의 하이브리드(PCI는 신뢰를, PayChain은 실행을 제공한다)를 다룹니다.

Once Receipt and state are defined, where should that state be operated? Part 3 covers the hybrid between public and permissioned: PCI provides trust, PayChain provides execution.