Simple or advanced: set the signature level per flow, not per account
Most products that embed signing have more than one flow that signs. A user accepts terms during onboarding, an account admin signs the first contract, a customer signs a mandate that moves money. When you move these flows off a seat or envelope tool, the signature level often came bundled with the plan: every flow got the same ceremony because the account had it. With IgniSign, the level is a choice you make per flow, and each signature bills at the level it used. The integrating developer's decision is which flow gets which level.
Where the level lives
The level is not an account setting. It comes from the signer profile you name when you create the signer, or when you describe the signer on a one-call signature request. One application can hold several signer profiles, so a single product can run simple signatures in one flow and advanced ones in another, with the same API calls and the same webhooks.
That makes the choice a line of code next to each flow, not a plan change. It also means the meter follows the choice: you pay per signature, at the level each request used, with no tier to upgrade when one flow needs more.
The three options as sold
- Simple electronic signature (email). The signer is identified by the email your product already knows. Five free per organisation per month, then €0.15 each.
- Advanced electronic signature with SMS authentication. The signer declares a name and confirms with a one-time code sent by SMS. It bills per signature, and the SMS is billed per country.
- Advanced electronic signature with identity check. The signer adds a second factor (passkey, TOTP, SMS, or corporate SSO where your organisation has it enabled) and one identity verification method: automated ID document and selfie verification, open banking, or SSN. Each check adds its own line.
None of these is the right one in the abstract. Each answers a different question your flow has about the signer.
Matching level to flow
Ask, per flow: what does the other side need to know about who signed?
If the answer is "the person who controls this account's email agreed", a simple signature fits. Terms acceptance, consents, internal approvals, a renewal signed by a user who is already logged in: these flows run at volume, and the simple level keeps them inside the product with a retrievable proof and no SMS or identity line.
If the answer is "the person also controls this phone", use the advanced level with SMS. It fits contracts with a counterparty you know by email and phone number, where a second factor ties the signature to a device.
If the answer is "we verified who this person is", add the identity check. It fits a higher-risk step: a mandate, an onboarding that must match a real person, a flow where your compliance team asks for identity evidence. Use it where that question is real, since every check is a billed line.
A layout that holds up
A typical embedding team ends up with two or three signer profiles:
simplefor consents and acceptances, usually the bulk of the volume.advanced-smsfor contracts with external counterparties.advanced-idfor the one or two flows where identity is the point.
Name profiles after the need of the flow, not after a customer tier. When product or legal changes the requirement for one flow, you switch that flow's profile and leave the others alone. For people who sign again at the same level, keep the signer you created under that profile: the registered second factor and any verified claims belong to that signer.
Test each profile in development first. Development never bills, so you can open each ceremony, finish it, and check the webhook and the proof before the SMS or identity lines can bill in staging or production.
The decision
Set the level per flow, through the signer profile, by asking what that flow needs to know about the signer. Use simple signatures where email control answers it, advanced with SMS where a phone factor does, and the identity check where a verified identity does. Because each signature bills at its own level, the high-volume flows stay inexpensive, and only the flows that need more pay for more.