23/24 Patron Status

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|
  1. The BL field (SIP2, optional) is valid patron, so the N value means bad_barcode doesn’t match a patron, the Y value means 999999 does.
  2. The CQ field (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.