--- title: Legacy Retail API Overview slug: legacy-fraud-apis/legacy-retail-api-overview createdAt: 2026-03-10T14:33:44.820Z --- ::::ExpandableHeading ### **Topic type: Concept** :::hint{type="warning"} **Purpose**: Legacy Retail API overview, differences, and hashing requirements. **Audience**: API integrators and client developers. **Applies to**: Legacy Retail clients implementing via API. **Does not apply to**: Universal APIs, any other industry, or retail clients who opt for a non-API integration. ::: :::: :::hint{type="info"} ******Legacy API Notice**: This API is part of the Legacy Fraud API framework and is maintained for compatibility with existing implementations. New integrations should use the **Universal Fraud APIs** instead. The Universal Fraud APIs provide: - A shared core transaction model - Consistent request and response contracts - Industry-specific extensions - Unified documentation and onboarding - Ongoing feature investment Use this Legacy API documentation only if: - You are maintaining an existing Legacy Fraud API integration. - You have not yet completed migration to Universal Fraud APIs. - Accertify has specifically directed your implementation to remain on the Legacy API framework. For new implementations, start with **Universal Fraud APIs Overview**. ::: The Retail Fraud API is designed for transactions involving **consumer goods and fulfillment‑oriented purchases**, built on the shared core model (transaction, account, payment, items, addresses, device signals, and so forth). ## What Makes Retail Different Retail implementations typically emphasize: - **Line items** (what was purchased, quantity, price, discounts) - **Fulfillment and delivery context** (shipping vs pickup patterns, address usage) - **Payment method mix** (single tender vs split tenders, wallet vs card, etc.) Retail clients can vary significantly (product types, checkout flows, fulfillment models). This is why the field requirement model is important: if your implementation can supply an Imperative field, you should send it consistently. ## Hashing Requirements The Retail API follows the platform hashing rules. Fields designated as hash-required must be hashed before submission, including: - `giftCardNumber` - `hashedPassword` See: **[Hashing Requirements](docId\:yuGHwVL8eOn7vCgSwPcd3)** (Constraint) and **[Accertify Hash Algorithm](docId\:rKIK1Lb6EUUWsz3sxPCe-)** (Reference). ## Field Reference ::::LinkArray{contentSource="CUSTOM"} :::LinkArrayItem{headerType="IMAGE" headerImage="https://api.archbee.com/api/optimize/C_ua77kdJRrVi_Gd-0NCF/x5sNUJxJcklsn3yspXizk-20260326-190742.png"} [US Retail Fields](docId:1KMQmrorNam8nWRpfV1Ge) ::: ::::