What the documents look like
Cross-border independent-site payment risk control operates around card-network disputes and the receiving account. The materials handled include chargeback notices, fraud order lists, invoices, and proof of carrier delivery. This differs from order-fulfillment scenarios that center on parcel status. Data sources are spread across the acquiring back office, independent-site orders, carrier delivery records, and customer-service email. The update rhythm is daily or per order.
Operating reports and anomaly reviews need to group these materials along two lines: order and funds. The conversation logs and audit step aligns system-side session records with business-side materials, so that during review it is possible to state which entry point a record came from, which conversation it belongs to, and what state it was in at the time.
Constraints at the conversation logs step
Conversation identity is defined by chatId. Sessions from different entry points under the same application must be checked separately and cannot be merged in counting. When run details are needed, set detail according to the official contract and inspect the module status and complete results in responseData. Non-streaming results are held in responseData; streaming distinguishes them through event. Which fields the interface actually returns determines what verification the logs can support. Business data that is not returned cannot be assumed to be fully retained. Identity fields in test mode and formal calls may differ, so input, history, and returned content need separate checks. Reconciliation, retention, and compliance requirements are implemented by the complete business solution; the existence of logs does not by itself complete a compliance audit.
Hypothetical paper exercise sample. On 10 March 2025, a risk specialist at an independent site received a chargeback notice for one order. The source material reads: "Order number A-2291, delivered 6 March 2025, signed for by Li, carrier receipt number SF-88213" and "This order's payment channel is an overseas acquirer, amount 218 USD, cardholder filed an unauthorized-transaction dispute." The draft handover request is: "Please archive A-2291's conversation logs together with the delivery proof for this chargeback evidence preparation." This request is pending. No archiving has been executed, and no authorization conclusion has been obtained.
Configuration and implementation checks
| Configuration item | Purpose on this page | Value note |
|---|---|---|
| appId | Locate the target application | Passed when calling chat and history interfaces; verifies session ownership |
| chatId | Locate the target session | Length under 250, unique under one application; check each entry point separately |
| detail | Obtain run details | Set true when responseData is needed; non-streaming results are held in responseData |
| source | Filter session origin | source=api retrieves only API-created sessions, not page sessions |
| loadCustomFeedbacks | Read feedback | Set true when feedback is needed |
| dataId | Locate a single exchange | Used when obtaining single-exchange run details and updating feedback |
These values are the starting point for this hypothetical exercise. The reason for choosing them is to align A-2291 in the sample with its corresponding session item by item. The comparison object is the chatId and dataId returned by the interface against the order number and receipt number in the business material. Numeric values and switches follow fields already described in the official documentation.
Three common errors
- Merging sessions from different entry points under one chatId in statistics. In the sample, A-2291's conversation may come from a customer-service email entry point and an API entry point. The input is the two session records; the comparison is whether the chatId values match; the observable result is that counting the two records as one session is an error.
- Substituting retrieval results for an authorization judgment. The input is the draft handover request sentence; the comparison is whether that sentence carries a signed authorization or a completed approval; the observable result is that treating archiving as authorized solely because logs exist is an error.
- Treating unreturned fields as retained. The input is a detail=true response; the comparison is between the fields actually present in responseData and the fields the review requires; the observable result is that marking a missing field as fully retained is an error.
How to verify the setup
- Input the sample source material and the draft handover request sentence. Compare the order number and receipt number in the request sentence against the chatId and dataId returned by the interface. The check passes when the three align to the same record and the status is marked as pending.
- Input a detail=true request. Compare the module status and complete results in responseData against the run information the sample requires. The run-detail check passes when the required fields appear in the return; when they do not appear, record the gap.
- Input a session-list request with source=api. Compare the returned list against page sessions. The origin-filter check passes when the list contains only API-created sessions; if page sessions appear, record the anomaly.