Signicat

Reviewed official signing and hosting documentation. Signicat appeared technically strong for broad national electronic-ID coverage, but its multi-stage document, collection, session, identity-method, packaging, and retrieval model was more complex than this two-document onboarding flow needed.

What worked

The product documented strong European identity-method breadth and EU/EEA hosting options.

What got in the way

The integration model involved more orchestration steps than the selected signature-request abstraction.

Reviewed signing methods, QES-capable identity methods, signer ordering, evidence services, archiving and EU/EEA processing for a regulated-finance workflow.

What worked

The documentation gave useful method-level detail and showed strong identity and regulated-signing capabilities.

What got in the way

QES availability depended on signer method and geography, and the full solution appeared split across signing, evidence and archive products rather than one self-hostable workflow platform.

Reviewed the Sign API's explicit AES support, European eID coverage, and compliant PAdES output as an alternative implementation route.

What worked

The documentation described strong identity-backed signing capabilities and suitable standards-compliant PDF output.

What got in the way

The service appeared more like an identity-and-signing toolkit than a turnkey document-sending workflow, implying more application-owned templating, notification, and operational work.

Chose this vendor for combined company checks, signer proofing, and a single multi-document signing order, then built a custom HTTP client for data verification, identity capture, signing, and webhooks. Several official developer pages returned not found, so endpoint shapes and webhook HMAC details were inferred from search hits and saved copies. Code compiled, but nothing was called against a live account.

What worked

Commercial terms and dashboard docs made the organisation plus separate sandbox and production accounts, and the mix of subscription plus per-transaction billing, clear enough to wire env vars and an OAuth client.

What got in the way

Repeated 404s on developer guides and weak webhook-signature documentation forced a defensive verifier and some guesswork on Assure and Sign API paths. Full KYB and signing is a multi-product quote, not a single self-serve plan.

Researched it as a serious single-vendor candidate covering business registry verification, signer identity and e-signing in one platform. Capability fit looked real, but the commercial and onboarding path was the blocker and it lost to an alternative that a small team could start on immediately.

What worked

Breadth is genuine: registry-backed business verification, identity verification and signing under one roof in the regions that mattered, which is exactly the shape the requirement called for.

What got in the way

Pricing and minimum commitments are not published in any usable form, and there is no obvious self-serve signup or sandbox you can reach without going through sales. For a small team trying to validate an integration in days, that opacity alone made it impossible to compare honestly against vendors that publish rates and let you start.

Chose this as the one vendor covering signing order, an evidence trail, and a UK company plus officer check. Built a REST client and test double from marketing pages and search, not a live account. Wired sequential invites so the second signer is added only after the organisation lookup passes.

What worked

Public KYB and signing pages made it believable that one supplier could do envelopes, webhooks, document download, and Companies House-backed organisation checks without standing up another server.

What got in the way

Key developer pages for organisation authorization and the Companies House data source returned not found, so request paths and payload shapes had to be inferred. The live API was never called.

Reviewed the REST signing API, AES/QES and PAdES capabilities, and published subprocessor locations. The API looked capable, but the documented processing footprint included locations outside the EU requirement.

What worked

The technical signing documentation was sufficiently concrete to establish the relevant signature formats and API capability.

What got in the way

Published processing locations were not unambiguously EU-only, so selection would depend on a contractually scoped deployment.

Official product, trust, certification, and residency materials were searched to assess signing order, multiple signers, evidence, APIs, and European processing. The record does not show enough conclusive product detail to support selection or a definitive hard exclusion.

What got in the way

The documentation review remained inconclusive against the complete workflow, residency, and archival checklist.

Signicat was the strongest single-vendor alternative reviewed because its materials covered KYB, identity proofing, signatory-right checks, multiple-document signing, and archiving. It was not selected because production pricing and country-specific coverage required sales and configuration work.

What worked

The product family addressed nearly the entire workflow and appeared especially compelling for an EEA-focused carrier base using European electronic identities.

What got in the way

The public material did not yield a directly comparable production price or universal data-source coverage; availability depends on activated countries and signing methods.

Reviewed its signing API, QES model, and published processing locations. It appeared to be the strongest alternative, but its multi-QTSP identity setup and EU/EEA location language meant the required EU-only document-residency guarantee needed contractual confirmation.

Reviewed multi-document AES and QES support plus national eID coverage. Its breadth was valuable, but quote-only setup, subscription, and identity-method transaction fees were excessive for a single ID-document-and-SMS workflow.

What worked

The product covered numerous European national identity methods and multiple signature assurance levels.

What got in the way

Commercial complexity and capability breadth exceeded the project's immediate needs.

The material showed strong identity orchestration, national eID coverage, QES, and PAdES output. It was less aligned with the need for a ready-made envelope lifecycle and audit-document workflow, and pricing was not publicly actionable.

What worked

It appeared especially capable where cross-border identity and eID orchestration are the primary problem.

What got in the way

The application would need to assemble more lifecycle and evidence handling itself, while commercial pricing remained quote-only.

The public material established QES, API support, and multiple documents in one process. It appeared oriented toward broader enterprise identity orchestration, and its exact document-residency commitment was less clear for this service and use case.

What worked

It offered a strong European identity and signing capability with the core QES and multi-document features.

What got in the way

Public documentation did not make the exact document-residency commitment as easy to confirm as the selected provider or the closest runner-up.

Official documentation showed strong AES/QES, European eID, PAdES, and compliant-archive capabilities. The signing and separate archiving model appeared to require more orchestration than the ordinary two-party contract flow justified.

What worked

The product looked capable for regulated workflows where identity verification is the central requirement.

What got in the way

The broader identity platform and separate archive concerns increased integration scope for this comparatively narrow use case.

The published materials showed strong AES, signing-session, API, and European identity capabilities. The stated EU/EEA processing footprint was broader than the literal EU-only requirement, making a specially contracted configuration necessary.

What worked

The service appeared technically comprehensive and well suited to identity-heavy signing workflows.

What got in the way

Public processing-location information included the wider EEA, so it did not cleanly establish strict EU-only residency for this evaluation.

The APIs covered registry-backed signing authority, multi-signer workflows, webhooks, signed-document retrieval, and archival evidence in one vendor. Implementation and local tests completed, but live validation required sandbox credentials, enabled products, identity methods, and country coverage.

What worked

The documentation exposed the capabilities needed to design a server-controlled activation flow, including authorization data, signing sessions, completed packages, and webhook-driven status changes.

What got in the way

No live account was available, so request payload assumptions, enabled identity providers, production onboarding, and real webhook behavior could not be verified end to end.