G+D Netcetera manages 1.4 billion tokens
Payment tokenization as prerequisite in e-commerce
The SDK enables configurable device data collection, the information that helps an issuer's risk system decide whether to approve a transaction frictionlessly.
Better risk scoring, more frictionless transactions.
Full support for both EMV 3DS frictionless and challenge flow, handled entirely within the merchant app. When a challenge is needed, it appears inside the app — not in a browser.
Native UI or HTML UI for challenge screens. No redirects, no context loss, no abandonment.
PCI ready product. G+D Netcetera builds both the 3DS SDK and the 3DS Server it communicates with. Testing is done against the actual counterpart, not a simulation.
That difference shows in production — fewer integration surprises and better performance from day one.
Authentication that stays inside the app, completes in seconds, and never confuses the customer is authentication that does not cost you sales. Better user experience, significantly reduced abandonment rate, increased transaction volume.
Designed as a showcase for integration of 3DS SDK in merchant native shopping apps. The Netcetera Demo Merchant (NDM) application for Android and iOS which comes along with the 3DS SDK delivery shows exactly what SDK integration looks like inside a real shopping app.
G+D Netcetera builds the 3DS SDK, the 3DS Server, the Access Control Server, and the Directory Server. The SDK is tested against the actual server-side components, not a third-party simulation. That is a different quality standard, and it shows in integration and in production.
The SDK collects richer, more relevant device context with every authentication request. More context gives the issuer's risk system more signal. More signal means more transactions approved frictionlessly. For a PSP processing meaningful volume, that frictionless rate is a direct revenue driver.
3DS SDK Is compliant with all major schemes’ 3DS programs and updates the schemes certificates automatically. No action from the Customer is needed. Scheme compliancy is fully taken care of.
It holds separate EMVCo approvals for Android and iOS, both at EMV 3DS 2.3.1.1 and 2.2. Being first means the implementation has been tested longer and more thoroughly than any alternative.
Compliant with EMV 3DS programs of all major schemes.
The data that helps issuer risk systems decide whether to approve a transaction frictionlessly. Collection is configurable, giving merchants and PSPs control over what data is included.
More relevant data means better risk decisions, which means more frictionless outcomes for the cardholders who deserve them.
Full support for EMV 3DS frictionless and challenge flow. For frictionless transactions, authentication completes automatically in the background.
For challenge flows, the SDK manages communication with the Access Control Server and renders the challenge interface within the app. Both paths are fully supported, fully tested, and compliant with the EMV 3DS specification.
Native UI renders the challenge screen using native mobile components, matching the look and feel of the merchant app. HTML UI renders the issuer's own branded challenge experience inside the app, giving issuers full control over design. Neither option uses an external browser redirect.
The right choice depends on whether priority is matching the merchant app experience or giving the issuer maximum flexibility over their challenge design.
Detecting rooted devices, emulators, and other conditions that indicate elevated fraud risk.
These checks happen as part of the standard SDK flow, adding an additional fraud signal layer to every authentication request without requiring extra implementation effort from the integrating team.
It shows exactly what SDK integration looks like inside a native shopping app, with a working demo environment developers can run themselves. The yearly license includes comprehensive technical documentation, full online support, and webinar education sessions.
The vast majority of genuine transactions complete without any challenge at all. The SDK processes authentication invisibly. The customer taps pay, the result comes back clean, and the purchase completes. No interruption, no re-orientation, no reason to abandon.
When a challenge is required, Native UI renders it using the same visual language as the merchant app. The customer never feels like they have been handed off to a different product. The transition is seamless because technically it never happened, they stayed in the app throughout.
Whether the card is Visa, Mastercard, AmEx, or any other supported network, the cardholder gets the same contained, consistent authentication experience. No surprises based on which card they reach for.
Authentication is not PSD2 hygiene. It is the control that decides whether a suspicious payment is stopped early or becomes a loss, a complaint, and a regulator headline. Treat it like the revenue-and-trust lever it is."
The 3DS SDK lives inside the merchant's native mobile app. When a payment is initiated, the SDK: (1) performs device security checks, (2) collects device information, (3) initiates the 3DS authentication request to the 3DS Server, (4) handles the frictionless result or triggers the challenge flow if needed, (5) renders the challenge screen inside the app using Native UI or HTML UI, and (6) returns the authentication result.
The merchant app does not leave the 3DS flow at any point.
As fraud becomes more sophisticated — AI-driven attacks, synthetic identity fraud, device spoofing — the quality of the device data sent in the 3DS authentication request becomes increasingly important.
An SDK that collects richer, more accurately characterized device context gives issuer risk systems better raw material. Better raw material leads to better decisions. Better decisions mean fewer genuine customers challenged and fewer fraudulent transactions approved.
The SDK handles the mobile client side: device data collection, security checks, and the challenge flow if one is triggered inside the merchant app.
The 3DS Server handles the acquirer or PSP side: initiating the authentication request, managing the Directory Server conversation, and processing the response. The SDK and 3DS Server are separate components that work together.
The SDK is the mobile piece — it cannot replace the Server, and the Server alone cannot deliver in-app authentication. Both are needed for a complete EMV 3DS implementation in a native mobile environment.
Native UI renders the challenge screen using native mobile components — the same building blocks as the rest of the merchant app.
The challenge content comes from the ACS, but the presentation is native. It looks and feels like part of the app. HTML UI renders the issuer's own HTML-based challenge screen inside the app — giving the issuer full control over branding and design. Neither option uses a browser redirect.
The right choice depends on whether priority is matching the merchant app experience (Native UI) or giving the issuer maximum flexibility over their challenge design (HTML UI).
Because authentication is a two-way conversation between the SDK and the 3DS Server. When the same team builds both, integration testing is done against the actual counterpart — not a third-party mock that approximates what the Server might do. The device data the SDK collects is designed with the Server's data handling in mind.
The challenge flow the SDK renders is tested against the ACS behaviour the Server expects. That internal coherence shows up as fewer integration surprises and better production performance.
The annual license includes the 3DS SDK for Android and iOS — both with separate EMVCo certifications — comprehensive technical documentation, the Netcetera Demo Merchant app for Android and iOS, full online support, and webinar education sessions.
G+D Netcetera commits to regular product improvements, so as the EMV 3DS specification evolves, the SDK is updated and clients stay current. SDK download requires login to the G+D Netcetera partner portal.
Frictionless authentication happens when the issuer's ACS decides the transaction is low-risk — based on the data it receives. The SDK's role is to maximize the quality and relevance of that data with every authentication request: device fingerprint, payment context, security check results. The richer and more accurate that data, the more transactions the ACS can confidently approve without challenging the cardholder.
Fewer challenges means fewer interruptions at checkout. Fewer interruptions means fewer abandoned carts. Better device data is the upstream cause of the downstream conversion improvement.