What the documents look like
Payment risk control in this category centers on card network disputes and receiving accounts. The working materials are chargeback notices, fraud order lists, invoices, and carrier proof of delivery. They arrive from payment backends, order systems, carrier delivery records, and customer service email. When these materials need to be shown to customer service staff or external collaborators, a no-login share window is commonly used to publish an access link and embed the conversation entry into an existing system.
The access link itself is only an address. It does not carry business authorization. Once chargeback evidence and order information move through a share entry, who may view and follow up under what authorization state requires separate verification. The materials update daily and per order; that cadence does not by itself create any synchronization or trigger mechanism.
Constraints at the shared access step
The no-login window generates a localId for each user and pulls conversation records from the cloud. It only guarantees use on the same device and same browser. Switching devices or clearing browser cache loses those records, so only the most recent 30 days and 20 records are allowed to be pulled. Identity verification is a POST request root address. Share link initialization, conversation start, and conversation finish each send a request to that address. The server returns success and uid, and FastGPT uses whether success is true to decide whether the user may continue. The uid must be a string that does not contain "|", "/", or "\\" and must be no more than 255 bytes in length; otherwise an Invalid UID error is returned. Identity verification is available only in the commercial edition, and parameters such as expiration time, QPM, and points cap are partly configurable only in the commercial edition.
Hypothetical drill sample: a direct-to-consumer site risk specialist plans to embed a chargeback appeal conversation entry into a customer service workspace for an external settlement colleague to view. The material text to be checked reads: the chargeback notice states "Order SO-2261, charged on 14 March 2026, dispute reason: goods not received"; the carrier proof of delivery states "SO-2261 was signed for in person on 21 March 2026"; the customer service email states "the customer says the goods were not received and requests a refund." The proposed embedded link is the original share link with authToken=settle2261 appended. The draft sentence to be judged is: "This order was signed for, the chargeback does not stand, and the dispute can be closed directly." The handover request is: "Please have the external settlement colleague view and confirm the handling opinion through this share link."
Configuration and implementation checks
The table below addresses the sample above and lists only settings or implementation checks that the official text describes. A hypothetical starting point states why it was chosen and what it is compared against; it is not an official default.
| Configuration item | Approach for this page | Check method |
|---|---|---|
| Identity verification root address | Enter the third-party verification root address without a specific path | Check that initialization, conversation start, and conversation finish requests all go to that root address |
| authToken | Append authToken=settle2261 to the share link | Compare whether the token in the request body equals that value |
| uid return | The verification interface returns a uid without forbidden characters and within the byte length limit | Compare whether the returned uid matches the identifier used to pull records |
| Expiration time | Set according to this viewing scope; the hypothetical starting point is invalidation after handover completes | Compare the current time with that setting to judge whether the link remains usable |
| QPM | Set according to the external colleague's access frequency; the hypothetical starting point is a small number of visits per minute | Compare the same user's actual visits per minute with that value |
| Points cap | Set according to the estimated usage for this viewing | Compare the link's cumulative billing data with that value |
Three common errors
- Treating the share link identifier as business authorization. Link accessibility does not mean the external settlement colleague has authority to handle the chargeback; the authorization boundary must be judged separately in the connected system.
- Treating proof of delivery as equivalent to the chargeback not standing. Proof of delivery only records the carrier's record; the dispute conclusion must be judged separately under card network rules, and the draft sentence in the sample exceeds what the materials support.
- Treating a success return from identity verification as completed business approval. success only indicates that verification passed; charging, closing a dispute, and writing to a settlement system each require separate downstream implementation.
How to verify the setup
- Input the proposed embedded link from the sample with authToken=settle2261, compare whether the token in the verification interface body equals that value, and observe whether the returned success is true and whether the uid is compliant. The expected result is that verification passes; this is not a claim that it was actually tested.
- Input the sample draft sentence "This order was signed for, the chargeback does not stand, and the dispute can be closed directly," compare its conclusion with the records in the chargeback notice, proof of delivery, and customer service email, and observe whether proof of delivery is sufficient to support "the chargeback does not stand." The expected result is that the conclusion is not supported by the materials and remains pending verification.
- Input the handover request "Please have the external settlement colleague view and confirm the handling opinion through this share link," compare the link's accessible state with whether the colleague has obtained handling authorization, and observe whether an independent authorization record exists. The expected result is that access and authorization are two separate matters; when the authorization record is missing, record the evidence gap.