--- title: Universal Fraud APIs slug: public-apis/universal-fraud-apis createdAt: 2026-03-16T20:41:19.181Z --- ::::ExpandableHeading ### **Topic type: Concept** :::hint{type="warning"} **Purpose: **Introduce the Universal Fraud APIs and explain how they use a shared transaction model, industry-specific extensions, and transaction lifecycle workflows to support real-time fraud evaluation. **Audience: **API integrators and client developers implementing transaction-level fraud detection. **Applies to: **Universal Fraud APIs used to evaluate Retail, Airline, Travel, Ticketing, Amusement, and iGaming transactions. **Does not apply to: **Account Protection, Risk & Intelligence APIs, Dispute APIs, or regulatory‑only workflows such as Data Privacy. ::: :::: The Universal Fraud APIs provide a consistent way to submit transaction data to Accertify for fraud evaluation across supported industries. Each request combines shared transaction information with the industry-specific context applicable to the transaction. Accertify evaluates the submitted data and returns a response that your system can use to inform downstream business logic. The Universal Fraud APIs do not process payments, authorize payments, or execute transactions. They provide risk information that supports decisions made by your payment, order management, reservation, or other transaction-processing systems. ::::ExpandableHeading ## Universal API Model The Universal Fraud APIs use a shared architecture rather than separate, unrelated contracts for each industry. Every industry implementation is built from: - A shared transaction model - Shared supporting objects - An industry-specific extension - Shared response structures - Transaction lifecycle update workflows This architecture allows integrations to reuse common structures and processing logic while still supplying the specialized information needed for a particular industry. At a high level: :::BlockQuote Shared Transaction Model + Industry-Specific Extension = Universal Fraud API Request ::: :::: *** :::ExpandableHeading ## Shared Transaction Model The shared transaction model defines information that is common across industries. This information may include: - Transaction identifiers and timestamps - Transaction source - Account and customer information - Payment amounts - Payment methods - Addresses - Items - Promotions - Device information - Browser information - Behavioral information - Purchase context Shared fields use the same names, structures, and purposes wherever they appear in the Universal Fraud APIs. ::: *** ::::ExpandableHeading ## Shared Supporting Objects Universal Fraud APIs reuse supporting objects for common transaction data. Shared supporting objects may include: - `account` - `payment` - `addresses[]` - `shippingAddresses[]` - `billingAddresses[]` - `paymentMethods[]` - `items[]` - `promotions[]` The supporting objects available in a request depend on the industry contract. :::hint{type="success"} ******Example**: The shared `paymentMethods[]` collection supports multiple payment instrument types, while the shared `items[]` collection provides a consistent structure for describing products, reservations, tickets, subscriptions, and other transaction items. ::: :::: *** :::ExpandableHeading ## Industry-Specific Extensions Each Universal Fraud API adds structures that describe the specialized context of its industry. See the industry overview topics for more information. ::: *** :::ExpandableHeading ## How Fraud APIs Are Used The Universal Fraud APIs follow an event-based interaction model. Each scored request represents a transaction event that you want Accertify to evaluate. Your system submits the information available at the applicable stage of the transaction lifecycle. At a high level: 1. Your system gathers the shared and industry-specific information applicable to the transaction. 2. Your system submits the transaction to the appropriate Universal Fraud API endpoint. 3. Accertify validates and evaluates the submitted data. 4. The API returns the result of the request and the response information available for that workflow. 5. Your system uses the response to determine the appropriate downstream action. The action taken by your system depends on your integration, business rules, and Accertify configuration. ::: *** ::::ExpandableHeading ## Transaction Lifecycle Universal Fraud APIs support multiple transaction lifecycle workflows. :::ExpandableHeading ### Pre-Authorization Use a preAuth endpoint before payment authorization. A pre-authorization request allows the transaction to be evaluated before authorization results are available. When Payment Optimization is enabled, the pre-authorization response may also contain Payment Optimization information. ::: :::ExpandableHeading ### Post-Authorization Use a postAuth endpoint after payment authorization. A post-authorization request can include authorization, Address Verification Service, Card Verification Value, 3-D Secure, and Strong Customer Authentication results through the post-authorization payment method structure. ::: :::ExpandableHeading ### Authorization Update Use an Authorization Update endpoint to record authorization information for a transaction that was previously submitted for evaluation. An Authorization Update request identifies the original transaction and may contain authorization and 3-D Secure results for its payment methods. Authorization Update is a non-scored workflow. ::: :::ExpandableHeading ### Fulfillment Update Use a Fulfillment Update endpoint to record a change in the fulfillment status of a previously submitted transaction. A Fulfillment Update request may identify: - The original transaction - The updated transaction status - A cancellation reason - Item-level shipping or fulfillment information Fulfillment Update is a non-scored workflow. ::: :::ExpandableHeading ### Chargeback Update Use a Chargeback Update endpoint to record chargeback information for a previously submitted transaction. A Chargeback Update request may identify: - The original transaction - Chargeback status - Chargeback resolution - Chargeback amount - Chargeback currency - Chargeback reason code group Chargeback Update is a non-scored workflow. ::: :::: *** :::ExpandableHeading ## Pre-Authorization and Post-Authorization Payment Methods Pre-authorization and post-authorization requests use the same general transaction hierarchy. The primary request difference is the payment method model: - Pre-authorization requests use the pre-authorization payment method structure. - Post-authorization requests use the post-authorization payment method structure. The post-authorization structure extends the pre-authorization structure with authorization and authentication-result fields, which may include: - Address Verification Service result - Card Verification Value result - Card authorization code - Card authorization date and time - Pre-authorization rejection indicator - Post-authorization rejection reason - Electronic Commerce Indicator - Strong Customer Authentication soft-decline indicator - 3-D Secure flow - 3-D Secure version - 3-D Secure challenge request type - 3-D Secure transaction status - Strong Customer Authentication authorization status - Strong Customer Authentication authorization error Do not include post-authorization-only fields in a pre-authorization request. ::: *** ::::ExpandableHeading ## Request and Response Data :::ExpandableHeading ### Requests Submit only information that applies to the transaction being evaluated. A Universal Fraud API contract may support many optional structures, payment types, item types, and industry branches. A production request does not need to include every structure supported by the contract. ::: :::ExpandableHeading ### Responses Scored pre-authorization and post-authorization endpoints return response information for the submitted transaction. Depending on the endpoint and configuration, a scored response may include: - Request status - Event identifier - Error, warning, or informational messages - Device details - Connection details - Payment Optimization information for pre-authorization workflows Non-scored update endpoints return the status of the update request rather than performing another fraud evaluation. ::: :::: *** :::ExpandableHeading ## Errors and Fraud Evaluation Results An API error is not a fraud decision. Validation, authentication, rate-limit, or processing errors indicate that the request could not be accepted or processed as submitted. Correct the request or integration issue before relying on the result. A successfully processed request indicates that the API accepted the transaction for the workflow represented by the endpoint. ::: *** :::ExpandableHeading ## What the Universal Fraud APIs Do Not Do The Universal Fraud APIs do not: - Process payments - Authorize payment instruments - Capture or settle funds - Execute purchases or reservations - Fulfill orders - Initiate chargebacks - Replace payment gateways - Replace order management, reservation, ticketing, or gaming platforms The APIs provide fraud-related information and lifecycle reporting capabilities that support your existing transaction systems. :::