These standards are available publicly free of charge. See each item below to request or download the necessary documents. For our full list of Standards, see the options on the side to read each abstract. In order to access all standards, learn more about Conexxus Membership.
NOTE: Only the latest version of each standard is listed. If you would like an earlier version, please contact [email protected]
Conexxus Age Verification API Specification
The Conexxus Age Verification APIs may be implemented by POS vendors to communicate with a supported Age Verification System such as the NACS TruAgeTM solution. To get more information about onboarding to TruAgeTM please email [email protected].
The Age Verification API system supports a far-reaching system for verifying consumer age for age restricted product sales and supporting system-wide limitations on certain restricted product sales. With over 37% of industry inside transactions involving an age restricted product, consistent age verification is key to maintaining a retailer’s ability to “responsibly sell legal products”. The Age Verification API provides such consistency.
The industry is constantly under scrutiny by regulators on this topic – in many cases resulting in loss of product segments available for sale (e.g., flavored tobacco and vape products). Our industry must adopt modern techniques for verification.
The goal of the Age Verification API is to provide support for retailers’ ability to continue sales of scrutinized products with provable due diligence.
The Age Verification API, through consistent implementation, helps assure that suppliers support retailers in the goal of provable due diligence.
This specification is targeted deliberately at Point of Sale Systems implementers and integrators. While some information not specifically germane to POS Systems is introduced in the specification (e.g., consumer boarding in the user stories), this information is present to aid in understanding the overall program.
There are two main APIs in the system, each with its own schemas – the Tokenization Authority System API, and the Merchant Restricted Goods Auditing System API.
Conexxus Payment System Product Codes
From pay-at-the pump, to paperless transactions with vendors, to tracking consumer sales patterns through point-of-sale data, to not yet realized uses, technology promises greater business efficiencies for the convenience store and petroleum marketing industries.
Standards greatly facilitate the interoperability of technology applications. The Conexxus Retail Financial Transactions Committee, originally part of the NACS Technology Standards Project and then the Petroleum Convenience Alliance for Technology Standards, generated this set of recommended product codes. Subsequently, these Payment Product Codes were adopted as part of the X9 standard for terminal-to-host messaging (first TG-23 and later X9.104 Part 2). They have has been maintained sequentially by NACS, PCATS, and now Conexxus; Conexxus is the official Registration Authority, approved by ASC X9, Inc., to maintain these codes as part of X9.104.
These product code definitions are for use in electronic payment systems formats. Industry specific category/subcategory definitions and descriptions proposed by the NACS Category Management Project are incorporated in the listings. These codes define petroleum and merchandise products and services by assigning them a specific three-digit number. Host payment systems, along with vendors, are encouraged to adapt their systems to utilize these codes so that standard product definitions are maximized for the benefit of all users.
Conexxus maintains this set of product codes and updates them as necessary. In order to facilitate this maintenance and still provide maximum flexibility for individual vendors and networks to use these codes, two sets of undefined code categories exist. The first is for the exclusive use of Conexxus in making future changes. The second is for the proprietary use of the vendor community to add codes outside the adopted list. Notwithstanding such private use opportunities, Conexxus encourages vendors to submit new generic product codes so that the list may reflect the most up-to-date codes in use throughout the industry and continue to achieve the goal of standard product definitions.
What’s the difference between product codes and category codes?
The NACS Category Definitions are six position numeric fields that provide a framework for retailers and manufacturers to have meaningful discussions regarding market performance comparisons and establish performance benchmarks. Maintained by NACS, these are available to download free of charge from the NACS website (www.convenience.org).
The Conexxus Payment System Product Codes are three-digit codes used in payment transactions sent to a host payment system. The codes convey the products sold in the transaction in a standard way.
Conexxus EMV Fleet Tag Specification
Request: EMV Fleet Tag Specification: V1.3
The EMV Fleet Tag Specification is available to qualified industry participants upon request. Please email [email protected] to request your copy.
Magnetic stripe fleet card processing has historically used track data to convey required product restrictions and prompts to the POS. The POS then used the product restriction information to ensure only applicable products were purchased and prompt responses were transmitted from the POS to the acquirer/host in fields as defined by the acquirer. Encryption, tokenization, and masking of account numbers and track data made product restriction and prompt data impossible to interpret, creating artificial barriers to securely process fleet.
Ultimately, processing of fleet EMV chip cards face similar barriers. The EMV Fleet Processing Specification defines Tag DF 32 for Purchase Restrictions and extends previous work, completed by IFSF, to enhance, Tag DF30, for Fuel Card Usage Bitmap for Prompting. A key direction for this Specification is to develop a tag-based solution to ease the development for merchants and POS vendors and not to focus on the use of Tag 57 – Track 2 Equivalent Data. This Specification does not eliminate the use of the Track 2 Equivalent approach, but instead provides an alternative path for handling fleet data and provide for future growth of data collected using this approach.
A standard way to read fleet prompt requirements and transmit the data in an EMV transaction will limit the number of interfaces required for various fleet cards. This can significantly reduce the work required by vendors and acquirers/hosts, thereby eliminating complexities and potentially reducing overall cost of implementation.
To access all of the Conexxus Standards, join as a Gold Level Member today!