# TRADOM — 前払い型 vs 後払い型 Side-by-Side Comparison

## 🔑 Core difference

|  | **前払い型** (Pre-Payment) | **後払い型** (Post-Payment) |
|---|---|---|
| **Source diagram name** | 商品引渡し後履行型 | 商品引渡し先履行型 |
| **Order of events** | Pay → Ship | Ship → Pay |
| **Who bears default risk** | Buyer (already paid before getting goods) | TRADOM / Seller (goods sent before payment) |
| **Credit review depth** | 事前審査 (preliminary, lighter) | 厳密版 (strict) |
| **Sales contract info at inquiry** | ❌ Not required | ✅ Required |
| **When invoice is created** | Up front, bundled with application | After delivery |
| **Admin approval gates** | 1 combined gate (review + invoice check together) | 2 separate gates (review first, then invoice check after shipping) |
| **Admin shipping-phase role** | Monitor (取引モニタリング) | None (Seller already approved to ship) |

---

## 📋 Phase-by-phase comparison

| Phase | 前払い型 | 後払い型 |
|---|---|---|
| **1. Inquiry** | Seller creates **取引申請** (formal application) | Seller submits **問い合わせ** (inquiry) — includes 売買契約情報 |
| **2. Review** | 事前審査 on Buyer | 厳密版 与信審査 on Buyer |
| **3. Invoice** | Created **NOW** — uploaded with application | Created **LATER** (after delivery) |
| **4. Payment** | Buyer pays now | Not yet — happens after delivery |
| **5. Shipping** | Seller ships **after** payment confirmed | Seller ships **immediately** after review passes |
| **6. Settlement** | Same: TRADOM converts crypto → fiat → pays Seller on agreed date | Same |

---

## 👤 What changes for each role

### Seller

| | 前払い型 | 後払い型 |
|---|---|---|
| Phase 1 deliverables | Application + invoice + docs | Inquiry + **sales contract info** + docs |
| Invoice timing | Front-loaded (Phase 1) | Back-loaded (after delivery) |
| Shipping trigger | Payment confirmation email | Review approval email |
| Total manual steps | ~9 | ~10 |

### TRADOM Admin

| | 前払い型 | 後払い型 |
|---|---|---|
| Review type | 事前審査 (lighter) | 厳密版 (stricter, more scrutiny) |
| Invoice check timing | Bundled with application review | Separate gate after delivery |
| Shipping-phase activity | Active monitoring | No action |
| Number of approval decisions | 1 (combined) | 2 (review, then invoice) |

---

## 🔁 What stays the same

Both flows share the following:

- Seller is pre-onboarded and pre-审査ed.
- 代物弁済契約 (dation in payment): debt is assigned from Seller to TRADOM at the point the payment link is sent to Buyer.
- Buyer payment screen flow: ToS agreement → 代物弁済契約 → wallet/chain selection → 送金.
- Reconciliation outcomes: 一致 / 不足入金 / 超越入金 with the same auto-refund behavior.
- Refund-after-settlement flow (Buyer requests, Seller agrees/declines).
- Settlement mechanics: crypto → fiat off-ramp → Fiat 振り込み to Client A on the agreed date.
- All status emails and 連動処理 patterns.

---

## ✅ Resolved behaviors (consistent across both flows)

| Topic | Behavior |
|---|---|
| **受け取り完了 status switch** | ⚙️ **Automated** — system switches status when delivery is confirmed. |
| **金額照合 (reconciliation)** | 🟢 **Manual admin decision.** The system flags mismatches but the admin declares whether amounts match and decides the action. |
| **不足入金 re-payment** | ✅ After auto-refund, **Buyer may re-pay** and the transaction resumes. |
| **インボイス問題あり** | 🛑 Process is **halted**; admin contacts Seller manually (email/phone) to confirm. |
| **追加確認あり in review** | 📞 Handled via **email or phone**; admin can leave notes in 管理画面. |