Types of Electronic Contracts Under Indian Law: Which Ones Hold Up and What Records You Need

An "electronic contract" covers everything from a Rs 500 crore outsourcing agreement signed with Digital Signature Certificates to the terms you accept by ticking a box on a checkout page. They are not equally easy to prove. This explainer sets out the main types, the Indian legal basis for each, the Stamp Act and personal-data points that get missed, and the records that matter when a dispute comes. Position as of October 2026.

The legal baseline

Three provisions do most of the work:

• Section 10A, IT Act, 2000: where a contract is formed through electronic means, it "shall not be deemed to be unenforceable solely on the ground" that electronic form was used. This is the general enabling rule for every type below.
• Section 10, Indian Contract Act, 1872: an electronic contract still needs the ordinary ingredients, free consent, lawful consideration and object, and parties competent to contract.
• Section 5, IT Act, 2000: where a law specifically requires a signature, an electronic signature affixed in the prescribed manner satisfies it. Not every electronic contract needs a signature; most do not. But where one is required, this is the route.

Evidence sits on top: since 1 July 2024, electronic records are admitted under sections 61 and 63 of the Bharatiya Sakshya Adhiniyam, 2023, with a certificate under section 63(4) identifying the record and the device that produced it.

Type 1: Agreements executed with electronic or digital signatures

The highest-assurance form. A digital signature under section 3 of the IT Act uses asymmetric cryptography and a Digital Signature Certificate issued by a licensed Certifying Authority. An electronic signature under section 3A uses a technique listed in the Second Schedule, which since 2015 has included the Aadhaar e-KYC based eSign.

Use for: MSAs, leases, employment contracts, vendor agreements, anything that will be stamped or may be litigated. Record to keep: the signed file, the signature certificate details, timestamps and the audit trail of the signing session.

Type 2: Clickwrap agreements

The user sees the terms (or a clear link to them) and takes an affirmative action, usually ticking "I agree" or clicking a clearly labelled button, before proceeding. Clickwrap is the standard form for SaaS subscriptions, app sign-ups and online marketplaces.

Indian courts have not laid down a single clickwrap rule, but the Supreme Court's approach to electronic formation is permissive: in Trimex International FZE Ltd. v. Vedanta Aluminium Ltd. (22 January 2010) it held a contract concluded through email exchange binding, stating that "the mere fact that a formal contract has to be prepared and initialed" does not affect acceptance. For clickwrap, the practical test is whether you can show the terms were presented, the action was unambiguous, and which version applied.

Record to keep: the exact terms version, the timestamp, the account or device identifier, the IP address, and the screen the user saw.

Type 3: Browsewrap

Terms are posted by a link in the footer; use of the site is treated as acceptance, with no affirmative act. This is the weakest form. The user may never have seen the terms, so proving consent under section 10 of the Contract Act is hard. Treat browsewrap as notice of your policies, not as a contract you will enforce against a consumer.

Type 4: Shrinkwrap and in-box terms

Terms enclosed with a physical product (software packaging, hardware) that take effect on opening or use. Rare now; where used, back them with a clickwrap on first activation.

Type 5: Contracts formed by email or messaging

An exchange of emails or messages that settles the essential terms can be a binding contract even without a signed document; Trimex is the leading Indian authority. The risk runs both ways: an informal "confirmed, go ahead" from a manager can bind the company. Set an internal rule that commercial terms are confirmed only through the contract workflow.

The two points most e-contract guides skip

Stamp duty applies to electronic instruments. The Indian Stamp Act, 1899 charges duty on instruments, and an e-signed agreement that falls within a chargeable article (a lease, an agreement of a type the state schedule lists) must be stamped, under section 17 before or at execution, or it is inadmissible under section 35 until duty and penalty are paid. E-stamping and e-signature are designed to be combined; clickwrap terms are generally not chargeable instruments, but check the state schedule for agreements of the type you are forming.

Consent to terms is not consent to data processing. Under section 6(1) of the DPDP Act, 2023, consent to personal data processing must be "free, specific, informed, unconditional and unambiguous with a clear affirmative action". Bundling a privacy consent into the same checkbox as the terms of service is the opposite of specific. Keep the contract acceptance and the data consent as separate actions in the flow. These provisions commence on 13 May 2027 under the DPDP Rules, 2025, but flows built now should assume them.

Sample acceptance language

For a clickwrap flow, language of this kind, with the checkbox unticked by default, is clear:

"I have read and agree to the [Terms of Service] (version 4.2, effective 1 September 2026)."

And, as a separate control:

"I consent to [Company] processing my personal data for [stated purpose] as described in the [Privacy Notice]."

For a signed agreement, the execution block should state the place of execution (for stamp purposes) and the signature method used.

Choosing the type

Where Legatio fits. Legatio is designed for Type 1: executing agreements with electronic signatures, dispatching them to recipients, tracking their status and keeping the executed version with its audit trail. The guidance on the other types applies to your product and website flows independently.

Position stated as of October 2026. General information, not legal advice.