From simple signature requests to complex workflows, Universign’s Transactions service is designed to help you and your customers sign documents electronically in the easiest and most compliant way.
Our Transaction API has been designed to offer the most flexible configuration on your side. Transactions are fully dynamic, which allows you to make updates even if you have already sent your transaction. For example, you can add additional documents or signers and modify multiple parameters while your transaction is live.
Only 3 parameters are mandatory to send a transaction request but you can set multiple options depending on your workflow needs.
General settings
Transaction name
You can set a custom name for your transaction. The default name is the transaction ID.
Transaction language
You can choose the language of the transaction, emails and SMS sent to participants. Supported languages are:
- Bulgarian (bg)
- Catalan (ca)
- Dutch (nl)
- English (en)
- French (fr) - the default language
- German (de)
- Italian (it)
- Polish (pl)
- Portuguese (pt)
- Romanian (ro)
- Spanish (es)
Transaction expiration
The expiration of your transaction can be configured on your side by setting either an expiration date or a duration.
Mandatory settings
Transaction documents
Required
You must add at least 1 document (and up to 20) to your transaction. We accept PDF, Word and images as input format in a maximum size limit of 25MB for each document. The output document is always a PDF. By default, the document name is the file name but you can set a different one on your side.
Document fields
Required
You must create at least 1 field in your document, except if your document already contains built-in fields. Depending on the type of field you create, the participant will be requested to sign the document or simply read it. If you want the document to be signed, you can also specify if you want the signature to be visible on a document page or not (visit add a field for more details). Note that whether the participant signed or simply read the document, whether the signature is visible or not, the technical information of the operation is always displayed in Adobe’s signature panel.
Note that a transaction can hold a maximum number of 50 participants.
Signer or Seal
Required
The signer is the physical person who signs or reads the document. The seal is the moral person who signs the document. The signer is identified by an email address and the seal by a seal ID.
Additional settings
Custom consents
It is possible to add custom consents to your documents, which can be different for each participant. Consents will materialize as checkboxes for the participant to accept before signing the document.
Alternate participants
If a document can be signed by several persons indifferently, it is possible to assign multiple emails to one signature field. The first person who signs closes the task. The same option applies to reviewers.
Reviewer
You can request the documents of a participant to be validated by someone prior to signature, by adding a reviewer. The reviewer has the possibility to leave a private message for the review recipient. A reviewer can validate documents for several recipients.
Workflow mode
You can specify an order between the participants of your transaction; whether parallel, sequential or both. Default mode is parallel. Note that a reviewer is always positioned before the recipient of the review. This means that even if the reviewer is also a signer, he cannot be positioned after the recipient.
Carbon copies
You can request the documents to be forwarded to someone once they are signed. The person added in copy will receive a link by email to download the signed documents.
Participant settings
Participant name
You can set the name of signers and reviewers.
Mobile number
You can specify the expected mobile number of a participant, which will be used as authentication means for signing.
Invitation email
You can activate or deactivate the invitation email and customize its content.
Automatic reminders
You can schedule automatic reminders and customize the content. There must be a minimum of 24 hours between each automatic reminders. It is also possible to send manual reminders via the web application, with no minimum time between each.
Inactivity alert
You can be choose to be notified if a participant has not completed the requested action within the period of your choice.
Signature level
Choose a minimum signature level for each participant, among simple signature and advanced signature with a certificate. If a participant already owns a certificate, Universign will upgrade the signature level for free.
Document captures
You can request participants to provide supporting documents directly within the signature workflow. These documents are timestamped and added to the transaction with the signed documents.
Transaction access
Metadata
Metadata are helpful to help you search for your transactions easily.
Folders
Transactions are sorted by folders so that only allowed members can access them. Upon creation, a transaction is placed in a default folder but you can specify a folder of your choice.
Privacy
If you make your transaction private, it will not be visible to your co-members in their dashboard, even if they have access to the folder in which is placed the transaction . By default, transactions are public within a folder.
Transaction lifecycle
From the moment it is created until its termination, a transaction undergoes different states: Draft, Started, Paused, Cancelled, Closed, Completed, Archived and Expired.
Draft
A transaction is created in draft until it is sent. A transaction can remain in draft for 7 days. During this time, all parameters can be edited. Draft transactions are automatically cancelled after 7 days if not started.
Started
Once the transaction is started, documents are ready to be processed by the first participants in queue. A started transaction can be updated if modifications do not affect tasks already completed by participants. For example, you cannot delete a field that has already been signed but you can add a new field or a document, or add a new participant or request a new task for a participant who has already completed his/her action. Because Universign transactions are dynamic, all modifications are immediately effective unless you pause the transaction before you update it. Once it is started, a transaction has a maximum lifetime of 60 or 180 days depending on your workspace configuration. If not completed after that time, it expires.
Paused
When a transaction is paused, you can edit it with no immediate effect. Modifications will be effective when you restart the transaction. While the transaction is paused, participants cannot complete any of the required actions on the signature page and do not receive notifications.
Note that pausing a transaction does not impact its expiration: the countdown still runs normally. A paused transaction will therefore expire if not restarted after the allowed duration.
Cancelled
A cancelled transaction can no longer be edited, and partially signed documents cannot be retrieved. If a transaction was in draft state before cancellation, it is permanently deleted after 24 hours. If it was started or paused before cancellation, it is permanently deleted after 60 or 180 days depending on your workspace configuration.
Closed
A transaction is closed when all participants have completed their actions. Closed transactions can no longer be edited and signed documents can not be retrieved yet. Once a transaction is closed, the Long Term Validation (LTV) is performed, and the transaction is completed. This operation usually takes a fraction of a second.
Expired
By default, a transaction expires if not completed within 14 days after it is started, but you can set the expiration to a maximum of 60 to 180 days, depending on your workspace configuration. However, you can manage the transaction expiration by setting its duration or expiration date (equaling 2 months maximum from start date). Note that expired transactions remain in the system for 60 days before they are permanently deleted. An expired transaction can no longer be edited, and partially signed documents cannot be retrieved.
Completed
A transaction is completed when all documents have been LTV-extended and archived. A completed transaction can no longer be edited. Signed documents and attestations are now available for retrieval. A completed transaction can be retrieved via the API endpoint /transactions/transaction_id and displays in your transactions dashboard for 60 days.
Archived
Once completed, a transaction is immediately archived. An archived transaction can no longer be edited. It can be retrieved via the API endpoint /archives/transaction_id and is available in your archives dashboard. Note that our qualified preservation of archives is included in our Transaction service.
Transaction follow-up
Via the Watcher option, it is possible to appoint workspace members who should be notified of the transaction lifecyle.
Signed documents
Once the documents are signed, signers receive an email with a link to download them. A signature attestation is always provided and contains information about the signature operation of the signer and co-signers.
Dynamic updates
When a live transaction is updated, the signature page updates accordingly, and the participants performing their action on the signature page are notified instantly if they are concerned with the changes.
Note that a transaction is fully editable for as long as your requests are coherent with the signature flow (for example, once a participant signed a document, you can no longer change the document’s name or the signer’s name).
We recommend that you pause the transaction before editing it.
Instant messaging
Participants can contact you instantly via the chat box on the signature page if they notice a problem with the document or have any question for you. You can automate your responses and decide what to do with the transaction, either manually, or automatically with the use of webhooks.
Signature refusal
A signature refusal (or any refusal from the participant) does not cancel the transaction automatically. When a participant refuses the documents, you are notified and can decide what to do with the transaction, manually or automatically with the use of webhooks.
