Contract bodies, signature blobs, and inbound email content are encrypted with AES-256-GCM before they reach the database. The key is held in the application host’s environment, not in the database, so a database read alone does not reveal contract or signature content. Signed contracts are immutable at the database level — a trigger blocks edits and deletes after signature.
contracts.body_text— the full contract body shown to the client at signing.
contracts.signer_signature_blob— the drawn signature image bytes.
dispute_kits.notes— free-text notes you add to a dispute kit before generating the PDF.
project_emails.subject and project_emails.body— inbound email captured via the BCC alias for evidence threads.
project_emails.raw— body content is stripped from the inbound payload before storage. Only headers and attachment metadata remain.
Encryption breaks search and sort. Some keys stay readable so the product works.
Project and client title, email, billing address — drives listing, search, and invoice rendering. Invoice line items, total, currency, status — drives the project view and the dispute kit summary. Activity log payloads are pseudonymous by design; PII is not written into payloads. Contract metadata (signed_at, IP, UA, body_hash) stays readable because the evidence value depends on these being readable to the bank.
The database disk is encrypted at rest by the platform host (AES-256). That covers stolen-backup risk; the application layer covers vendor-read and key-isolation risk.
When a contract is signed, three columns lock at the database level via a trigger: body_text, body_hash, and the four signing fields (signed_at, signer_ip, signer_ua, signer_signature_blob). UPDATEs touching any of those raise check_violation; DELETEs are blocked entirely. The trigger fires for service-role connections too — even we can’t edit a signed contract.
| Attack | Posture |
|---|---|
| Stolen database backup or disk imageDisk AES plus column-level ciphertext. | Defended |
| Database vendor reads tables directlyThey don’t hold the application key. | Defended |
| Read-only SQL injectionLeaks ciphertext, not plaintext. | Defended |
| Client claims you altered the contract after signDatabase trigger blocks edits to body / hash / signing fields. Body hash detects any tamper. | Defended |
| Tampering with a signed contract via SQLDatabase trigger blocks edits and deletes. | Defended |
| Client claims the contract didn’t exist on date XOpen until RFC 3161 trusted timestamping ships (roadmap). Self-stored hash + system clock alone do not independently prove when. | Open |
| Client signs from a VPN, NAT, or shared IPIP and UA captured + logged. Treated as corroborating signal, not identity proof. Device fingerprint adds an independent signal accepted by Visa CE 3.0. | Mitigated |
| Application host breach with environment accessAttacker has both key and decryption path. | Open |
| Logged-in user bypassing row-level securityEncryption does not replace access control. | Open |
IP address.Corroborating signal, not identity proof. VPN, NAT, shared WiFi, and mobile carrier-grade NAT all sever the link between IP and individual. We capture and log it because it’s asked for in processor evidence forms; we don’t treat it as a load-bearing identity claim.
User-agent string. Trivially spoofable. Useful as one piece of a transaction fingerprint, weak as identity proof on its own.
SHA-256 body hash. An integrity check. Proves the contract body hasn’t been edited since signing. Without an independent trusted timestamp, the hash cannot, on its own, prove whenthe document existed — the system storing the hash also controls its clock. RFC 3161 trusted timestamping is the fix and is on the roadmap (see below).
Device fingerprint.Canvas, fonts, timezone, screen, language. Visa Compelling Evidence 3.0 (effective April 2023) explicitly accepts a device ID/fingerprint as a “main evidence element” for blocking friendly-fraud disputes when matched against prior undisputed transactions. Captured at sign and at payment.
Trusted timestamp (roadmap).RFC 3161 countersignature from an independent Time Stamp Authority. Free TSA on Solo, qualified TSA on paid tier — eIDAS Article 41 carries a presumption of accuracy of date and time for qualified timestamps. Tracked transparently as a roadmap item.
Stripe / Visa CE 3.0 chargebacks (reason 10.4 — fraudulent, no authorization). High mechanical value when the device fingerprint, IP, or account identifier matches a prior undisputed transaction with the same cardholder. The dispute kit organizes these matches into the format Visa CE 3.0 asks for.
Stripe reason 13.1 / Mastercard 4853 — services not received. Delivery timestamps, signed-URL access log, and the signed contract map directly to the defense evidence processors ask to see.
PayPal seller protection (intangibles). Materially weaker for digital services regardless of evidence — PayPal’s policy for intangibles does not extend the same protections as it does for tangible goods. We surface what we have without overpromising.
Small claims and civil court.What wins these cases is a clean version of “signed contract + invoice + delivery proof + email thread.” That is exactly what the dispute kit assembles. Hash and IP are nice-to-have, not load-bearing.
Cross-border (sub-$10K invoices).Litigation is rarely economical at this size. Judgment recognition is a separate, harder problem — Hague 2005 isn’t universal. The realistic levers are the chargeback response and the delivery gate; PaidProof is built for both.
Click-to-sign is a Simple Electronic Signature (SES) under eIDAS, not a Qualified Electronic Signature(QES). SES is admissible everywhere we operate — US (ESIGN / UETA), EU (eIDAS), UK (ECA 2000), Canada (PIPEDA + UECA), Australia (ETA 1999). The equivalent-to-wet-signature presumption only applies at the QES level in the EU and UK. For EU contracts that legally require QES (some real-estate, some employment, some public-sector), use a dedicated QES provider; the upload-back path is on the roadmap so you can store the signed PDF inside PaidProof and reference it in the dispute kit.
We are not a notary. We are not a Time Stamp Authority (until RFC 3161 timestamping ships, and even then, the TSA is the independent third party, not us). We are not a court. We collect and structure evidence; we don’t adjudicate disputes.
The dispute PDF is not a guaranteed-win packet. Card networks favor the cardholder when evidence is evenly matched. The PDF is your strongest opening, not an outcome.
PaidProof is not zero-knowledge or end-to-end encrypted — the application server reads plaintext to render the contract for the client and to generate the dispute PDF. We are not SOC 2 attested. We are not HIPAA, PCI-DSS, or FedRAMP. Don’t put cardholder data, US healthcare records, or classified material into PaidProof.
GDPR Article 32 lists encryption of personal data as one of the appropriate technical measures. Combined with row-level security, append-only audit logging, per-tenant data isolation, and one-button export and account deletion, PaidProof’s posture covers Article 32 and Article 25 (data protection by design) for a small-team controller.
PaidProof is operated from Poland. A Data Processing Agreement is available on request to support@paidproof.app.
The /evidence page reasons through every field PaidProof captures, why we capture it, and what it does and does not prove — field-by-field, with primary sources cited.
Security reports go to support@paidproof.app. Acknowledged within one business day.
Last verified 2026-05-08.
Product analytics and ad attribution use cookies. Decline and we load neither — only the auth cookie that keeps you signed in. What we collect →