What you hold

Two surfaces produce evidence, and they answer to different people. Choosing between them — or running both — is the main integration decision, so it is worth being precise about what each one leaves you holding.

	Driven by	You get an artifact
Certified consent	You	On every submission where the visitor ticks your box
Share button	The consumer	Only when the consumer approves the share

Exactly what lands, in every case

The SDK never ticks a consent box — it skips every checkbox, radio and password field when filling — so approving a share and agreeing to your terms are two separate acts by the visitor. That gives four outcomes, and they are worth knowing precisely:

Visitor	You hold
Approves the share and ticks your box	Both: a fingerprinted share (live fields, duration, consumer.updated.*) and a certificate with a public verification page
Approves the share, leaves your box unticked	The share only — fingerprint, share.created/share.redeemed in the audit chain, share.created event and webhook. No certificate.
Ignores the button, ticks your box	The certificate only — verification page, evidence pack, consent.certified in the audit chain, external anchor
Ignores the button, leaves your box unticked	Nothing

That last row is not a defect. No consent was given, so there is nothing to certify and nothing to record. If you need an artifact on every lead, make your consent checkbox required — then the fourth row cannot occur, and every submission produces at least a certificate.

The two artifacts are not equivalent

Worth stating plainly, because it decides which one you rely on in a dispute:

• A certificate is publicly verifiable. Anyone with the URL can check it — no account, no API key, no involvement from you or us — and an evidence pack verifies offline against an independent implementation.
• A share is auditable, not publicly verifiable. It carries a fingerprint and is hash-chained into the audit log, whose head is checkpointed into an separately operated ledger every fifteen minutes — so tampering with it after the fact would have to survive that. But there is no public page a third party can open, and no evidence pack.

External anchoring is deliberately a chain-level guarantee, not a per-object one. Its job is to let anyone prove our audit chain has not been rewritten, not to notarise each individual record. Checkpointing the head covers every entry beneath it at once, which is why anchoring is fail-open per event: it must never sit between a person and their consent.

So the Share button is the better source of data. Certified consent is the better source of proof. If a carrier or regulator will one day ask you to substantiate a consent, that is the one to have.

Run both on one form

They are independent instances — one <script> tag each — so a single form can carry both:

<!-- Seals every submission that ticks the box -->
<script
  src="https://cdn.pryvc.com/v1/pryvc.js"
  data-client-id="pc_your_client_id"
  data-mode="consent"
  data-purpose="Discuss coverage options"
  data-checkbox-selector="#agree"
  data-disclosure-selector="#disclosure"
></script>

<!-- Offers the consented path to anyone who wants it -->
<script
  src="https://cdn.pryvc.com/v1/pryvc.js"
  data-client-id="pc_your_client_id"
  data-fields="first_name,last_name,email,phone"
  data-purpose="Discuss coverage options"
></script>

With the checkbox marked required, every submission produces at least a certificate, and the ones where a consumer chose to share produce both. What you hold stops depending on a stranger’s enthusiasm for our product — which is the point of running the two together.

There is no event for a consumer who declines

If someone opens the consent sheet and closes it, the SDK emits a local pryvc:closed event in that browser and stops. Nothing is sent to us, nothing is recorded, and no webhook fires. You can listen for closed to adjust your own interface, and that is all it is for.

This is deliberate, for two reasons.

A record about someone who declined is not evidence, it is surveillance. Their only interaction was refusal. Manufacturing a durable record of it — attached to an identifier, delivered to a business — is the behavior this product exists to argue against. We are not going to do it on our own surface.

Knowing about a decline requires knowing about the visit. The SDK makes no network request until a person acts: not on page load, not on render, not on close. That means embedding PRYVC cannot turn us into a third-party tracker on your site, and that property is worth more than decline analytics would be.

Why this leaves you better off, not worse

The instinct is that evidence you can produce unilaterally is stronger, because it does not depend on anyone else. It is the reverse.

A record you generated yourself, asserting that someone agreed, is what every CRM already contains: a row saying consent = true, a page that has since changed, and your word for it. That is precisely what gets disputed, and it loses.

A certificate is worth something because a person acted, we sealed what they saw at that moment, the fingerprint commits to all of it, and a carrier or a regulator can verify it without asking you and without asking us. That property comes entirely from the consumer having driven it. Weakening the link to make the artifact easier to produce would make it worth less, not more.

So: use certified consent when you need something in hand on every submission. Add the Share button when you want fresher data and a consent you did not have to administer. Do not plan reporting on people who said no — we have not given you the means to, on purpose.

Questions your customers may ask about this — including what we refuse to record and why — are answered at docs.pryvc.com/faq.