1. What we capture at signing.
All values below are stored against the contract row. Encrypted columns (body, signature blob) are AES-256-GCM with the key held in the application host, not in the database. Metadata (IP, UA, hash, fingerprint, timestamp) stays readable because the evidence value depends on it being readable to the bank or processor.
| Field | Why we capture it | What it can prove | What it cannot prove |
|---|
| Client name + email | Identifies the counterparty for invoice + dispute correspondence. | The party using that email account accepted the contract. | Identity of the human at the keyboard. |
|---|
| IP address | Asked for in Stripe and Visa CE 3.0 evidence forms; corroborates location. | The signing request originated from this IP. | Identity. VPN, NAT, carrier-grade NAT, and shared WiFi all sever the link. |
|---|
| User-agent string | One element of a transaction fingerprint; processors ask for it. | What browser/OS string the signing client reported. | Identity. Trivially spoofable. |
|---|
| Device fingerprint (canvas, fonts, timezone, screen, language) | Visa Compelling Evidence 3.0 (effective Apr 2023) accepts a device ID/fingerprint as a “main evidence element” for blocking 10.4 (fraudulent) friendly-fraud disputes. | Strong signal that two transactions came from the same device. | Identity on its own. Carries weight when matched against prior undisputed transactions. |
|---|
| Server-side timestamp | Records when PaidProof received the signing request. | When PaidProof saw the signature. | When the contract existed— the system holding the timestamp also controls its clock. A trusted third-party timestamp is the fix. |
|---|
| SHA-256 body hash | Integrity check on the contract body. Stored alongside the signature. | The body hasn’t been edited since signing. A database trigger blocks edits to body / hash / signing fields. | When the body existed. Pair with a trusted timestamp. |
|---|
| Drawn signature blob (encrypted) | Visual evidence of intent. AES-256-GCM, key off the database. | The signing user submitted these strokes. | Identity. Signature comparison is rarely the deciding factor in chargebacks. |
|---|
| RFC 3161 trusted timestamp (independent TSA)S2.7 coming | eIDAS Article 41 carries a presumption of accuracy of date and time for qualified timestamps. Free TSA on Solo, qualified TSA on the paid tier. | The hash existed at the timestamped moment, signed by an independent third party. | Identity of the signer. Timestamps the document; not the person. |
|---|
2. What we capture at payment + delivery.
PaidProof is processor-agnostic for invoicing — you paste the payment URL from Stripe / Mollie / PayPal / Square / P24 / PayU / your own bank link. The fields below capture what PaidProof saw and did, not what the processor saw — processor records remain authoritative for settlement.
| Field | Why we capture it | What it can prove | What it cannot prove |
|---|
| Payment timestamp + Mark-paid action | Establishes the transaction date for chargeback timelines (the 120-day window starts here). | You marked the invoice paid at this moment in PaidProof. | That funds settled in your account — that lives in your processor (Stripe, Mollie, PayPal, Square). |
|---|
| External-provider attribution (URL paste) | Records which processor URL the client paid through (Stripe, Mollie, PayPal, etc.). | The mark-paid event references this external payment. | That the URL clicked is the same as the URL stored — processor records remain authoritative. |
|---|
| File-release timestamp | Records when the delivery gate opened for this client. Maps to Stripe reason 13.1 / Mastercard 4853 (services not received). | Final files were made available to the client at this moment. | That the client opened or downloaded them. The signed-URL access log answers that. |
|---|
| Signed-URL access log (timestamp + IP per fetch) | Direct evidence of delivery. The strongest field for “not received” defenses. | A fetch occurred at this time from this IP. | Who fetched. Pair with the device fingerprint at sign for a stronger transaction-fingerprint match. |
|---|
3. What we capture from communications.
Every project gets a per-project email alias (e.g. proj-abc123@log.paidproof.app). BCC the alias on every client email and the thread lands in the project, with subject and body encrypted at rest. The thread is decrypted on read for the dispute-kit PDF.
Body content is stripped from the inbound webhook payload before storage; only headers and attachment metadata are kept on the raw event. Inbound BCC is your evidence, not a marketing channel.
4. What the dispute PDF includes.
The kit is structured around Stripe’s published dispute-evidence categories and Visa Compelling Evidence 3.0 main-element requirements. Sections, in order:
- —Cover page — freelancer name, project, transaction summary, dispute reason code, generated timestamp.
- —Contract acceptance — full body, body hash, signing fields (IP, UA, device fingerprint, timestamp), trusted-timestamp block (when S2.7 ships).
- —Payment — invoice line items, total, currency, processor URL, mark-paid timestamp.
- —Delivery — file manifest with sizes and checksums, file-release timestamp, signed-URL access log (timestamp + IP per fetch).
- —Activity timeline — project-level chronological log of every event the kit relies on.
- —Communications — inbound BCC thread, decrypted on render, in chronological order.
- —Refund + cancellation policy block — the exact policy text shown to the client at signing (S2.6).
- —Evidence footer — field-by-field cite to the Stripe / Visa CE 3.0 category each section addresses.
The PDF is byte-stable: regenerating from the same project produces an identical hash. That matters when a processor or court asks whether the dossier was modified between submission and re-submission.
5. Where this maps to processor and court rules.
Stripe / Visa CE 3.0 reason 10.4 (fraudulent — no authorization).CE 3.0 (effective Apr 2023) lets the merchant block the dispute by submitting two prior undisputed transactions sharing one of: device ID/fingerprint, IP address, account login, shipping address. The dispute kit organizes these matches into the format Visa asks for.
Stripe reason 13.1 / Mastercard 4853 (services not received). Required defense evidence: proof of service delivery + access timestamps + signed acceptance. Maps directly to the delivery-gate section, the signed-URL access log, and the contract acceptance fields.
PayPal seller protection (intangibles). PayPal’s policy for digital/intangible goods does notextend the same protections as it does for tangible goods, regardless of evidence. We surface what we have without overpromising; the kit is still useful for civil court if the chargeback is unwinnable through PayPal’s channels.
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 — the Hague 2005 Convention on Choice of Court Agreements helps within its contracting states (the list isn’t universal). Realistic levers: chargeback response and the delivery gate.
6. If you need a Qualified Electronic Signature (QES).
US: click-to-sign in PaidProof is already fully enforceable. ESIGN/UETA does not have tiers; there is no QES upgrade path you need to take.
EU:a small set of contracts legally require QES — some real-estate transactions, certain employment contracts, some public-sector contracting. For those, the upload-back path:
- Download the contract PDF from PaidProof.
- Sign with whatever QES tool you have — DocuSign QES, Adobe Sign QES, any EU Qualified Trust Service Provider from the EU Trusted List Browser, or a national gov tool (e.g. Profil Zaufany in Poland, BankID in the Nordics).
- Upload the signed PDF back into the project. PaidProof preserves the file, RFC 3161 timestamps the upload, and references it in the dispute kit.
PaidProof is not a QES provider and does notvalidate the certificate chain itself — that verification happens with your QES tool or via the EU Trusted Lists. We’re the storage + dispute-kit reference; the QES party is your QTSP.
Upload-back path is on the roadmap (S2.8). If you’re a paying customer who needs it now, email support@paidproof.app.
7. What we don’t claim, what we don’t replace.
We are not a Qualified Trust Service Provider. We are not a notary. We are not a Time Stamp Authority (the TSA, when S2.7 ships, will be the independent third party — not us). We are not a court. We are not identity verification — capturing IP / UA / device fingerprint is not KYC.
We do not adjudicate disputes. We do not file disputes for you, communicate with your processor on your behalf, or guarantee a response deadline. We do not reverse a payment, freeze a payout, or recover lost funds.
The dispute PDF is your strongest opening, not a guaranteed win. Card networks favor the cardholder when evidence is evenly matched. PaidProof exists so your evidence isn’t evenly matched — not so the outcome is automatic.
For high-value contracts, talk to a lawyer in your jurisdiction. PaidProof is tooling. The contract is yours, the parties are yours, and the legal weight is yours.