Link Search Menu Expand Document
mSIGNIA uSDK

Frequently Asked Questions

What versions of iOS and Android are supported?

See the versions tables in the 7.x Mobile SDKs Overview.

What versions of EMV 3DS are supported?

That is documented in the 7.x Mobile SDKs Overview.

What certifications or compliance does the uSDK have? Is it certified for Visa, Mastercard, Amex, JCB, Discover, and China UnionPay?

uSDK is EMVCo certified and works with any payment scheme supporting EMV 3DS 2.1 or 2.2 (or 2.3 for uSDK 7.x). uSDK is registered with AMEX as this is a specific AMEX requirement. VISA, MC and Discover do not require additional registration or certification.

Does uSDK support regional card schemes like Russia’s Mir, India’s RuPay etc?

The uSDK should work with the regional schemes that support the v2.1 and v2.2 (and 2.3 for uSDK 7.x) 3DS protocols (since it is a standard). mSIGNIA will work with any regional scheme if required to register the uSDK.

How does mSignia verify the license of each uSDK implementation? Is there anything the merchant’s developers need to take note of to allow outbound communications from uSDK to mSignia’s licensing server?

The license key is validated about every 10 days when the SDK is initialized. The SDK calls the mSIGNIA license server to validate it. If the license is expired the SDK will not initialize. There is nothing special about the connection, it uses the standard internet connection the app uses.

How are transactions and usage fees calculated?

The SDK keeps local storage of each time the app requests data from the SDK for authentication. This is when either authenticate (Simplified Interface) or getAuthenticationRequestParameters (Spec Interface) is called. A time stamp and SDK Transaction ID is stored. About every 7 to 10 days the SDK will post this data to the licensing server (and verify the license is still valid). mSIGNIA uses the transaction data posted to the licensing server for billing the customer. If the transaction goes to challenge flows where additional data is passed, the same SDKTransactionID is used and there are no more additional transactions counted.

If a customer repeatedly calls authenticate or getAuthenticationRequestParameters due to bad programming practice, this would cause a lot of sdkTrxnIDs to be generated but the 3DS Server would only be sent a subset of those sdkTrxnIDs. Thus, the customer can review mSIGNIA’s list of generated sdkTrxnIDs against their list of received sdkTrxnIDs and resolve which sdkTrxnIDs were ‘valid’ for billing. mSIGNIA is able to ID the app/browser creating extraneous sdkTrxnIDs and have the customer work to fix the problem. If the app/browser refuses to fix this issue, mSIGNIA can ultimately block that app/browser from generating any sdkTrxnIDs.

Does the license key ever need to be updated?

The production license key should not need to be replaced. However, mSIGNIA may issue new API-KEYs for security reasons (i.e prevent leaked keys etc.) and request the customer to start using the new keys on their next app updates.

When mSignia releases an update of uSDK, how does the update reach the merchant?

mSIGNIA releases new uSDK binaries download links on this portal.

  1. Distributor downloads the binaries
  2. Distributor makes the binaries available to their customers via the distributor delivery process (i.e download link, repo etc.)

Contact mSIGNIA for other options such as Maven/Cocoapod repositories etc.

What additional data fields (in addition to 3DS data) are collected by the uSDK for SCA? How is the data included in 3DS messages and how does a standard 3DS 2.2 ACS decode and process those additional fields? And are they optional?

The uSDK supports additional fields (primitives) such as device tags (cookies), behavioral biometrics (typing pattern, device angle/tile, swipe/pressure gestures etc.), biometric prompt (fingerprint/face), and more. The additional data rides the existing 3DS2 message rails via deviceinfo field and messageExtensions. The ACS uses the same mechanism as already used for secure channel setup with the SDK for challenge/response (CReq/CRes). The SDK/ACS exchange keys and validate signed content in the CReq/CRes. This same format is used for the additional data fields. They are 100% optional.