---
title: Populating Universal Fraud API Requests
slug: public-apis/populating-universal-fraud-api-requests
createdAt: 2026-08-25T20:35:17.680Z
---

::::ExpandableHeading
###

**Topic type: Constraint**

:::hint{type="warning"}
**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.

::::ExpandableHeading
## Use Only Applicable Fields

A production request should contain only the fields relevant to the transaction being submitted.

:::hint{type="success"}
****<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.
:::
::::

***

:::ExpandableHeading
## 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.
:::

***

:::ExpandableHeading
## 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.
:::

***

:::::ExpandableHeading
## Payment Methods

The `paymentMethods[]` array supports multiple payment instrument types.

A single transaction typically contains only the payment method types involved in that transaction.

::::hint{type="success"}
****<font color="#4f6228">**Example**</font>:

:::BlockQuote
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.
:::::

***

:::ExpandableHeading
## 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
:::

***

:::ExpandableHeading
## 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.


:::