Security · privacy · trust

Know where your document goes — and what PocketESign keeps.

PocketESign separates the WordPress product layer from specialized signing, payment and email infrastructure. This page explains the practical controls behind that architecture.

See the workflowRead Privacy Policy
1Your browserAccount · PDF editor · dashboard
→
2PocketESignAccounts · credits · metadata · API adapter
→
3Signing infrastructureSigning request · recipient events · completed document
Stripe-hosted Checkout
Authenticated SMTP
Google consent-controlled analytics
Security principles

Keep the sensitive parts where they belong.

PocketESign does not try to implement every security-sensitive signing function directly inside WordPress.

Provider credentials stay server-side

Signing-provider and payment secret keys are stored encrypted and are not exposed to the browser.

No source PDF in Media Library

The uploaded source PDF is not retained in the WordPress Media Library. It is transmitted into the signing workflow.

Signed lifecycle webhooks

PocketESign verifies signed webhook events before applying document-status or payment-credit updates.

Hosted payment entry

Full card details are entered in Stripe-hosted Checkout rather than stored by PocketESign.

Account isolation

Customer-facing document and template queries are scoped to the signed-in account, with administrative access separated.

Export & deletion workflows

Account data can be exported, and deletion requests are reviewed against retention, audit and provider-side obligations.

Document data flow

What happens after you upload a PDF?

The signing workflow needs the document, but PocketESign minimizes what the WordPress application retains.

UploadPDF selected in PocketESign

The browser submits the document for the signing workflow.

→
PrepareSigning request / draft

The specialized signing infrastructure receives the document required for preparation and signing.

→
TrackMetadata in PocketESign

PocketESign stores account-facing metadata such as document name, provider request ID, recipients, status and credit state.

→
CompleteCompleted record

The completed signing workflow and activity remain retrievable according to the provider and PocketESign retention process.

Important distinction:“Not stored in WordPress Media Library” does not mean “the document is never processed or stored anywhere.” The signing infrastructure must process the PDF to deliver the requested signature workflow. See Privacy Policy, DPA and Subprocessors for the current disclosures.
Verified events

Status changes are not trusted just because a browser says they happened.

PocketESign uses provider-to-server webhook events for signing lifecycle and Stripe purchase reconciliation. The webhook signature is verified before the event is accepted.

Firma lifecycleViewed, Completed, Declined, Expired and related signing events.
Stripe paymentsCredits are added from a validated paid Checkout event, not just from the customer's return URL.
Replay protectionWebhook/event identifiers are checked so the same event is not applied repeatedly.
Signed webhookverified
event: signing_request.completed
SignatureHMAC / provider signature verified
Request IDMatched to PocketESign document
ActionStatus → Completed · credit Reserved → Used
Accounts & email

Security also means protecting the ordinary account workflow.

Service providers

PocketESign is not a one-server system.

Signing, hosting, mail, payments and analytics each use specialized providers. We disclose the material processors instead of hiding the dependency chain.

SigningFirma.dev

Document-signing infrastructure, recipient events and completed signing workflow.

 PaymentsStripe

Hosted Checkout and payment processing for paid credit packs.

 Hosting & mailInfrastructure providers

Website hosting and authenticated account/support email delivery.

 AnalyticsGoogle / Site Kit

Optional measurement controlled through the consent stack.
DraftCan be deletedUnsent provider-side drafts can be removed through the supported deletion path.
Sent / completedAudit implicationsSent signing records may need cancellation, retention or provider-side review rather than a misleading instant-delete button.
Account dataExport / deletion requestUsers can export account data and submit deletion requests for review.
Retention & deletion

Deletion is treated as a data workflow, not a cosmetic “hide” action.

A sent signing record can have audit, contractual or legal relevance. PocketESign separates deletable drafts from records that require cancellation, retention review or coordinated provider-side deletion.

Read Data Retention & Deletion →
Security FAQ

Clear answers about the architecture.

Does PocketESign store my uploaded source PDF in WordPress Media Library?

No. The uploaded source PDF is not retained in the WordPress Media Library; it is processed through the specialized signing infrastructure used to deliver the signing workflow.

Does the browser receive the signing-provider API key?

No. Signing-provider credentials are kept server-side and are not exposed to the browser.

How are signing-status updates protected?

PocketESign verifies signed webhook events from the signing provider before applying lifecycle updates such as Viewed or Completed.

Does PocketESign store full card numbers?

No. Paid credit packs use Stripe-hosted Checkout, so full payment-card details are handled by Stripe rather than stored by PocketESign.

Where can I see PocketESign subprocessors?

The Subprocessors page lists material third-party providers involved in signing, hosting, email, analytics and payments.

Can I request deletion or export of my account data?

Yes. PocketESign includes account-data export and reviewed deletion-request workflows, subject to lawful retention and audit obligations.

Want the policy details?

Review the legal and data-handling documents.

Privacy, DPA, subprocessors, retention and electronic-signature consent are published and linked directly.

Open Privacy Policy