Verify consent with TrustedForm and Jornaya
Claim TrustedForm certificates and authenticate Jornaya tokens at ingest, so you can prove consent to a buyer or a regulator.
This article shows how to turn on consent verification so every lead carries proof the consumer agreed to be contacted. Buyers in regulated verticals will not pay without it.
Both services run automatically during ingest, and both cost money per call, so where they run matters commercially as well as technically.
What each service does
TrustedForm records a certificate of the consumer's session on your lead form. The certificate exists the moment the form is submitted, but it expires unless someone claims it. Claiming turns a transient recording into consent proof you own and can show a buyer or a regulator later.
Jornaya issues a LeadiD token at the moment of submission. Authenticating it confirms Jornaya really issued it, that it has not expired, and that it is not being replayed.
When they run
Both run on the post only, never on the ping, and this is fixed behaviour rather than a setting. On a ping the campaign usually does not require email, phone or the certificate field yet, so a claim there would match nothing, would still be billed, and would block the post claim that could have matched.
A lead is only checked once. If a claim or authentication already produced a settled answer, success or failure, a later post or a redistribute reuses it instead of paying again. A call that never completed does not count as settled, so a timed-out check is retried rather than stuck.
Prerequisites
- A TrustedForm API key, from the Settings tab of your ActiveProspect account
- A Jornaya account code, and an audit key if your account is provisioned for audit-enriched responses
- A campaign whose fields include somewhere to carry the certificate URL and the token
Turn it on
- Open Integrations from the sidebar.
- Open the TrustedForm row and enter your API Key. Open the Jornaya row and enter your Account Code, plus the Audit Key if you have one.
- Open the campaign, go to its Integrations tab, and enable the provider there.
- Open the override modal on that campaign and check the settings below. Every setting is campaign-overridable.
- Send a test lead with a genuine certificate URL and LeadiD, then read the result on the lead.
A provider configured globally does nothing until it is also switched on for a specific campaign. Both the global integration and the campaign link must be active.
TrustedForm settings
| Setting | Default | What it does |
|---|---|---|
| Certificate URL field | trusted_form_cert_url |
Which lead field holds the certificate URL |
| Fingerprint fields | email to email, phone to phone | Which fields are sent for matching against the certificate |
| Require fingerprint match | Off | Reject when none of the sent fingerprints matched |
| Require certificate | Off | Reject leads with no usable certificate URL |
| Required scan terms | Empty | Consent language that must appear in the page snapshot |
| Forbidden scan terms | Empty | Language that must not appear |
| Vendor field | Empty | A field sent as the claim's vendor, for example the traffic source name |
| Timeout (seconds) | 5 | How long to wait before the claim counts as incomplete |
| On provider error | Accept | What to do when the check could not be run at all |
Fingerprint fields
TrustedForm can confirm the email and phone on the lead are the same ones typed into the form it recorded. That is the difference between "a consent record exists" and "a consent record exists for this consumer", and it is what a careful buyer is paying for.
The mapping has two columns. The left is the TrustedForm parameter, the right is the field on your campaign. It ships mapping email to email and phone to phone, which is right for most campaigns and wrong for any campaign that names its fields something else. Point the right column at your real field names.
A wrong mapping fails silently at the provider, because TrustedForm answers success either way. Every claim therefore records what it actually sent, so an empty sent list on a lead that clearly has an email is the signature of a mismapped field.
Deleting every row means "claim the certificate but match nothing", which is a legitimate choice. A campaign override replaces the whole mapping rather than merging it row by row.
Scan terms
Scan terms search the recorded page snapshot for wording. Required terms are consent language you need present, such as your disclosure. Forbidden terms are language that must not appear, such as prize or sweepstakes wording that would undermine the consent.
There is no separate switch. With no terms configured the check cannot fire, and configuring a term is itself the statement that you want it enforced. A lead that misses a required term, or carries a forbidden one, is rejected.
Jornaya settings
| Setting | Default | What it does |
|---|---|---|
| LeadiD token field | jornaya_lead_id |
Which lead field holds the token |
| Require token | Off | Reject leads with no usable token |
| Timeout (seconds) | 5 | How long to wait before the call counts as incomplete |
| On provider error | Accept | What to do when the check could not be run at all |
A token Jornaya reports as not authentic rejects the lead.
Junk values are treated as missing
A field holding something that could never be a certificate or a token counts as empty. A placeholder such as a landing page URL or the literal text example_value is not consent proof, so it does not trip the checks that exist to demand consent proof.
A certificate URL must be a real TrustedForm certificate address, and a LeadiD must be a 36-character token. Screening these locally also avoids paying for a call whose only possible answer was "malformed".
The consequence operators ask about most: with Require certificate off, a lead carrying junk in the certificate field is skipped rather than rejected. With it on, that lead is rejected and the reason says the value is not a certificate URL rather than claiming the field was empty.
When the provider is the problem
There is a difference between "this lead failed the check" and "we could not run the check". An expired certificate is the lead's problem. A timeout, a server error, a rejected API key, or an unfunded account is not.
On provider error decides what happens on that second kind. It defaults to accept, which matches every other check in the pipeline: an outage on a service you depend on should not cost you traffic. Set it to reject when your compliance posture requires that nothing ships without verified consent, accepting that an outage will then stop your traffic until it clears.
Failures caused by the lead always reject regardless of this setting. When a provider outage does reject a lead, it is filed under Consent provider unavailable in the technical group, so an outage never shows up in your reporting as a bad traffic source.
What lands on the lead
Each check writes its result onto the lead as enriched fields, prefixed per provider. They are merged before filters run, so filters, distribution steps and buyer payload mappings can all use them with no special syntax.
TrustedForm writes the outcome, the reason, whether fingerprints matched, which were sent and which were missing, any scan terms that failed, and a masked certificate URL. That masked URL is the durable, shareable form of the claimed certificate, and it is what you hand a buyer as proof.
Jornaya writes the outcome, whether the token was authentic, the reason, and the transaction id.
The same fields appear in the campaign field list, the filter rule builder, and the postback token list.
Testing a campaign
The buyer test modal has an Integration checks panel with a checkbox per check. TrustedForm and Jornaya are unticked by default on every flow, because a test that silently claimed a real certificate would consume one of its limited claims. Tick them deliberately when the consent path is what you are testing.
The generated mock payload fills unknown fields with placeholders, which are correctly treated as "no certificate" and "no token". Paste a genuine certificate URL and LeadiD into the payload editor to exercise the real path.
Expected result
A test lead with a genuine certificate comes back with a successful outcome and a masked certificate URL on the lead. The Usage tab under Integrations shows one row per call with its request, response, response time, and outcome.
Troubleshooting
- The sent fingerprints list is empty on every lead. The mapping still points at
emailandphonebut your campaign names them differently. Repoint the right column. - Fingerprints never match. The mapped fields hold different values than the consumer typed. Confirm the mapping, then decide whether a mismatch should reject at all.
- Everything rejects the moment Require fingerprint match is switched on. There are no rows in the mapping, so nothing is sent and nothing can match. Add at least one row, or leave the setting off.
- TrustedForm returns a payment error. The account is inactive or out of funds. That is a provider fault, so leads still pass unless you set On provider error to reject.
- Certificate claimed too many times. Expected once a certificate has been claimed. Normal reposts reuse the settled answer rather than re-claiming.
- Checks never run. The global integration is on but the campaign link is not, or the lead's country is not supported. Both providers cover the United States and Europe.
- Checks skipped on a ping. Working as designed. Look at the post leg.
Frequently asked questions
Comments
No comments yet — be the first to share your thoughts.