Smart Card Overview

The WIC EBT Middleware (WEM) provides support for smart card driven EBT host systems to the SPIRIT interface of the Client Endpoint software using an additional module referred to as the SPIRIT WIC EBT Middleware - Smart Card (SWEM-SC) and an EBT Hub called the SPIRIT WIC EBT Middleware - Queue (SWEM-Q). This section attempts to cover a high level overview of how Smart Card systems work in general and more specifically how WEM can communicate with a smart card host using SWEM-SC and SWEM-Q.

Online vs. Offline

This was for many years the magic question in WIC EBT, which system is better. The fact of the matter is that both flavors have their pluses and minuses, but this document assumes some familiarity with the pros and cons of each approach. However it doesn't assume a knowledge of the technical differences, so this subsection is designed to cover this topic.

The Cards

A simple observation tells you that the chip card has a little metallic section and that is (typically) the only glaring difference as a chip card also contains a magstripe on the back side in most cases. This metallic section is the IC connector and it is effectively the "chip" that makes the card "smart". Beyond the visual differences however the more significant technical difference is that the data is written to and read from that chip. Thus, the card itself contains data, rather than a simple account number that points to data in another location.

The magnetic stripe card on the other hand, simply has a card number - and a few other pieces of data - encoded into the magnetic stripe itself. However, this data is not something that gets changed as it does on the chip cards. It simply tells the cash register a card number, which is then used to route the transaction so it eventually ends up at the specific host who issued the account, where the account is validated and approved.

Online EBT systems have all the account and benefit information centralized in a single data store - typically a database - in a facility accessible via financial network connections and/or the internet. Offline systems have all the account and benefit information distributed such that each card is it's own little miniature database.

Transaction and Management flow

Because of the differences in the cards, the transaction and management flows may be different as well. Many operations may be initiated in a similar manner, but in the end the process behind the scenes is often very different.

Account Setup

When an account setup message is sent to an online host, it is created in the central database, and will live in that location only, and is typically permanent data. In an offline system it will be created on the host, but when the card is presented information about the account will also be stored on the card. This information is then used as part of the validation when the card is presented at a different time to be used for benefit management.

Benefit Management

Online benefit records are maintained on the host exclusively. So when a redemption happens at a retailer, the host updates the benefit quantities in realtime. This allows a balance inquiry to always be aware of what benefits remain on the card. This also allows the clinic to pull up benefit information in the user interface for the EBT host and see this information in realtime.

In the case of offline benefit management, the benefits are stored on the host, as well as on the card. The card will always have the real balance, as it will deduct benefits when purchases are made in the store. However, the host will not know about those until after a claim file from that store containing the transaction has been posted.

Retail Transactions

Because the benefits are stored on the card the retailer can trust the card's records and process transactions even when communication to the EBT host is unavailable without risk. Whereas communication outages in an online system typically mean the retailer must deny the transaction or process it as a Store and Forward, which may get rejected if the benefits were not available - which is risky for the retailer.

Lost or stolen cards

A lost or stolen card in an online system is reported via a message or by accessing the EBT Host management interface. Once it is reported the record in the online database is flagged immediately and the card is rejected for future transactions. Whereas with an offline host, because the card is it's own database, this must be handled in a more disconnected manner. In the offline system it is necessary to report the card lost or stolen in the same manner, but then - because there is no centralized database - the EBT Host must add it to a list (The Hot Card List) which is distributed via FTP to the retailers who are authorized to accept the EBT card. When the card is presented at the register, if it's on the list it is rejected.

Workflow for Smart Cards using WEM, SWEM-Q, and SWEM-SC

When utilizing SPIRIT as the WIC MIS the system was designed originally to work with an Online host. In order to build upon that, without dramatically changing the underlying structure SWEM-Q was conceived. The premise is simple: provide a mechanism by which the SPIRIT system can communicate with a host that provides the functionality that SPIRIT lacks for streamlining communication between SPIRIT and the Smart Card host. This is accomplished by presenting an interface mimicking the online interface for a subsystem which stores benefit information and account information locally. So SPIRIT can communicate using the same messages and files that it uses today when talking to an online system. However, WEM will be aware of the offline host and SWEM-Q. As a result it will route all "impactful" transactions to both hosts.

For example, if you create a new account in SPIRIT, WEM will send messages to SWEM-Q and to the Offline host to create a new account. It will also help SWEM-Q manage the data flow by updating SWEM-Q on the status of the messages sent to the host. Benefits, Accounts, and Card Management messages are all handled this way. This in turn allows WEM to utilize SWEM-Q for balance inquiry messages and more without having it's own stores of this information and without the need to process files from the offline host. SWEM-Q performs all of this functionality and returns via WEM the information in the format that SPIRIT already is accustomed to receiving.

By involving SWEM-SC SPIRIT WEM is notified when a card is presented and it routes the information between the card and SWEM-Q much like it routes information between SPIRIT and SWEM-Q. This allows for a centralized approach to smart card loading, meaning that not every workstation needs a card reader sitting next to it.