Populating Universal Fraud API Requests
6 min
\<font color="#b6c7cb">\</font> 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 use only applicable fields a production request should contain only the fields relevant to the transaction being submitted \<font color="#4f6228"> example \</font> a transaction paid entirely by credit card should include only the credit card payment method structure a transaction paid with a digital wallet should include only the digital wallet fields a transaction without promotions should omit promotion data a transaction without fulfillment or shipping information should omit those structures do not populate fields simply because they appear in a documentation example do not generate placeholder data only submit data that your implementation legitimately collects or stores do not invent values generate synthetic identifiers reuse unrelated values populate optional fields with placeholders artificial data can reduce data quality and negatively affect fraud evaluation follow field classifications universal fraud api fields are classified as required conditional optional when populating requests required fields must always be supplied conditional fields must be supplied when their documented conditions are met optional fields should be supplied when legitimate values are available payment methods the paymentmethods\[] array supports multiple payment instrument types a single transaction typically contains only the payment method types involved in that transaction \<font color="#4f6228"> example \</font> credit card digital wallet gift card bank account voucher store credit a documentation example may demonstrate all supported payment method types, but production requests should include only the methods used for the transaction address references when an object contains an addressid field, the value should reference a valid address object included in the request use identifiers consistently across addresses payment methods items industry specific objects complete request examples complete request example topics are designed to illustrate object hierarchy nested structures field placement supported data branches they are not intended to represent realistic transactions use complete request examples as structural references rather than implementation templates