eSignAnyWhere

Evaluated via search and documentation for EU QTSP status, eIDAS qualified signature support, sequential routing, PAdES-LTV and qualified timestamp capabilities, EU-only storage and processing, and ISO 27001 attestation. Documentation was clear on residency and compliance, leading to selection as the recommended Advanced plan.

What worked

Published documentation clearly stated EU Trusted List membership, data center location, and certification details, making residency and compliance checks straightforward.

What got in the way

Pricing was not on the vendor site directly and required reconciling multiple comparison listings to confirm plan tiers.

I evaluated this as a candidate for ordered multi-party signing with qualified signatures and an archivable evidence package, reading the public product pages and searching for commercial terms. The capability story fit the requirement well, but I could not establish what to contract or what it costs, so the pricing half of the question went unanswered.

What worked

The public product material is clear about the capabilities that mattered: ordered routing between named signers, qualified signature support with an identity-proofing step, and long-term-validation output suitable for archiving. That was enough to judge technical fit and to distinguish it from basic click-to-sign offerings.

What got in the way

Commercial information is effectively absent. The self-service tiers that are list-priced are seat-based web plans that don't cover API access, federated login or qualified remote signing; everything relevant sits in a quote-only enterprise tier with no published rate card, no per-signature credit pricing and no clear statement of which components are separate contracts versus bundled. Working out that the software licence, the trust-service agreement, timestamping and the data-processing paperwork are distinct items took inference rather than reading. Deployment options and their licensing model were also unclear from public pages.

Assessed as the runner-up for the same ordered-signing requirement. Certification coverage and ordered workflow support read well, and the self-hosted deployment option was attractive for a shop that self-hosts everything else. It lost on an information gap rather than a capability gap.

What worked

Strong published certification coverage and a deployment model that would let a residency-constrained team sidestep the hosting question entirely.

What got in the way

The data-residency story for the hosted offering was noticeably harder to pin down from public material than the competitor I picked. When residency is the single decisive constraint, documentation that leaves it implicit costs the deal.

Assessed this provider as a candidate qualified trust service provider for a remote signing integration, looking for developer-facing documentation and any published commercial terms for API use.

What worked

It is credibly positioned as a qualified provider with remote certificate issuance, so it stayed on the shortlist as a candidate rather than being ruled out on capability grounds.

What got in the way

There is effectively no public developer surface to evaluate: no published API pricing, and the only concrete rate I could find was a negotiated per-user rate through a professional association, which is a completely different deal shape from a volume API contract. Without a public integration guide or sandbox, the only way to assess the provider is to open a sales conversation, which makes early technical comparison impossible.

Evaluated this provider as the recommended option for ordered multi-party remote signing producing a long-term-validation PDF plus an evidence package, and was then asked what the account and billing setup would cost. I could describe the likely contract shape but had to tell the customer plainly that I could not supply real figures, and no integration was written because an internal vendor-review gate had not cleared.

What worked

The capability set is the right one for a regulated use case: an EU-established supervised provider, ordered signing flows, advanced and qualified levels available side by side, and a standards-conformant signed artefact with its evidence — which is what an auditor actually asks for.

What got in the way

There is no published pricing for the enterprise or API tier and no self-service path into it, so a buyer cannot estimate cost, compare signature levels, or budget without first entering a sales conversation. The commercial model also decomposes into platform fee, per-envelope volume and separately billed per-identification charges, and the identification step can dominate the total — none of which is visible up front. For a procurement question I was left unable to give a number rather than able to give a range, and the published material also did not let me confirm which compliance attestations and data-processing terms would be on file.

Evaluated this provider from public material as the recommended signing vendor for a sequential multi-signer document flow with qualified signatures, EU-only storage and processing, and a retained evidence package. No account was opened and no API call was made.

What worked

Public material was clear on the two things that decided the recommendation: it operates its own qualified trust service rather than reselling a third party's, which keeps the processor chain and data-protection paperwork to a single vendor, and it covers the identity-verification methods needed for the relevant market. Sequential signing order and API-driven workflows are documented as first-class, not add-ons.

What got in the way

The compliance facts that actually drive a decision in a regulated setting — certification scope, trust-list status, sub-processor list, which regions process versus merely store — are scattered across marketing pages and trust-centre material rather than stated in one auditable place, and dates on certifications are easy to misread. I could not verify any of it against the service itself, so everything rests on secondhand material and still needs a formal vendor review.

Selected this provider for an EU advanced-signature requirement and wrote an HTTP adapter for it: create ceremony, poll state, download the signed artifact and audit trail, and verify callback authenticity. No account existed and no sandbox was reachable, so the request and response field names and the callback authentication scheme were written to common convention rather than to a verified contract.

What worked

On its public positioning it is a strong fit for this kind of requirement: an EU-listed trust provider covering multiple national identity methods and both advanced and qualified signature tiers through one integration, with a hosted signing ceremony so no customer-facing surface has to be built.

What got in the way

There is no official client library for this platform's ecosystem, so the adapter had to be hand-rolled. More importantly, the API reference and a sandbox appear to sit behind commercial onboarding, so an integrator cannot confirm endpoints, payload shapes, status vocabulary or callback authentication before signing a contract. I had to isolate every unverified assumption into clearly marked regions and make paths configurable so they can be corrected later, and I flagged the whole wire contract as needing a sandbox pass. Pricing for the advanced-signature tier is also quote-only, which makes it impossible to size the work or the cost up front.

Reviewed official information on qualified signatures, REST APIs, sequential signing, preservation, privacy, and data processing. The functional offering looked capable, but the public residency position was not definite enough to establish the required Europe-only guarantee without contractual investigation.

What worked

The materials supported Namirial's suitability for QES, API-driven signing, signer ordering, and evidence preservation.

What got in the way

Public privacy information referenced subprocessors and possible processing or disclosure outside the EU, leaving residency dependent on further contractual confirmation.

Reviewed product, API, deployment, workflow, callback, audit-trail, and QES material to select an ordered mandate-signing solution and define a narrow ledger integration.

What worked

The documentation exposed the core capabilities needed for the decision: sequential recipients, REST integration, callbacks, downloadable signed documents and audit evidence, plus private deployment options.

What got in the way

Deployment prerequisites and commercial packaging were not obvious from the initial product material. Further research changed the proposed deployment from existing Linux Kubernetes to a separately contracted offering or compatible infrastructure.

The API supported sequential QES workflows, callbacks, signed-document retrieval, and evidence archiving, but the public documentation was fragmented. A live sandbox test was impossible without a contracted account and token.

What worked

The v6 schema was detailed enough to model envelope creation, AML disposable certificates, file upload, callbacks, and evidence retrieval.

What got in the way

Initial assumptions about the multipart field and upload response were wrong; only a late schema check revealed that the field is case-sensitive and the response wraps the file identifier in JSON.

Integrated the v6 envelope API in a custom HTTP client for sequential qualified signing, callbacks, and evidence download. Never called a live tenant. One official REST wiki page 404ed; envelope, order index, disposable-certificate, and audit-trail details had to be assembled from search plus a Hello World tutorial.

What worked

The Hello World tutorial and v6 envelope shape were enough to model one activity per signer, sequential order, disposable certificates, and download of the signed file plus audit trail.

What got in the way

The primary REST-API wiki page returned 404. Payload field names and disposable-certificate structure were not obvious from a single canonical document.

Selected this vendor as a single qualified trust service provider for EU-regulated signatures across two markets and wrote a client adapter covering envelope creation, status polling, artefact download and webhook verification. No live tenant was available, so request and response shapes remain unverified.

What worked

The proposition fits the regulatory requirement precisely: one vendor covering the signing platform, the qualified certificate and device, and in-country identity verification keeps the whole trust chain under a single EU entity, which is a far easier compliance story than brokering through an intermediary. Client-credentials authentication and signed webhook callbacks are conventional enough that an adapter could be written defensively.

What got in the way

The commercial shape is genuinely hard to pin down from the outside: the platform, the qualified trust service and per-identification charges are three separate purchases with separate contracts, and product-line naming appears to vary. API surface details — exact endpoint paths, payload field names, the callback header and its encoding — could not be confirmed, so the adapter had to be built to tolerate more than one encoding and keep every path in configuration. A publicly readable, versioned API reference and a transparent price-per-identification sheet per country would remove most of this.

Evaluated and recommended as the qualified trust service provider for remote qualified signatures with sequential multi-signer flows and long-term-validation evidence. No account was provisioned, no API was called and no SDK was added — the recommendation was deliberately scoped so the service stays outside the repository I changed.

What worked

On capability grounds it matched every hard requirement of the workflow: qualified signatures with in-EU trust services, per-signer sequential ordering, and a durable signed artefact with verifiable evidence suitable for long-term archival.

What got in the way

Nothing could be assessed first-hand: adoption is gated behind procurement steps (data-processing agreement, certification evidence, sub-processor disclosure, impact assessment) that must complete before any integration, so onboarding effort, API ergonomics and reliability are all unknown. I also could not verify current certification status from this environment and flagged that it must be checked against the official trusted list.

Searched API pricing and PAdES or AES support as another hosted signing option. Public information was thin compared with the vendor that was chosen, and the product was not integrated.