App-based 3D Secure has a reputation for producing better frictionless rates than browser flows, and the reason is usually given as richer device data. That is true, but it is an incomplete answer. The more interesting part is how the data is structured, and how it gets to the issuer without the merchant or the acquiring side ever being able to read it.<\/p>\n
For any team integrating the SDK<\/a>, the transport model is worth understanding properly. It explains several constraints that otherwise look arbitrary.<\/p>\n The core specification defines device information to allow rich device data collection on app-based transactions, and a dedicated EMVCo specification defines the common and operating-system-specific elements the SDK captures during an authentication request.<\/p>\n The categories include device manufacturer and model, operating system and version, geolocation data including IP address and locale, device IP and fingerprint, telecom data such as SIM metadata, and user interface preferences and settings.<\/p>\n The data set serves two purposes rather than one. It assists in assessing transaction risk, which is the well-known function. It can also provide information on the capabilities of the device, which informs how authentication methods are presented during a challenge. That second function is underused. An ACS that knows what a device can do is better placed to choose a challenge method the cardholder can actually complete.<\/p>\n This applies across all app-based implementations, including both the Default-SDK and the Split-SDK and its variants.<\/p>\n The elements are captured as JSON name and value pairs, each with an identifier key, and grouped into sets.<\/p>\n There are common device identification parameters that apply regardless of platform. There are operating system-specific parameters, defined separately for Android and for iOS. And there are platform provider-specific parameters. The decrypted device information delivered to the ACS contains either the common parameters together with the operating system-specific parameters, or the platform provider-specific parameters, depending on what the SDK determines.<\/p>\n Within the operating system-specific sets the elements vary considerably in nature, ranging from probabilistic device identifiers through to user profile metadata held on the device.<\/p>\n The keyed structure exists for a practical reason. Operating systems typically release at least one major version each year, and platform providers restrict or modify access to particular data over time. Keying each element by identifier means the specification can adapt quickly when an element is changed or restricted, without restructuring the whole format.<\/p>\n This is the part worth understanding precisely.<\/p>\n The SDK collects the device information using built-in operating system APIs. It then encrypts that data using the Directory Server public key and sends it to the 3DS Server, which forwards it on the authentication request as SDK encrypted data. The DS receives it, decrypts it, and passes the device information to the ACS for use in risk assessment and cardholder verification.<\/p>\n The 3DS Server handles the payload without being able to read it. The connection between the SDK and the DS is required to be secured using the DS public key even though the 3DS Server is facilitating the connectivity. The stated purpose is to preserve cardholder privacy and uphold the security model of the protocol, and the result is that the requestor cannot access or modify device-level data during an authentication request.<\/p>\n All device information is accessed only by the ACS. That is the same principle that governs the browser-channel mechanism, applied to a much richer data set.<\/p>\n There is an operational consequence here that catches integrators out.<\/p>\n The DS public key must be obtained from each supported network. That process is subject to network programme rules, and it requires a valid EMVCo Letter of Approval.<\/p>\n In other words, SDK device data collection is not something you can stand up unilaterally. Every scheme you intend to support requires its own key, obtained through that scheme’s own process, and approval is a precondition. Teams planning an app-based rollout should treat key acquisition as a lead-time item in the project plan rather than a configuration step at the end.<\/p>\n EMVCo’s guidance is direct. It strongly recommends populating all the fields accessible to the SDK, subject to device and runtime permissions, in order to better inform network and issuer processing systems.<\/p>\n The word subject is doing important work. Accessibility is determined by what the device exposes and what permissions have been granted, and the specification accommodates that. The recommendation is to supply everything genuinely available, not to pursue data the platform or the cardholder has not made available.<\/p>\n There is a related discipline point that applies across the whole authentication request. Incomplete or incorrect information, such as placeholder values that do not accurately represent the cardholder or the transaction context, can lead to increased challenges or, at worst, declined authentication. Sending a dummy value is not a neutral act. It is an assertion, and the ACS will treat it as one.<\/p>\n This section is short and it is the one that most often gets discovered late in a project.<\/p>\n In line with regional regulations and operating system provider policy, the 3DS Requestor is required to provide prominent disclosure of the use of this data in the application at the time of submission to the operating system provider, specifying which elements may be collected and used as part of a 3DS authentication.<\/p>\n At installation, the requestor app must prominently disclose to the user that the app will access and use sensitive user data such as a phone number, and that it will provide access to that data to the SDK and the ACS for transaction risk assessment.<\/p>\n When sensitive user data is invoked for an authentication, the SDK must verify user consent and permission before requesting that data from the requestor app, implemented in line with the permission designation in the device information specification.<\/p>\n And one rule that is easy to violate by accident. The 3DS SDK must never prompt for user consent or permission for any data within a 3DS authentication. Consent is obtained by the app, in advance, through the platform’s own mechanisms. It is not requested mid-transaction.<\/p>\n If your app submission copy, your permission prompts and your privacy disclosures were written before the 3DS integration was scoped, they need revisiting. This is a compliance and store-approval question as much as an engineering one.<\/p>\n The SDK device information specification has been published multiple times, each publication incrementing the version of the device information object. All 3DS components are expected to support the latest device information version in order to maintain compatibility with each operating system platform provider.<\/p>\n Combined with the annual cadence of major operating system releases, this makes device information versioning a recurring maintenance obligation rather than a one-off integration task. It is one of the more reliable triggers for regression testing across an app-based estate, and it is worth building into a planned cycle rather than responding to it each time a platform changes.<\/p>\n Three things, if you take nothing else.<\/p>\n Key acquisition per scheme has lead time and depends on approval. Start it early.<\/p>\n Consent and disclosure obligations sit with the requestor app and must be handled before submission, not after a rejection.<\/p>\n And device information versioning will require you to come back. Plan for it in your release cadence rather than treating each update as an incident.<\/p>\n Can the 3DS Server or the merchant read the device data?<\/strong><\/p>\n No, and this is by design. The SDK encrypts the data with the Directory Server public key, the 3DS Server forwards it without being able to read it, and the Directory Server decrypts and passes it to the ACS. The stated purpose is to preserve cardholder privacy and ensure the requestor cannot access or modify device-level data during an authentication.<\/p>\n What type of encryption key will the Directory Server issue?<\/strong><\/p>\n Either elliptic curve or RSA. The type issued is determined by the Directory Server programme rules, and SDKs are required by the specification to support both key types, so your integration cannot assume one or the other.<\/p>\n What happens when the SDK cannot retrieve a data element?<\/strong><\/p>\n It must be declared rather than silently omitted. All device information the SDK is unable to provide or retrieve must be listed as a device parameter not available. This tells the issuer that the element is genuinely unobtainable rather than simply missing, which is a materially different signal for risk assessment.<\/p>\n Does the device information version have to match our protocol version?<\/strong><\/p>\n No. EMVCo changed the version format so that it indicates the data version number rather than the specification version, and the most recent data version is backwards compatible with previous specification versions. The update cycle is tied to operating system releases rather than the specification release cycle, and ACS providers are urged to support all announced data version numbers to help avoid step-up authentication.<\/p>\n Integrating a 3DS SDK?<\/strong> ActiveSDK<\/a> is the GPayments mobile 3DS SDK. Speak with a 3DS specialist<\/a> about app-based device data and integration planning.<\/p>\n\n\n\n\n","protected":false},"excerpt":{"rendered":" App-based 3D Secure has a reputation for producing better frictionless rates than browser flows, and the reason is usually given as richer device data. That is true, but it is an incomplete answer. The more interesting part is how the data is structured, and how it gets to the issuer without the merchant or the […]<\/p>\n","protected":false},"author":13,"featured_media":3024,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[2],"tags":[37,109],"class_list":["post-3022","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article","tag-acs","tag-sdk"],"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3022","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/comments?post=3022"}],"version-history":[{"count":3,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3022\/revisions"}],"predecessor-version":[{"id":3029,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3022\/revisions\/3029"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media\/3024"}],"wp:attachment":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media?parent=3022"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/categories?post=3022"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/tags?post=3022"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What gets collected<\/strong><\/h2>\n
How the data is structured<\/strong><\/h2>\n
The transport model, and why the 3DS Server cannot read any of it<\/strong><\/h2>\n
The key distribution constraint<\/strong><\/h2>\n
Populate everything you are permitted to<\/strong><\/h2>\n
Consent, disclosure and what the SDK must never do<\/strong><\/h2>\n
Version alignment is not optional<\/strong><\/h2>\n
What this means for an integration plan<\/strong><\/h2>\n
Frequently Asked Questions<\/strong><\/h2>\n