docs: correct payment and fee semantics
This commit is contained in:
@@ -56,7 +56,7 @@ These are source codes, not Persian user-facing descriptions. Meanings and succe
|
||||
|---|---|---|
|
||||
| `try_seq` | 0–135 | `smallint`, non-negative |
|
||||
| `amount` | 1,000–2,000,000,000 | `bigint`, Rial |
|
||||
| `adjusted_fee` | 1,920–284,800 | fixed-precision numeric; obfuscated relative fee only |
|
||||
| `adjusted_fee` | 1,920–284,800 | positive integer merchant-fee value; confidentiality-adjusted in the challenge source and normalized as real `fee_amount_rial` per ADR 0013 |
|
||||
| `init_time_ms` | 44–59,905 | nullable integer milliseconds |
|
||||
| `verify_time_ms` | 35–58,553 | nullable integer milliseconds |
|
||||
| `expire_in` | timestamp strings | rename canonically to `expires_at`; it is not a duration |
|
||||
@@ -68,7 +68,8 @@ No negative or zero amount/fee/timing values were observed. Source identifiers a
|
||||
- Each observed category id has one Persian title.
|
||||
- The quick scan found no merchant-to-category or terminal-to-owner conflict, but exact staging validation remains mandatory because session rows are not contiguous.
|
||||
- Merchant volume is highly skewed: median merchant has 78 attempts, p95 has 8,915, and the largest has 1,138,592. Unweighted merchant benchmarks and volume-weighted transaction benchmarks answer different questions and must be named separately.
|
||||
- One terminal/merchant/category and one amount/session relationship are proposed invariants, subject to exact staging validation before constraints are finalized.
|
||||
- One terminal/merchant/category, amount/session, and fee/session relationship are proposed invariants, subject to exact staging validation before constraints are finalized.
|
||||
- All 150,450 rows repeating a previously observed session repeated the same `adjusted_fee`; zero fee conflicts were found. The normalized model therefore stores the fee once per session rather than once per attempt.
|
||||
|
||||
## Timestamp quality
|
||||
|
||||
@@ -110,7 +111,6 @@ Populated `payer_card_key` values are opaque alphanumeric tokens 6–11 characte
|
||||
|
||||
- Drop anomalous rows silently
|
||||
- Replace missing values with plausible defaults
|
||||
- Treat `adjusted_fee` as ZarinPal's real fee
|
||||
- Sum the repeated source fee at attempt grain
|
||||
- Depend on CSV row order
|
||||
- Claim payer tokens represent verified people
|
||||
|
||||
|
||||
Reference in New Issue
Block a user