What the documents look like
Cross-border standalone-site payment risk control centres on card network disputes and receiving accounts. The materials handled include payment chargeback notices, fraudulent order lists, invoices, and proof of delivery. The parties, objects, statuses, and validity scopes of these materials are often spread across different sources: the Stripe or PayPal back office, Shopify orders, carrier delivery records, and customer service email. Comparing contract and transaction materials requires placing the contract-side information and the transaction-side information for the same transaction onto the same field for checking, for example order number, amount, date, and recipient. Material updates occur daily and per order, so a comparison may involve versions that are not synchronised.
A chargeback notice and an invoice can share an amount while differing on the cardholder name and the delivery recipient. A delivery record can carry a signing date that sits between the invoice date and the chargeback date. These are the field-level differences that a comparison step has to surface, and they are the reason the tool description and parameter description matter more than the volume of tools attached.
Constraints at the tool calls step
The tool calls node depends on the tool description and the parameter descriptions; the model decides from context semantics whether to call the tool. System module parameters are fixed, while plugin parameters are configurable. When a required parameter has no suitable value in context, the model may not call the tool, and a prompt can guide the user to supply it. In advanced orchestration, available tools are connected to the tool calls module, and the documented advice is to start with a small number of tools and tune before expanding.
The tool calls termination node ends the current call: no further tools are called, and the AI is not called again to summarise the tool results. Custom variables extend tool input for nodes not treated as tool parameters. A retrieval result or a form-collected value is not business authorisation or a database write; downstream execution needs its own implementation.
Hypothetical exercise sample. Source text one: "Order number SO-2024-0871, invoice amount USD 1,250.00, invoice date 3 June 2024, buyer Company A." Source text two: "Payment chargeback notice: transaction number TX-99120, amount USD 1,250.00, chargeback date 18 June 2024, cardholder name does not match the delivery recipient." Source text three: "Proof of delivery: waybill number SF-778812, signing date 10 June 2024, signed by B." Draft sentence to be assessed: "The contract amount and the chargeback amount for this transaction match, the signing date precedes the chargeback date, and the transaction can be confirmed as genuine." This draft sentence needs checking on whether the contract amount and the chargeback amount are the same field with the same value, whether the difference between the signing party and the cardholder name is explained anywhere in the materials, and whether "can be confirmed as genuine" exceeds the scope the materials authorise. The three source texts are hypothetical and were not tested.
Configuration and implementation checks
| Configuration item | Relevant setting or check for this page | Link to the sample |
|---|---|---|
| Tool description | State the purpose, the input conditions, and the situations in which the tool should not be called | Used to judge whether the comparison tool should process the chargeback material |
| Tool parameters | Plugin parameters are configurable; system module parameters are fixed | Check whether amount, order number, and date fields are passed in |
| Required parameters | With no suitable required parameter, the model may not call the tool | When the cardholder name is absent from the sample, guide the user to supply it |
| Tool connection | In advanced orchestration, connect available tools to the tool calls module | The comparison tool and the termination node need correct connection |
| Tool calls termination | Ends the current call; the AI is not called again to summarise | After comparison, prevent further tool calls |
| Custom variables | Extend tool input with a matching parameter description | Can pass contract-side and transaction-side material fields |
Three common errors
- Writing the tool description as a general statement without input conditions or the situations in which the tool should not be called. Check: input source text one and source text two, compare whether the tool description contains field conditions such as amount, order number, and date, and observe whether the model still calls the comparison tool when the cardholder name is absent.
- Treating the parameter description as a guarantee of execution. Check: input the draft sentence, compare whether the parameter description states that the amount must match, and observe whether the comparison output reports "match" merely because the parameter exists while no same-field same-value check was performed.
- Treating tool calls termination as automatic business approval. Check: input the draft sentence and the termination node configuration, compare whether any downstream approval or database write still occurs after termination, and observe whether termination is mistaken for completed authorisation.
How to verify the setup
- Input source text one, source text two, and the draft sentence. Compare whether the contract amount and the chargeback amount are the same field with the same value. Observe whether the comparison tool output states that the amounts match while the cardholder name difference remains unexplained. The condition is met when the output explicitly lists the unsupported item.
- Input source text three and the draft sentence. Compare the order of the signing date and the chargeback date. Observe whether the tool output states that the signing date precedes the chargeback date. The condition is met when the output states only the date order and does not output a "transaction is genuine" conclusion.
- Input the draft sentence and the tool calls termination configuration. Compare whether the AI summary or downstream approval is called after termination. Observe whether the termination node ends the current call. The condition is met when there is no AI summary output after termination and no automatic approval action.