Universal Fraud APIs
10 min
\<font color="#78b5c7">\</font> topic type concept purpose introduce the universal 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 apis used to evaluate retail, airline, travel, ticketing, amusement, and igaming transactions does not apply to , risk & intelligence apis, dispute apis, or regulatory‑only workflows such as data privacy the universal 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 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 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 shared transaction model + industry specific extension = universal fraud api request 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 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 \<font color="#4f6228"> example \</font> 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 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 how 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 your system gathers the shared and industry specific information applicable to the transaction your system submits the transaction to the appropriate universal fraud api endpoint accertify validates and evaluates the submitted data the api returns the result of the request and the response information available for that workflow 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 transaction lifecycle universal fraud apis support multiple transaction lifecycle workflows 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 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 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 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 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 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 request and response data 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 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 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 what the universal apis do not do the universal 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