mSIGNIA

Service Overview

3DS is a chain. A merchant or acquirer submits a transaction to a 3DS Server, the 3DS Server passes it to the scheme Directory Server, the Directory locates the issuer ACS, the ACS runs the challenge, and the result comes back. Each link has a different supplier, and a merchant usually touches only the 3DS Server, sometimes only indirectly, while the rest is decided by the acquirer, scheme and issuer. That structure matters when evaluating a tooling vendor, because tooling adds no strength to any link; it makes building the chain faster.

mSIGNIA is the only one of these 5 that neither processes transactions nor carries risk. It positions itself as supplying testing and tooling to the online payments industry so that payments and authentication become simpler, faster and more successful. There are 2 product lines. Payment Simulator delivers end-to-end payment testing, letting product developers run continuous testing and prototype validation, letting sales demo, and letting payment providers test third-party implementations. 3-D Secure Split SDKs are white-labellable EMV 3DS authentication SDKs that attach to an existing 3DS Server to deliver a complete checkout across Web, iOS and Android, built on 3DS v2.3, with the split design intended to make merchant integration faster and simpler. The site also lists 3DS Testing and FIDO capabilities.

Its customer base is broad by design. The vendor states that customers and collaborators span the entire online payments ecosystem: EMV 3DS product vendors, merchants, payment providers, acquirers, schemes, issuers, delegated authenticators, FIDO relying parties and risk engines. That list is itself a positioning statement. The company does not acquire and does not issue; it supplies parts and test benches to the parties that do.

Its value therefore lies not in fees or authorisation rates but in turning 3DS integration and certification, the part that most often slips, into a testable and reproducible process. Many 3DS launches are delayed not by business logic but by SDK adaptation, cross-browser and cross-device challenge compatibility, and scheme certification. The right metric is how much your team's integration and certification cycle shortens, not how much the pass rate rises, since the latter depends on risk policy, the issuer ACS and regulatory exemptions rather than on the SDK vendor.

If your institution already runs a mature 3DS Server with strong engineering, use it for one thing only: either the SDK or the testing tools, not necessarily both lines.

Key Strengths

• 1 SDK across 3 endpoints: Web, iOS and Android are solved inside one EMV 3DS SDK, which avoids the inconsistent experience that comes from three separate implementations and reduces endpoint retesting during certification.
• White-labellable: the SDK can ship under your own brand, which matters for 3DS Server vendors, payment providers and acquirers that do not want merchants seeing a third-party mark inside their checkout.
• Split design lowers the merchant barrier: the SDK is deliberately divided so merchant integration can be completed in stages instead of one large build, shrinking the scope of a single change.
• Recent specification version: it runs 3DS v2.3, the current mainstream version, which means more complete support for newer flows and fields and fewer post-launch reworks caused by protocol differences.
• Testing exists without the SDK: Payment Simulator supports end-to-end testing, prototype validation, sales demos and third-party implementation checks, so the tools remain usable even with another vendor's 3DS Server.
• Wide ecosystem footing: collaborators run from 3DS product vendors to schemes, issuers, delegated authenticators and FIDO relying parties, which means the components have been validated on integration paths for several roles and the interfaces suit multi-party setups.
• No transactional conflict of interest: because it does not process transactions or take risk, it holds no position on approval, challenge or scoring policy and works well as a neutral test baseline.

Product Ecosystem

3-D Secure Split SDKs

White-labellable EMV 3DS authentication SDKs on 3DS v2.3 covering 3 endpoints: Web, iOS and Android. They attach to an existing 3DS Server to deliver a complete checkout and challenge experience, with the split design breaking integration into smaller steps to shorten merchant onboarding. They replace neither the 3DS Server nor the ACS.

Payment Simulator

An end-to-end payment testing service with 3 uses: continuous testing and prototype validation for product developers, demos for sales, and third-party implementation testing for payment providers. For teams shipping frequently, it replaces the effort of maintaining an in-house simulation environment.

3DS Testing

The 3DS testing capability listed on the site, used to validate behavioural consistency in the authentication flow before formal certification. It complements Payment Simulator, since one targets end-to-end payment simulation across the chain and the other targets the authentication step itself.

FIDO Capabilities

FIDO capabilities are also listed. FIDO and 3DS are complementary rather than substitutes: 3DS verifies the cardholder at the transaction moment, while FIDO handles stronger device binding and passwordless authentication, and both can coexist in one checkout.

Ecosystem Roles and Integration Paths

The vendor states that customers and collaborators include EMV 3DS product vendors, merchants, payment providers, acquirers, schemes, issuers, delegated authenticators, FIDO relying parties and risk engines. Since the same SDK and tools must work across several integration paths, buyers should confirm the path and support terms that match their own role.

Limitations

• No authorisation lift, no fee change: it does not process transactions or take risk, so expectations about approval rates, chargeback ratios or pricing are misplaced. The return is schedule and labour, which should be modelled in engineering cost rather than transaction cost.
• You must already own a 3DS Server and compliance programme: the SDK attaches to an existing Server, and the institution still needs risk policy, a scheme certification path and PCI DSS scope management. Missing any of these blocks go-live.
• Part of the 3DS experience is outside your control: even with the SDK integrated, challenge UI, frictionless pass rates and failure semantics come from the issuer ACS and the scheme directory. The SDK guarantees process correctness, not a uniform user experience.
• Frictionless ratios follow risk models and exemptions: whether a challenge triggers is not a client SDK decision but a risk and exemption decision, so swapping SDKs will not lower challenge rates.
• 3DS does not cover every fraud type: post-authorisation fraud, friendly fraud, first-time card binding after takeover and parts of APP scams stay outside what tooling addresses and still need monitoring and dispute processes.
• Compliance responsibility does not move with a third-party SDK: adding an SDK widens the code surface, while PCI DSS scope assessment and SCA evidence remain with the merchant and acquirer. The vendor delivers an implementation, not a compliance conclusion.
• Integration and certification still take months: the SDK shortens your own adaptation work, but scheme certification and issuer integration follow external schedules, so overall launch timing is not controlled by tooling alone.
• Cost tracks project count, not volume: tooling purchases save schedule and labour rather than per-transaction cost, and neither grow nor shrink meaningfully with transaction volume, unlike usage-priced risk products.

Use Cases

• 3DS Server vendors and payment providers filling in the client layer (★★★★★): when Web, iOS and Android need one consistent challenge experience, a single white-labellable SDK costs less engineering than maintaining 3 separate implementations.
• Merchants with a self-built checkout and an existing 3DS Server (★★★★☆): if only the client challenge component and testing capability are missing, the SDK and tools can be added without replacing the Server.
• Payment teams with heavy regression testing needs (★★★★★): the continuous testing and prototype validation in Payment Simulator maps directly onto high release frequency.
• Delegated authenticators and FIDO relying parties (★★★☆☆): the listed capabilities overlap partly with these roles, though exact integration must be confirmed per project.
• Teams preparing for scheme certification (★★★★☆): using the testing tools early surfaces cross-browser and cross-device problems before the certification phase and moves rework upstream.
• Mainland China operations (☆☆☆☆☆): domestic card 3DS runs through domestic acquirers and the domestic scheme and overseas 3DS components are not part of it. Cross-border sellers on overseas acquiring can use the SDK after confirming acquirer and scheme admission for both the 3DS Server and the SDK.
• Worst fit: merchants hoping to buy a better pass rate (★☆☆☆☆): since it does not process transactions or take risk, any procurement motive based on approval rate or fee improvement will not be met.

Pricing

Cost drivers include endpoint coverage across Web, iOS and Android, whether white-labelling is required, the number and concurrency of simulation environments, whether 3DS Testing and FIDO components are included, support tier and response targets, and whether the vendor supports your scheme certification. No price list is published, so concrete figures belong in a contract, and comparing unit cost against usage-priced risk products is not meaningful because the billing logic differs.

The table reflects the currently published product structure on the mSIGNIA website. No standard rate card is published; actual quotes and delivery scope are governed by your contract.

FAQ

• Is mSIGNIA a 3DS provider?
  It is a component and tooling supplier rather than a full 3DS provider. It offers an SDK that attaches to a 3DS Server plus testing tools, does not process transactions or take risk, and replaces neither the Server nor the issuer ACS.

• Will it raise my frictionless ratio?
  No. Whether a challenge triggers depends on risk policy, the issuer ACS and regulatory exemptions, and the SDK only ensures the challenge flow executes correctly on Web, iOS and Android.

• How do Payment Simulator and 3DS Testing differ?
  Payment Simulator focuses on end-to-end simulation of the whole payment chain for continuous testing, prototyping and demos, while 3DS Testing focuses on the authentication step itself. They work together but can also be bought separately.

• I already have a mature 3DS Server. Can I use only part of it?
  Yes. The SDK and the testing tools are separate products, so a strong engineering team can add the SDK for the client layer, or add only the tools for regression testing, without buying both lines.

• Is it suitable for mainland China merchants?
  Domestic card 3DS runs through domestic acquirers and the domestic scheme and overseas 3DS components are not part of that path. Cross-border sellers on overseas acquiring can use the SDK, after confirming 3DS Server and SDK admission plus certification requirements with the acquirer.

Source: original 16IDC content. Product capabilities, supported countries and fee definitions follow the official documentation on msignia.com and your contract.