Plan an SDK evaluation around your deployment.
Bring the intended customer journey, hardware configuration and target business services. The evaluation should establish what is supported, what needs integration work and what evidence is required before rollout.
Deployment and installation boundary
Azimut SDK runs the hardware integration beside the kiosk application’s device workflow and exposes JSON over HTTP. Agree the machine and operating-system configuration, supplied runtime package, drivers, service account, network routes and authentication with the integration team. Use the compatibility matrix to identify where model-specific evidence is still needed.
Application hosting, business backends and fleet management are separate deployment decisions. Confirm where each component runs, which connections are required and who operates them. Payment, identity and clearing workflows also depend on their connected services. For every disconnected scenario, specify which steps may continue, how pending work is retained and how it is reconciled after connectivity returns.
Security evidence and responsibilities
Define access to the runtime and its APIs, transport protection, allowed application origins, credential storage, operator permissions and logging before the pilot. For document and payment workflows, identify the data captured, destination systems, storage locations, retention and deletion rules, and the parties allowed to access it. Keep personal fields and payment data out of routine diagnostic logs unless the agreed design explicitly requires and protects them.
Request security evidence for the exact component and release being evaluated: assessment scope, date, test method, unresolved findings and responsible owner. Confirm what can be shared under the project’s confidentiality terms. Confirm the applicable assessment cadence and compliance requirements for the complete deployment, including the scope covered by any device or component certification.
The application owner remains responsible for business decisions and integration policy; hardware suppliers and payment or identity providers retain their respective responsibilities. Agree those boundaries with the SDK integration team. Satellite’s documented release and fleet-security controls are described on its own product page; confirm the required products and controls in your proposal.
Licensing, inclusions and support
Request a written proposal specifying the licensing basis, runtime and driver inclusions, permitted environments, deployment count, integration work, upgrades and support. Include evaluation access and any Satellite licence in that scope. Confirm these terms for the proposed configuration before committing to hardware or rollout dates.
Provide the device models and quantities, sites, operating systems, required operations, backend interfaces, expected transaction volume, languages and support hours. Assign ownership for the application, SDK runtime, device drivers, physical servicing, business APIs and fleet operations. Confirm supported versions, end-of-support notice, response expectations and the escalation route in the agreement.
Move from a controlled pilot to rollout
- Agree the configuration. Record runtime, OS, device model, firmware and driver versions, required fields and target service contracts. Request the release-specific reference and evaluation tooling.
- Verify the first connection. Install the approved package and start with the read-only status example. Confirm authentication and error handling before enabling device actions.
- Test the intended workflow. Use controlled samples and test funds where relevant. Check success, cancellation, device disconnect, power loss, service timeout and duplicate-request handling. Retain original references and final outcomes.
- Approve acceptance evidence. Review measured performance, unresolved exceptions, reconciliation, security scope and operator recovery. Agree localisation, accessibility and customer-session handling for the actual application.
- Stage the release. Start with representative devices, verify the installed version and customer workflow, and define the stop and recovery criteria. Confirm rollback compatibility before relying on it; software rollback cannot reverse every physical or financial action.
Pilot duration depends on hardware access, provider test environments and integration scope. Agree a schedule once those dependencies are known.