triPOS/PIN-Pad Behaviors After triPOS Direct (and subsequent RBA version) Update

Discussion created by frank on Nov 27, 2018

Starting this post after some observations in the field where our clients updated triPOS from v5.4.0 to v5.14.2, which also included the update of their Ingenico (iSC250's in this case) RBA version from v17.x to v21.x.  Notably, the following:

  • After the triPOS service application update, the RBA version updates are "pushed out" to the devices - this is understood. However....
    • One of the things that appears to be happening, is that only a small "batch" of devices get their updates pushed out after the service is started.  IOW, they're not all updated after the service restart - only a few at a time.  It seems that the service needs to be restarted in order to get the next "batch" to update.  If there are a lot of devices, this gets tedious.
    • Another thing is that I've found the PIN pads themselves need to be bounced after they've completed the update process, and doing-so while triPOS is stopped.  This seemed to be the only way to get the devices back to a "ready" state with triPOS (otherwise, the triPOS logo would only show - not the user-defined welcome message, and wouldn't respond to requests).  Once the Ingenico devices have all been restarted, and triPOS started, then everything appears to work OK.
  • The Ingenico iSC250 PIN pads, after the update, have been exhibiting some "flaky" behavior since the update, most-notably with the Signature form (for any type of signature capture - i.e.: /api/v1/sale, /api/v1/signature, etc.).  We have found that running the calibration procedure on the Ingenico (through the Telium Manager) remedied this behavior (so far).  Some examples:


Please feel free to join in - add your own thoughts, troubleshooting tips, field-reported issues, etc.