Micr Class (POS for .NET v1.12 SDK Documentation)


Defines the programmatic interface for a UPOS magnetic ink character recognition (MICR) device.

Namespace: Microsoft.PointOfService
Assembly: Microsoft.PointOfService (in microsoft.pointofservice.dll)

public abstract class Micr : PosCommon
public abstract class Micr extends PosCommon
public abstract class Micr extends PosCommon

This object defines the programmatic interface for a UPOS magnetic ink character recognition (MICR) device.


The MICR service object has the following minimal set of capabilities:

  • Reads magnetic ink characters from a check.

  • Has programmatic control of check insertion, reading, and removal. For some MICR devices, this requires no processing in the service object because the device may automate many of these functions.

  • Parses the MICR data into the output properties provided by this service object. This release of POS for .NET specifies parsing of fields indicated in the ANSI MICR standard used in the United States of America, Canada, Australia, United Kingdom, Japan, India, Mexico, Colombia, and Turkey. For other countries/regions, the application may have to parse the MICR data from the data in RawData.

The MICR may have the following additional capability:

  • The MICR device may be physically attached to or incorporated into a check validation print device. If this is the case, after a check is inserted through MICR service object methods, the check can still be used by the printer service object before check removal.

  • Some MICR devices support exception tables. This cause nonstandard parsing of the serial number for specific check routing numbers. Exception tables are not directly supported by this POS for .NET release. However, a service object can support them, and can assign registry entries under its device name key to define the exception entries.

This release of POS for .NET does not define any parsing of partial MICR check data if an error occurs while reading a check, because any service object that implements such functionality cannot guarantee that fields parsed from partial data is correct. For example, it is possible to get MICR data that contains no '?' characters, but fails its checksum. This indicates that one or more characters in the data is incorrect, but you cannot determine which characters they are. If an application wants to parse the partial data, the RawData property is filled in with whatever was successfully read, even in error cases.


The MICR service object follows the general Device Input Model for event-driven input. One point of difference is that the MICR service object requires the execution of methods to insert and remove the check for processing. Therefore, this service object requires more than setting the DataEventEnabled property to true to receive data. The basic model is as follows:

  • The MICR service object is opened, claimed, and enabled.

  • When an application wants to perform a MICR read, the application calls the BeginInsertion method, specifying a time-out value. This results in the device being made ready to have a check inserted. The method returns either a success status if the check is inserted before the time-out limit was expired, or a time-out status.

  • If there is a time-out, the MICR device remains in a state that allows a check to be inserted while the application provides any additional prompting required, and then reissues the BeginInsertion method.

  • After a check is inserted, the method returns successfully and the application calls the EndInsertion method. This results in the MICR device being taken out of check Insertion mode and the check, if present, actually being read.

    • If the check is successfully read by the MICR service object, it queues a DataEvent event.

    • If the AutoDisable property is true, then the MICR service object automatically disables itself when a DataEvent event is queued.

    • A queued DataEvent can be delivered to the application when the DataEventEnabled property is true. Just before delivering this event, the service object copies the data into properties, and disables additional data events by setting the DataEventEnabled property to false. This causes later input data to be queued by the service object while the application processes the current input and associated properties. When the application finishes the current input and is ready for more data, it re-enables events by setting DataEventEnabled to true.

    • ErrorEvent events are queued if the service object encounters an error while reading the check, and are delivered to the application when the DataEventEnabled property is true.

    • The DataCount property can be read to obtain the number of DataEvent events queued by the service object.

    • All input queued by the service object can be deleted with the ClearInput method.

  • After it processes a DataEvent event, the application should query the CapValidationDevice property to determine whether validation printing can be performed on the check before check removal. If the CapValidationDevice property is true, the application can call the Printer service object's BeginInsertion and EndInsertion methods. This positions the check for validation printing. You can then use the Printer service object validation printing methods to perform validation printing. When validation printing is complete, the application should call the Printer service object's removal methods to remove the check.

  • After the check is no longer needed in the device, the application must call the BeginRemoval method, also specifying a time-out value. This method returns either a Success status if the check is removed, or a Time-out status if the check is not removed. If a Timeout is returned, the application can perform any additional prompting before it calls the method again. After the check is removed, the application should call the EndRemoval method to take the MICR device out of Removal mode.

Many models of MICR devices do not require any check-handling processing from the application. Such devices may always be able to receive a check and require no commands to actually read and eject the check. For these types of MICR devices, the BeginInsertion, EndInsertion, BeginRemoval and EndRemoval methods return a Success status, and the service object queues the data until the DataEventEnabled property is set to true. However, applications should still use these methods to guarantee application portability across different MICR devices.

Device Sharing

The MICR is an exclusive-use device, as follows:

  • The application must claim the device before the application enables it.

  • The application must claim and enable the device before the device begins reading input, or before the application calls methods that manipulate the device.

MICR Character Substitution

The E13B MICR format that is used by the ANSI MICR standard contains fifteen possible characters: the numbers 0 through 9, the space character, and four characters unique to MICR data known as the Transit, Amount, On-Us, and Dash characters. These special characters are used to mark the boundaries of certain fields in MICR data.

Because these characters are not in the ASCII character set, the following lowercase characters are used to represent them in properties and parameters to methods.

Property name (POS Dot Net MICR names )


Standard settings



> 6

The section between the transit number field and the On-Us symbol.




Bounded by two Amount symbols, that is 'a.'




Characters 4 to 8 of the transit field.


If Auxiliary On-Us field is not present, the type is Personal Check.  If the On-Us field is present, it is a Business check.  When no information is available, it is an Unknown check type.





When Transit Number is present, the number immediately before the Transit number.  Spaces are ignored.




If On-Us field present, the data from On-Us field.  If not, the data in On-Us field excluding the Account Number data.



All characters that are read between the Transit symbols.




All data that is read in from MICR.


Any public static (Shared in Visual Basic) members of this type are thread-safe. Any instance members are not guaranteed to be thread-safe.