Ultimate Conexxus FDC Standard Guide for Forecourt Controllers

One fuel dispenser brand change at a 24-pump travel plaza can trigger a six-month custom integration project. Not because the hardware is incompatible, but because proprietary communication protocols force every device pairing into a bespoke engineering effort.

The petroleum retail industry has had open communication standards for over two decades. Yet many operators still run entirely proprietary forecourt stacks without realizing there's an alternative. Think of open forecourt standards like USB for fuel dispensers: a universal interface that lets any compliant device plug into any compliant controller.

This article explains the Conexxus FDC standard, the IFSF forecourt protocol, and the emerging OpenRetailing API initiative, all in plain language with practical implications for controller procurement and long-term site strategy.

What Is the Conexxus FDC Standard?

The Conexxus FDC standard is an XML-based messaging specification that defines how forecourt controllers communicate with fuel dispensers, tank gauges, price signs, and car wash systems at petroleum retail sites.

FDC stands for Forecourt Device Controller. According to the specification, an FDC is a software application that interfaces to forecourt devices at a retail petroleum location. The standard was developed jointly by Conexxus (serving North America) and the International Forecourt Standards Forum, or IFSF (serving international markets). For operators unfamiliar with the physical hardware, this overview of forecourt controllers covers the fundamentals.

The current release is FDC V2.1.2, an XML specification. An accompanying FDC API V1.0 is under development through the OpenRetailing initiative, bringing the standard into a modern RESTful architecture.

The specification replaces proprietary protocols between the POS and forecourt devices, allowing any POS system to use standardized messaging to interface with any compliant controller. It defines five categories of messages:

1. Device states inform the controller about the current condition of each connected device.
2. Configuration messages allow the controller to read and set device parameters like fueling limits, service modes, and pricing.
3. Control commands let the controller reserve or authorize a dispenser, obtain a car wash code, or activate a price sign.
4. Data reporting provides transaction data and operational readings such as tank levels back to the controller.
5. Alarms and unsolicited messages notify the controller of state changes, error conditions, and maintenance alerts.

In practical terms: when a customer lifts a nozzle, the dispenser sends a state change message. When the POS authorizes the pump, the controller sends a control command. When fueling completes, the dispenser sends transaction data back through the controller. Every step follows a defined XML schema rather than a vendor-specific protocol.

How Does the IFSF Forecourt Standard Compare to Conexxus FDC?

IFSF is the international forecourt standard, while Conexxus FDC serves North America. Both organizations now collaborate through the joint OpenRetailing API initiative to converge their specifications into a single global framework.

The IFSF protocol uses a two-layer architecture. Think of it as separating the language spoken (the application layer) from the telephone line carrying the conversation (the communications layer). The application protocol defines what messages mean. The communications protocol handles how they travel between devices. This separation means the same device commands work regardless of whether the physical transport is LonWorks or TCP/IP.

Transport: LonWorks vs. TCP/IP

LonWorks (LON) was the original IFSF transport layer. Its advantage was practical: existing forecourt cabling could be reused without rewiring. For sites already built, this made IFSF adoption straightforward. TCP/IP is the modern alternative. It requires higher-spec Ethernet cabling but connects forecourt devices to standard IT infrastructure, which is cheaper and more familiar to network administrators. New construction almost universally uses TCP/IP.

The Dispenser State Machine

One of IFSF's most practical contributions is a defined state machine for dispensers. Every IFSF-compliant dispenser reports its condition using a standardized set of states:

1. Inoperative: the dispenser is offline or faulted.
2. Closed: the dispenser is shut down by the controller.
3. Idle: the dispenser is ready and waiting for a customer.
4. Calling: a customer has lifted the nozzle but the controller has not yet authorized the pump.
5. Authorised: the controller grants permission to fuel.
6. Started: fueling begins.
7. Fuelling: fuel is actively flowing.

Additional states (Suspended Started, Suspended Fuelling) handle interruptions. This state machine gives every device in the forecourt a common operational vocabulary, so a controller does not need custom logic for each dispenser brand. For context on how controllers manage related protocols like BIR and DIM, see ATG forecourt controller integration.

What Is the OpenRetailing API Initiative?

OpenRetailing is a joint Conexxus and IFSF initiative creating RESTful API standards and a shared data dictionary to replace legacy XML-based forecourt protocols with a modern, globally applicable specification.

Announced in February 2020, the initiative established a public repository at openretailing.org with sample APIs, design documents, and data dictionary materials. This is significant because legacy FDC and IFSF specifications are largely gated behind membership access. The public repository lowers the barrier for vendors, integrators, and IT teams evaluating the standards.

The foundation of the initiative is the Joint API Data Dictionary, published in June 2024. It defines consistent data terminology across all IT systems in the convenience retail and petroleum ecosystem. As the IFSF working group described it, the dictionary "provides the foundation for all global API standards" and ensures that a "dispenser," a "nozzle," and a "transaction" mean exactly the same thing in every system that implements the standard.

Technical Architecture

The APIs use REST architecture built on the OpenAPI Specification v3.0. Security is handled through OAuth2, with Server-Sent Events (SSE) for real-time event streaming and WebSocket support for bidirectional communication. For developers familiar with modern web services, this is the same architecture used by virtually every major cloud platform, which means existing tooling and expertise apply directly.

The initiative also provides simulators for testing: dispenser, carwash, mobile and remote fueling approval, digital offers, POS Activity Report API (PARA), site asset data, and FDC systems. Vendors can test implementations without physical hardware, dramatically reducing the development cycle.

Gray Taylor, Conexxus Executive Director, stated the goal plainly: "By rapidly migrating our Standards focus to APIs, we intend to save the industry millions in development costs, and years in development time."

Why Do Open Forecourt Standards Matter for Your Business?

Open forecourt standards eliminate proprietary lock-in, reduce integration costs, enable multi-vendor forecourts, and protect equipment investments over a 10 to 15 year lifecycle.

The cost of proprietary protocols is rarely visible on a purchase order. It shows up later. Every custom dispenser-to-controller integration is a separate engineering project, typically requiring months of development and certification testing. A travel plaza running three dispenser brands under proprietary protocols faces three separate integration maintenance streams, each with its own development timeline and vendor dependency.

Open standards change the equation in four ways:

• Switching cost reduction. Operators can change dispenser brands, POS systems, or peripheral devices without rewriting controller firmware. The USB analogy applies: a new printer does not require a new computer.
• Multi-vendor flexibility. Large travel plazas and truck stops often run dispensers from multiple manufacturers. A standards-compliant controller manages them all through a single interface. Allied Electronics controllers, installed at virtually every North American truck stop and travel plaza, support all major dispenser brands with a single firmware version.
• Future-proofing. The OpenRetailing API initiative means today's FDC-compliant controllers have a clear migration path to RESTful APIs. Investing in standards compliance now avoids a technology dead end in five years.
• Scale validation. With 52,000+ interface devices deployed worldwide, open standards are not theoretical. They operate at industrial scale across the harshest fueling environments in North America. For a deeper comparison of controller features, see how to choose a forecourt controller.

Key Questions for Evaluating a Standards-Compliant Controller

Evaluating a standards-compliant controller requires asking about FDC version support, certified dispenser brands, transport options, POS openness, and firmware architecture.

Before any procurement meeting, bring these questions. The answers separate genuinely open controllers from those that claim standards compliance while still locking operators into proprietary ecosystems.

Allied Electronics answers all five of these questions affirmatively. The NeXGen PRIME and AEGIS controllers support all major dispenser brands with a single firmware version, offer both serial and Ethernet connectivity, and maintain an open POS integration program where any vendor can request the specification document.

The Future of Forecourt Communication Standards

The future involves RESTful API convergence through OpenRetailing, integration of EV charging protocols like OCPP and ISO 15118, and the eventual replacement of regional specifications with a single global standard.

The move from XML to REST mirrors a pattern already completed in nearly every other technology sector. Banking, logistics, healthcare, and retail all transitioned from XML-based messaging to RESTful APIs over the past decade. The petroleum industry is following the same trajectory, just on a longer timeline because of the 10 to 15 year equipment lifecycle at most sites.

Hybrid forecourts add urgency. As operators install EV charging stations alongside fuel dispensers, controllers need to manage both fuel and electric protocols. EV charging relies on standards like OCPP (Open Charge Point Protocol) and ISO 15118 for vehicle-to-grid communication. Controllers built on open forecourt standards are better positioned to integrate these additional protocols without a ground-up redesign.

The joint Conexxus and IFSF working groups signal something larger: the end of the North America versus international standards split. One global standard means one integration effort, regardless of geography. For companies operating across borders, this simplification alone justifies the investment in open-standards controllers today.

Allied Electronics has built forecourt controllers for 48 years, including patenting the industry's first hybrid forecourt solution. Open standards are not a recent addition to Allied's approach; they are foundational to how the company engineers its products.

Frequently Asked Questions About the Conexxus FDC Standard

The Conexxus FDC standard and IFSF forecourt protocols raise practical questions for operators evaluating compliance. Here are the most common.

Conclusion

Open forecourt communication standards are not a theoretical ideal. The Conexxus FDC specification and IFSF protocols have defined the rules for dispenser-to-controller communication for over two decades. The OpenRetailing API initiative is now converging these regional standards into a single global framework built on modern REST architecture.

Three takeaways for operators evaluating forecourt technology:

1. Proprietary protocols are a hidden cost multiplier. Every custom integration is a separate project with its own timeline, budget, and vendor dependency.
2. FDC compliance is a concrete, testable criterion. Ask vendors which version they support and how many dispenser brands run on a single firmware. The answers reveal whether "standards-compliant" is a marketing claim or an engineering reality.
3. The future favors open. REST APIs, EV charging integration, and global standards convergence all reward controllers built on open architectures today.

The simplest next step: ask the current controller vendor which FDC version they support. That one question reveals whether a forecourt is future-ready or locked into yesterday's protocols.