Topic type: Constraint
Purpose: Explain how to populate Universal Fraud API request payloads and distinguish complete documentation examples from real-world transaction payloads.
Audience: API integrators and client developers.
Applies to: Universal Fraud APIs.
Does not apply to: Legacy Fraud APIs or non-API integrations.
The Universal Fraud APIs support a wide range of industries, payment methods, fulfillment models, and transaction scenarios.
Documentation examples may include multiple optional structures and payment methods to demonstrate the complete request hierarchy. These examples are intended to show field placement and object relationships, not realistic business transactions.
A production request should contain only the fields relevant to the transaction being submitted.
Example:
Do not populate fields simply because they appear in a documentation example.
Only submit data that your implementation legitimately collects or stores.
Do not:
Artificial data can reduce data quality and negatively affect fraud evaluation.
Universal Fraud API fields are classified as:
When populating requests:
The paymentMethods[] array supports multiple payment instrument types.
A single transaction typically contains only the payment method types involved in that transaction.
Example:
A documentation example may demonstrate all supported payment method types, but production requests should include only the methods used for the transaction.
When an object contains an addressID field, the value should reference a valid address object included in the request.
Use identifiers consistently across:
Complete Request Example topics are designed to illustrate:
They are not intended to represent realistic transactions.
Use complete request examples as structural references rather than implementation templates.