Development, staging, or production: which environment meters what
You create an IgniSign application once, then you get three environments: development, staging and production, each with its own API keys. The integrating developer’s decision is which of those environments you use for which work, and what that choice costs when a signature request runs. The answer is not “everything is free until production.” It depends on the environment and on what the request does.
Three environments, one application
Each environment is a separate slice of the same application: its own keys, its own webhooks, its own signature requests. A development event must never move a production record. That is why webhook handlers should reject events whose appEnv does not match the environment they serve — the same discipline as checking the verification token before you change state.
So the first rule is organisational, not billing: use development for the loop that teaches your team the API, staging for a shared pre-production cut that looks like production, and production for live users. Mixing keys across those jobs is how test events unlock real accounts.
What development meters
Development never bills. Signature requests, seals and the rest of the signature path run without a charge on that environment. That is the place to open the embedded iframe or a BySide link, finish a signature, watch the callback update the page and watch the webhook update your record.
If your flow also uses SMS authentication or an identity-check step, run those paths in development first as well. You want the ceremony and the webhook shape right before any environment that can invoice you for those extras.
What staging meters
Staging is free for signatures and seals. It is not free for everything around them. SMS authentication and paid identity-check methods (automated ID document and selfie verification, open banking or SSN) can bill in staging when your request uses them.
That split is the decision point. If staging is your shared demo for product and legal, prefer signature levels that do not pull in paid extras until you intentionally test those paths. When you do need to exercise SMS or identity-check before production, treat staging as a controlled cost surface: know which requests will trigger those lines, and keep volume small.
Do not treat staging as a second free sandbox identical to development. It is closer to production in shape, with a narrower free zone on the signature itself.
What production meters — and the five free simples
Production is where pay-as-you-go applies for live volume. Simple electronic signatures (email) start with five free per organisation per month, then €0.15 each. The five free are an organisation meter across your apps, reset monthly — not a personal or per-app gift, and not a consumer offer. Advanced signatures with SMS authentication, and identity-checked flows, bill as sold when you use them.
A card is required once you go beyond the free simple-signature allowance in staging or production. Development stays usable without that step, which is why the activation path is: build and sign in development, confirm the webhook and proof retrieval there, then move keys to staging and production when the flow is ready.
A practical split for an embedding team
- Development: one-call signature request, embedded or BySide UI, webhook verification, proof fetch. Stay here until the screen and the backend agree.
- Staging: same flow with production-like data and webhooks pointed at a non-production backend. Add SMS or identity-check only when you need to validate those ceremonies, and expect those lines to bill.
- Production: live keys, live webhooks, live meter. Keep the five free simples for real low-risk consents if that fits the product; use advanced levels when the flow needs them.
The level of signature does not change which environment you pick. It changes what each environment charges when the request runs. SES on a low-risk consent and an advanced signature with SMS both belong in the environment that matches the audience — test users in development or staging, real users in production.
The decision
Use development when you need a free full loop. Use staging when you need a production-shaped cut and accept that SMS and identity-check can bill. Use production when real users sign, and plan for the organisation’s five free simple signatures each month before the €0.15 line. Separate keys per environment so a development webhook never moves a production record — then the meter follows the environment you chose on purpose.