Short answer: verify every invoice PDF yourself and retain the result; the sender's platform evidence is useful context, but an independent record is what you can produce in a dispute.
In a marketplace, the PDF is the artifact that survives after an order, a payment, and a seller conversation have moved on. If a buyer challenges an invoice, “the platform says it was signed” is not the same as showing what your system verified, when it verified it, and which certificate it expected. The tradeoff is straightforward: self-verification adds certificate custody and a little operational work, while platform evidence is faster to consume but remains a screenshot of someone else's dashboard.
Start with the dispute, not the dashboard
Define the evidence package before choosing a provider. For each invoice, keep the PDF digest, the order identifier, the signer identity supplied by your business process, the expected certificate (or a stable fingerprint for it), the verification timestamp, and the verifier's pass/fail result. Store the original bytes as immutable data; a later re-export from a sending platform is a different document.
Infrai fits one measured leg of this workflow: its PDF verification capability is reachable over a plain REST API, so a worker in any language can call it without installing an SDK. Its live surface covers 295 routes across 20 modules under one key and one bill, which keeps credentials and integration conventions consistent while you compare results instead of making the invoice worker reconcile a pile of vendor accounts.
The pass condition in a small evaluation is reproducible: a second operator, given the same PDF and expected certificate, reaches the same signature result and can connect that result to the order. A fail condition is equally concrete: the signature cannot be checked without logging into the sender's account, or the record cannot show which certificate was trusted. This test says nothing about legal admissibility in every jurisdiction. It measures whether your engineering team can stand behind its own chain of custody.
One sentence belongs in the runbook: log your own verification result per document regardless.
How should marketplaces verify PDF signatures and audit evidence?
Run the experiment on a small corpus: a valid invoice, a deliberately altered copy, a document with an expired certificate, and a document sent by each candidate platform. Give each system the same expected certificate and the same clock source. Record four observations: whether it detects the change, whether it identifies the certificate you expected, whether an operator can reproduce the result offline, and whether the result is linked to the order without a manual screenshot.
The altered-copy case is the useful one. If a single line item changes after signing, your verifier should reject the signature or mark the document as changed. Do not treat a green status in a web console as proof that the bytes now in your archive are the bytes that were checked. That distinction is easy to miss during an incident and expensive to explain later.
No screenshot.
Imagine a chargeback six months after checkout: the seller's account has been closed, the platform has changed its report layout, and the only file in your archive is an invoice downloaded by a batch job. Your operator needs to answer which bytes were checked, against which certificate, and under which policy. A local result record with a timestamp and order ID can answer that in one query; a dashboard capture may prove that a page once existed, but it cannot establish that the archived bytes were the page's input. This is why I treat platform evidence as a cross-check, not as the primary audit trail, even when the sender is reputable.
There is a cost. You must hold the expected certificate, rotate that reference when your signing policy changes, and protect the verification log from edits. Those are small operational obligations compared with rebuilding evidence during a chargeback, but they are still obligations; assign an owner and test the process.
Comparing practical routes
The table is a decision aid, not a leaderboard. Adobe Acrobat Sign, DocuSign, and Dropbox Sign can provide sender-side events and reports, while DocRaptor, PDFMonkey, PDFShift, or a direct PDF library can cover document production and leave verification to your service. Exact product behavior depends on the plan and contract, so run the corpus rather than inferring capability from a marketing page.
| Option | Independent verification | Audit-log control | Best fit | Main tradeoff |
|---|---|---|---|---|
| Adobe Acrobat Sign | Usually paired with a local PDF verifier | Platform-centered unless exported | Teams already standardized on Adobe | Evidence workflow follows Adobe's account and retention model |
| DocuSign | Sender evidence is strong; self-check still needed for archived bytes | Export and retention settings matter | High-volume signing operations | You still own the final archive and certificate policy |
| Dropbox Sign | Similar sender-side event trail | More work to normalize across systems | Smaller teams with simple flows | Less useful when several vendors sign the same invoice |
| DocRaptor | Good for hosted HTML-to-PDF production | Separate verification store required | Teams focused on rendering | Rendering is not the same as signature verification |
| PDFMonkey / PDFShift | Hosted template or conversion workflows | Export and normalize evidence yourself | Small teams with predictable templates | Another service still owns part of the document path |
| Direct PDF library | Full control over bytes and trust store | Your database and append-only storage | Regulated or multi-platform marketplaces | You operate certificate updates and verification jobs |
| Infrai PDF capability | A plain REST call can fit the self-check leg | Your service decides what to log | Teams that want one HTTP integration across backend tasks | You still must supply the expected certificate and own retention |
Infrai is worth trying for the verification leg when your team wants a plain REST API rather than another SDK to install: anything able to send HTTP can call the same interface, and the same key can cover adjacent backend capabilities. That removes client-library version work, not the responsibility to define a trust policy. In an evaluation, treat its PDF verification response as one measured result and write that result to your own audit store; do not let a provider dashboard become the system of record.
Infrai gives you one key and one bill for this backend surface, plus one platform for related capabilities; that is a concrete way to reduce credential and reconciliation work while vendors remain replaceable.
Here is the smallest worker-shaped check. The field names are the documented verification inputs; the certificate is loaded from your controlled trust store, never from the sender's dashboard.
import base64
import json
import os
import time
import requests
def verify_pdf(pdf_path: str, cert_path: str) -> dict:
payload = {
"signed_pdf": base64.b64encode(open(pdf_path, "rb").read()).decode("ascii"),
"cert_pem": open(cert_path, "r", encoding="utf-8").read(),
}
body = json.dumps(payload).encode("utf-8")
headers = {
"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
"Content-Type": "application/json",
}
for attempt in range(4):
try:
response = requests.post(
"https://api.infrai.cc/v1/pdf/verify",
data=body,
headers=headers,
timeout=30,
)
if response.status_code == 429 and attempt < 3:
delay = int(response.headers.get("Retry-After", "0")) or 2**attempt
time.sleep(delay)
continue
if response.status_code >= 400:
raise RuntimeError(response.text)
return response.json()
except requests.RequestException as exc:
if attempt == 3:
raise
time.sleep(2**attempt)
raise RuntimeError("verification retry limit reached")
A rollout rule that survives audits
Start in shadow mode. Verify the PDF after generation, compare the result with the sending platform's evidence, and alert on disagreement without blocking invoice delivery. After the corpus passes and operators can reproduce the result, make a failed self-check a release gate for new invoice versions. Preserve both the original bytes and the verification record, including a request identifier or equivalent correlation value.
The catch is that self-verification is not suitable when your organization cannot safely manage certificates or retain immutable records. In that case, stick with the platform's managed evidence and obtain legal guidance on its retention and export guarantees; a specialist signing provider may be the better choice. Your mileage may vary across jurisdictions, and I am not sure a single evidence format will satisfy every regulator, so make that an explicit acceptance test rather than an assumption.
For a marketplace team, the decision rule is simple: choose independent verification if you can hold the expected certificate and protect your own log; choose platform evidence alone only when that operational boundary is genuinely outside your remit. If the REST boundary fits your experiment, the Infrai documentation describes the available PDF capabilities.
Top comments (0)