Example:
2300120060101 084235AOUWOLS|AAbad_barcode|ACsip_01|ADbad_password|
24YYYY 00120100507 013934AE|AAbad_barcode|BLN|AOUWOLS|
2300120060101 084235AOCONS|AA999999|ACsip_01|ADbad_password|
24 Y 00120100507 022318AEDoug Fiander|AA999999|BLY|CQN|BHUSD|BV0.00|AFOK|AOCONS|
2300120060101 084235AOCONS|AA999999|ACsip_01|ADuserpassword|LY|CQN|BHUSD|BV0.00|AFOK|AOCONS|
24 Y 00120100507 022803AEDoug Fiander|AA999999|BLY|CQY|BHUSD|BV0.00|AFOK|AOCONS|
SIP2
, optional) is valid patron, so the N value means bad_barcode doesn’t match a patron, the
Y value means 999999 does.
SIP2
, optional) is valid password, so the N value means bad_password doesn’t match 999999’s
password, the Y means userpassword does.
So if you were building the most basic SIP2
authentication client, you would check for |CQY| in the response to
know the user’s barcode and password are correct (|CQY| implies |BLY|, since you cannot check the password
unless the barcode exists). However, in practice, depending on the application, there are other factors to consider in
authentication, like whether the user is blocked from checkout, owes excessive fines, reported their card lost, etc.
These limitations are reflected in the 14-character patron status string immediately following the 24 code. See the
field definitions in your copy of the spec.