TMS Updates

the terminal management system (tms) is the source of truth for a reader's encryption keys and configuration there are two points at which the sdk applies pending tms updates during device setup , as part of ensuredeviceready() docid\ bqqtsyaoewssp dnwvsca this is the primary mechanism and handles everything key injection, ecc certificate signing and configuration updates on transaction start an opt in , lighter weight check that applies pending configuration updates immediately before a transaction updates during device setup the recommended approach is to call ensuredeviceready() docid\ bqqtsyaoewssp dnwvsca when pairing a reader and again on every app launch it checks the tms for pending updates and applies any that are found (keys, ecc certificate and configuration alike), skipping anything already up to date on a healthy device with nothing pending, the only cost is a single statusreport to the tms see device setup & readiness docid\ bqqtsyaoewssp dnwvsca for the full flow, progress states and ecc handling updates on transaction start (opt in) for integrators who want configuration to stay current without relying solely on app launch setup, the sdk can check for and apply pending updates at the start of each transaction this is off by default enable it via toroconfig var config = toro getconfig() config checkforupdatesontransactionstart = true try toro setconfig(config) you can equally set it when first constructing the toroconfig you pass to the sdk let config = toroconfig( // other config checkforupdatesontransactionstart true ) when enabled, starttransaction() checks the tms for pending updates before proceeding and applies any applicable update when disabled (the default), starttransaction() behaves exactly as before and runs no update checks the transaction start path handles configuration update (application parameters) only key injection and ecc signing are not applied here; those are prerequisites that must be resolved during initial device setup via device setup & readiness docid\ uymefwqpssfdqgfpvlaxg transaction states for this flow when checkforupdatesontransactionstart is enabled, two additional transactionstate values may be emitted to your transactionstatelistener immediately after connectingtodevice (i e once the device is connected and its info has been read) and before the usual awaitinggratuity / awaitingcard states state what's happening checkingforupdates checking the gateway for pending device updates before the transaction starts applyingupdates installing a pending configuration update on the device before the transaction starts only emitted when an applicable update was found if no update is pending, only checkingforupdates is emitted (briefly) and the transaction proceeds normally; the only cost is the status check itself reconnection after an update applying a configuration update can reboot the reader as with device setup, the sdk reconnects automatically via connection polling and then continues the transaction without integrator intervention choosing an approach app launch setup transaction start check entry point ensuredeviceready() starttransaction() (with config flag) opt in? no, call it yourself yes, via checkforupdatesontransactionstart handles keys / ecc yes no (configuration only) handles configuration yes yes added latency on app launch / pairing before every transaction the two are complementary at minimum, call ensuredeviceready() regularly enable the transaction start check additionally if you need configuration to converge as quickly as possible between setup runs