starcoach-hackathon/zarinpal-analytics-backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(data): locate verification policy on terminals

Browse Source
This commit is contained in:
Amirhossein Khalili
2026-08-20 18:23:36 +03:30
parent af69f549c0
commit 08ac99a5a6
2 changed files with 4 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
CONTEXT.md
View File

@@ -14,11 +14,11 @@ A time-bounded and revocable authorization grant connecting one authenticated me
## Terminal ## Terminal
A merchant-owned payment endpoint identified by the source terminal key. A merchant-owned payment endpoint identified by the source terminal key. In the challenge archive, the terminal also carries its invariant verification method (`Automated` or `Manual`); one merchant may own terminals configured differently.
## Payment Session ## Payment Session
One payment journey identified by the source session key. A session belongs to one merchant and terminal and can contain one or more payment attempts. One payment journey identified by the source session key. A session belongs to one merchant and terminal and can contain zero or more payment attempts.
## Payment Attempt ## Payment Attempt

2
docs/DATA-PROFILING-REPORT.md
View File

@@ -73,6 +73,8 @@ No negative or zero amount/fee/timing values were observed. Source identifiers a
- One terminal/merchant/category, amount/session, and fee/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. - 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.
- The CTO guide defines `psp_code` at attempt grain and namespaces `switch_response_code` by PSP; identical raw response codes from different PSPs are not semantically interchangeable. - The CTO guide defines `psp_code` at attempt grain and namespaces `switch_response_code` by PSP; identical raw response codes from different PSPs are not semantically interchangeable.
- A complete 2,213,289-row scan found `verify_type` invariant within every terminal (zero of 348 terminals had multiple values). One merchant had more than one value because it owned terminals configured differently. The normalized physical model therefore stores verification type on `terminals`, not `payment_attempts` or `merchants`.
- Maximum observed source text lengths were measured for type/index review: session key 7, terminal key 4, merchant key 4, category key 8, category title 34, session status 8, attempt status 9, switch response 11, PSP code 6, bank code 7, payer token 11, and verification type 9. Physical source identifiers remain `text` so opaque upstream formats are not frozen to challenge-only maxima.
## Timestamp quality ## Timestamp quality