ID TECH offers three SDKs for mobile platforms: an iOS SDK, an Android SDK, and a .NET SDK. Although each of these SDKs behaves differently under the hood, they have similar enough method names and information structures that integrating developers can understand how to apply each one on a per-platform basis.

Differences in Implementation

Due to different development periods and platform requirements, each ID TECH SDK communicates differently. Each SDK is similar in terms that they drive multiple devices, and each SDK has same or very similar API calls, integrators still need to treat each SDK uniquely in implementation. The sections below provide a rough description of each SDK’s communication protocol.

For a full description of each SDK’s integration steps, see the ID TECH iOS SDK Reference Guide for VP3300, the ID TECH Android SDK Reference Guide for VP3300 AJ, and the ID TECH Windows SDK Reference Guide for Visual Studio Development, each available as part of the SDK download ZIP files on the ID TECH Knowledge Base.

iOS SDK

Our Native iOS SDK uses multiple protocols and callbacks (one per function). It also uses individual Device classes that map to the main device class. However, the main device class doesn't share the same API method as the individual device class. For example: IDT_VP3300 emv_startTrans executes IDT_Device.startTrans.

Android SDK

Our native Android Java SDK  uses a more limited set of On Receiver Listeners. The individual device classes have more device types than the iOS SDK, which just requires declaring the device is a VP3300; on Android, the application must declare the device is a VP3300_USB, a VP3300_AJ, or a VP3300_BLE.

.NET SDK

Our Visual Studio Windows SDK is our most comprehensive SDK. In this case, the SDK has a callback model, but just one callback that processes everything. Additionally, the IDT_Device class has an extended naming convention to match the individual device class names.

Similarities Between Platforms

Much like the different platform implementations, there is no easy way to map each SDK’s API calls to another; the platforms and devices have too many differences respective to each other. However, there are some key similarities developers can look for when migrating an application to a different platform.

Predictably, most of the methods in each SDK have similar names, allowing integrators to find a common thread to trace when navigating each SDK’s reference guide. The call to start an EMV transaction is an obvious starting point:

Each of the calls above is copied as it appears in the three reference guides, and, although each SDK has its respective syntax, the main call—emv_startTransaction()—is the same across all three implementations. Integrators will find similar continuity for most methods across ID TECH SDKs.

Other information may be similar across two SDKs but have a different name in the third SDK. For example, the iOS and Android SDKs use unencryptedTags as a parameter field for unencrypted EMV Tag data, but the Windows SDK simplifies this parameter to tlv, whether the EMV Tag data is unencrypted, encrypted, or masked. While the names for the fields don’t map perfectly, or return exactly the same granularity of response, the reference guides provide enough of a common thread to give an integrator a sense of what to look for when the SDKs have differences.

Using the Reference Guide Implementation Examples

ID TECH encourages integrators to refer to each reference guide’s Core Implementation sections:

In addition to the basic required libraries, platform-specific protocols, and initializations, each guide provides a sample project for its SDK demonstrating how basic calls and callbacks function. Using each reference guide to determine areas of similarity, plus sample projects demonstrating basic implementations, should give integrators the jump-start they need to integrate ID TECH SDKs into an application on multiple platforms.