Required vs. Needed Fields

Signifyd's API is designed to provide robust fraud protection by leveraging critical data fields to evaluate and mitigate risk effectively. However, to accommodate the wide variety of merchant payment methods and order types, many fields are classified as needed rather than strictly required, offering flexibility while still being critical for optimal fraud detection and liability coverage.

• If a parameter is marked as required, it means the API call will fail with a 400 status code if the parameter is not included in the request.
• If a parameter is marked as needed, the API call will not fail; however, the omission of needed fields may delay or inhibit your ability to go live with Signifyd's fraud protection services, or result in the reduction of approval rates as a risk mitigation measure.

While our API does not enforce the inclusion of neededfields to accommodate scenarios where specific payment methods or transaction types make certain fields irrelevant, omitting these fields may significantly impact fraud detection and liability coverage. From a business and risk mitigation perspective, we strongly recommend including all antifraud-critical fields (e.g., card payment details, authorization responses) whenever applicable.

Before going live with our service, Signifyd's Risk Intelligence teams will validate that all needed fields are included accurately and sufficiently for Signifyd to provide robust, reliable antifraud service. Throughout the duration of your service, you are responsible for ensuring that needed fields are consistently sent to Signifyd.

A note on required fields in nested request objects:

A field is marked as required when it must be present if its parent object is included in the request. This also applies to fields marked as required in the top-level request, which must always be present. However, if the parent object itself is not indicated as required, the required designation applies only when the object is provided.

For example, in the Record Return endpoint, the refund object is optional. If it is included, the refund.amount and refund.method fields must be provided, which is why they are marked as required. Similarly, in the Sale endpoint, the memberships array is optional, but if included, each object in the array must contain a membershipName field.