Counter-Signatures

Counter-signatures let you enforce a two-party signing flow on a waiver. After the customer signs, the submission is held in a pending state until an admin or a user with the waivers:approve permission co-signs on behalf of your company. Only then is the customer emailed a copy of the both-signed document.

This is useful for waivers that require a witness, a manager's acknowledgement, or any "in the presence of" language that legally needs a second signature from your side.

When to use this

• Witness requirements. The waiver text reads "signed in the presence of an authorized representative of {Company}" and you need an actual person to attest to it.
• Owner / manager approval. Liability releases where a manager needs to acknowledge the customer's signed disclosures before the booking proceeds.
• Document review gating. You want a human to eyeball every signed waiver (matching name to the booking, checking that the signature isn't blank, etc.) before the customer gets their confirmation.

If none of these apply, leave the toggle off. Waivers without counter-signature behave exactly as they always have — the customer signs, the email goes out, done.

Enabling on a waiver

1. Open the waiver from Dashboard > Waivers and click the Settings (gear) icon in the editor header.
2. Scroll to Require Counter-Signature and check the box.
3. Click Save Properties.

Once enabled, all new customer submissions on that waiver will land in the pending queue instead of being treated as complete.

Who can counter-sign

• Administrators can always counter-sign and reject — admin status bypasses the permission check.
• Other users need the waivers:approve permission. Grant it from Dashboard > Company > Users by editing a user and checking the Approve action under the Waiver Approval feature.

You can grant waivers:approve independently of the existing waiver-management permissions, so the people who design waivers don't have to be the same people who counter-sign them.

The pending queue

When a customer signs a counter-signature-required waiver, the submission appears in the Pending Counter-Signatures section at the top of that waiver's detail page in the dashboard. The waivers list page also shows a top-of-page banner with the company-wide pending count, so approvers can see at a glance whether there's work waiting.

Each pending row shows:

The queue refreshes automatically when you return to the dashboard tab after counter-signing, so completed rows disappear without a manual refresh.

Counter-signing

1. Click Counter-sign on the pending row. A new tab opens in the Resytech signing app.
2. Review the customer-signed PDF rendered inline. You're seeing exactly what the customer submitted.
3. Enter your printed name. It defaults to the name on your dashboard account but you can edit it — the legal record will show whatever you enter here.
4. Draw your signature in the signature pad.
5. Click Submit counter-signature.

Once you submit, the server:

1. Loads the customer-signed PDF from cloud storage.
2. Appends a new "Counter-Signature" page with your signature image, printed name, the counter-signed date, and a verification metadata block (your user id, IP, browser fingerprint, and a cryptographic hash).
3. Cryptographically re-signs the combined document.
4. Stores the both-signed PDF as a separate artifact in cloud storage. The customer-only PDF is preserved at its original location, untouched.
5. Transitions the submission status to Counter-Signed.
6. Emails the customer a copy of the both-signed PDF (if the waiver's Email Copy to Customer setting is on).

The customer-only PDF and the both-signed PDF are both retained — the customer-only PDF is the immutable legal record of customer consent at the moment of signing, while the both-signed PDF is the final distribution copy with both parties' signatures cryptographically bound.

Rejecting a submission

If a customer's signed waiver isn't acceptable (wrong name, blank signature, doesn't match the booking, etc.), you can reject it instead of counter-signing.

1. Click Reject on the pending row.
2. Enter a reason in the modal. This is required and capped at 2,000 characters.
3. Click Reject Submission.

The customer is emailed the reason verbatim, the submission transitions to Rejected, and any outstanding counter-sign link for that submission is invalidated. Rejection is final — the customer would need to re-submit a fresh waiver if they still want to sign.

What customers see

• Pending state: The customer experiences signing exactly as they always have. They sign, see the success page, and leave. They do not receive the email copy at this point — it's held until you counter-sign.
• After counter-sign: The customer receives their normal "Your signed waiver" email, but the attached PDF includes both signatures (theirs on the original pages, yours on the appended counter-signature page).
• After reject: The customer receives an "Action needed" email with your reason in a highlighted block. The original signed PDF is preserved server-side for audit, but the customer is not sent a copy.

Race conditions and re-issuing links

The counter-sign links are short-lived and single-use:

• Lifetime: 24 hours from issuance.
• Single use: Once a counter-sign is submitted, the link is permanently consumed.
• One active per submission: Issuing a new link automatically revokes any prior outstanding link for that submission.
• Status-bound: If the submission is rejected or counter-signed (e.g., by a different operator) while you hold a link, your link is invalidated and the signing app shows a friendly error.

If two operators try to counter-sign the same submission at the same time, the database-level concurrency check ensures exactly one succeeds — the other receives a clear "already acted on" message and the dashboard refreshes.

If your operator account is deactivated after you've been issued a link but before you use it, the link stops working immediately. The dashboard admin can re-issue a new link to a different active operator.

Audit and verification

Both PDFs (customer-only and both-signed) include cryptographic signatures and metadata blocks suitable for downstream verification:

• Customer-side metadata: IP, user agent, browser fingerprint, audit log of field interactions, submission timestamp, data hash.
• Operator-side metadata: Counter-signer user id and email, IP, user agent, browser fingerprint, counter-signed timestamp, the token id used.

Both metadata blocks are hashed with SHA-512 and embedded in the PDF signature dictionary, so any post-hoc tampering with the visible document is detectable.

Related How-To Guides

• Counter-Sign a Waiver
• Track Waiver Submissions
• Download Signed Waivers