Legacy Retail API Overview
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 RequirementsHashing Requirements (Constraint) and Accertify Hash AlgorithmAccertify Hash Algorithm (Reference).
Field Reference

US Retail Fieldsff