Verification, e-Stamp & e-Sign Service Terms

1.1 These Verification, e-Stamp & e-Sign Service Terms (“Service Terms”) govern the use of verification, e-Stamp, e-Sign, electronic documentation and related services made available through the StampMitra Developer Platform and APIs.

1.2 These Service Terms form part of the contractual framework governing the Developer’s use of StampMitra Services.

1.3 These Service Terms must be read together with the StampMitra Developer Terms of Service, Developer Privacy Policy, Data Processing Addendum, API Acceptable Use Policy, API Security Policy, API SLA & Service Availability Policy, Billing, API Credits & Refund Policy, Third-Party & Underlying Services Policy, and API Versioning, Suspension & Deprecation Policy, as applicable.

1.4 These Service Terms do not replace applicable legislation, governmental rules, regulatory requirements, state-specific requirements, judicial orders, or requirements imposed by an authorised authority.

2.1 These Service Terms constitute binding contractual terms between BANI GLOBAL INDUSTRIES LLP (“StampMitra”, “we”, “us” or “our”) and the Developer (“Developer”, “you” or “your”) to the extent the Developer accesses or uses the applicable Services.

2.2 By enabling, accessing, integrating, calling, or otherwise using a Service, the Developer accepts these Service Terms.

2.3 Where a specific commercial agreement, Enterprise agreement, order form, or written service schedule expressly applies to a particular Service, that document may supplement these Service Terms.

2.4 In case of conflict, the order of precedence stated in the applicable Developer Terms of Service shall apply unless an applicable written agreement expressly provides otherwise.

3.1 “API” means an application programming interface made available by StampMitra.

3.2 “Authorised Source” means an authorised government, regulatory, institutional, verification, data, service, or other external source from which information or service functionality may be obtained.

3.3 “Developer” means an individual, freelancer, consultant, organisation, business, institution, or other eligible person or entity using StampMitra Services.

3.4 “Developer Application” means software, website, mobile application, system, workflow, integration, or other application operated by the Developer.

3.5 “Document” means an electronic or physical document submitted, generated, processed, signed, stamped, verified, or otherwise handled through the Services.

3.6 “e-Stamp” means an electronic or digitally represented stamp instrument or stamping service made available through applicable systems and authorities.

3.7 “e-Sign” means an electronic signing functionality made available through an applicable authorised electronic-signature system or service.

3.8 “End User” means an individual or entity whose information, document, signature, identity, transaction, or other data is processed through the Developer Application.

3.9 “External System” means any system, infrastructure, service, authority, data source, verification system, payment system, communication system, or other third-party system used in connection with a Service.

3.10 “Service” means any verification, e-Stamp, e-Sign, document, identity, transaction, or related functionality made available through StampMitra.

3.11 “Underlying Service Provider” means a third-party service provider, authorised source, external system operator, infrastructure provider, or other external party used by StampMitra to facilitate or complete a Service.

3.12 “Verification” means an identity, information, document, status, record, eligibility, or other verification transaction supported by the applicable Service.

3.13 “Verification Data” means information submitted or generated for a Verification request.

3.14 “Stamp Duty” means any stamp duty, levy, charge, fee, surcharge, or other amount imposed under applicable law or by an authorised authority in relation to stamping.

3.15 “Signer” means a person who is requested or authorised to execute an electronic signature.

3.16 “Signature Transaction” means a transaction involving an e-Sign or other electronic-signature process.

3.17 “Transaction” means a request submitted through a Service, whether completed, failed, rejected, cancelled, pending, expired, reversed, or otherwise processed.

4.1 StampMitra operates technology infrastructure that facilitates, orchestrates, routes, processes, and integrates certain services.

4.2 StampMitra may use Underlying Service Providers, Authorised Sources, External Systems, government systems, regulatory systems, technology providers, verification systems, payment systems, or other third-party infrastructure.

4.3 StampMitra is not necessarily the originating authority, statutory authority, issuing authority, government department, registrar, notary, Certifying Authority, electronic-signature authority, identity authority, or other authority responsible for the underlying legal or governmental function.

4.4 The specific legal status of a Transaction depends on the applicable law, jurisdiction, issuing or verifying authority, Service, Document, transaction type, and facts applicable to that Transaction.

4.5 StampMitra does not represent that every Service is available in every jurisdiction, state, district, office, authority, document category, or transaction type.

5.1 Unless expressly stated on an official StampMitra communication, StampMitra is not a government department or government authority.

5.2 Use of government-related or regulatory Services through StampMitra does not create any government affiliation, endorsement, partnership, agency, or representation.

5.3 Developers must not represent StampMitra as a government authority or represent a StampMitra Service as an official government service unless such representation is expressly authorised.

6.1 Verification Services may include identity verification, document verification, information validation, status verification, record verification, eligibility checks, or other verification functionality.

6.2 The availability and scope of a Verification Service depends on the applicable Service and underlying data source.

6.3 A Verification result may indicate that information matched, did not match, could not be verified, was unavailable, was inconclusive, or otherwise produced a status defined by the applicable Service.

6.4 A successful technical Verification does not necessarily constitute a legal determination, judicial determination, governmental certification, professional opinion, or guarantee of authenticity beyond the scope of the applicable verification process.

6.5 Developers must not represent a Verification result as stronger or broader than the result actually provided.

7.1 The Developer must have a lawful and appropriate basis for submitting a Verification request.

7.2 The Developer must obtain all required permissions, notices, consents, authorisations, mandates, or other legal bases required for the applicable Verification.

7.3 The Developer must not initiate Verification transactions for individuals or entities without appropriate authority.

7.4 The Developer must comply with applicable privacy, data protection, consumer protection, identity verification, sector-specific, and regulatory requirements.

7.5 StampMitra may require evidence of authority where reasonably necessary.

8.1 The Developer is responsible for ensuring that Verification Data submitted through the API is accurate, lawful, relevant, and authorised.

8.2 The Developer must not knowingly submit forged, manipulated, stolen, unlawfully obtained, misleading, or fraudulent Verification Data.

8.3 Verification Data must be limited to information reasonably necessary for the applicable Service.

8.4 The Developer must not use Verification Services to conduct unlawful surveillance, harassment, discrimination, profiling, identity theft, stalking, or other prohibited activities.

9.1 Verification results are provided for the purpose for which the applicable Service is designed.

9.2 A Verification result may be subject to source-system availability, data quality, data freshness, source-system rules, technical limitations, jurisdictional limitations, or other external factors.

9.3 StampMitra does not independently guarantee the accuracy of information originating from an external source.

9.4 Where a Service returns a source status, the Developer must not alter or misrepresent that status.

9.5 Developers must retain sufficient transaction references to support lawful reconciliation and customer support.

10.1 External data sources may contain incomplete, outdated, inconsistent, unavailable, or incorrect information.

10.2 StampMitra may normalise, structure, format, or transform source information for API delivery.

10.3 Such transformation does not constitute an independent certification of the underlying information.

10.4 Where source information is unavailable, StampMitra may return an appropriate unavailable, pending, failed, or error status.

11.1 e-Stamp Services may facilitate procurement, generation, delivery, validation, status tracking, or related processing of electronic stamp instruments.

11.2 The availability of e-Stamp Services depends on the applicable jurisdiction, state, authority, stamp article, transaction type, denomination, document type, and external system availability.

11.3 StampMitra does not itself determine statutory Stamp Duty unless the applicable Service expressly provides a calculation or information facility based on authorised data.

11.4 Where Stamp Duty is determined by an authority or source, the Developer must rely on the applicable authoritative determination rather than independently representing a different amount as authoritative.

11.5 Developers remain responsible for reviewing the Transaction information before final submission.

12.1 Stamp Duty, stamping procedure, document requirements, purchaser requirements, execution requirements, registration requirements, and related procedures may vary by State, Union Territory, authority, jurisdiction, document category, and transaction type.

12.2 The Developer must comply with the requirements applicable to the relevant jurisdiction.

12.3 A Service available in one jurisdiction may not be available in another.

12.4 StampMitra does not guarantee that a particular Service will remain available following a change in law, government procedure, authority system, or external service.

13.1 The Developer is responsible for selecting or submitting the correct document category, stamp article, instrument type, transaction type, and related classification where the Service requires Developer input.

13.2 A Developer must not knowingly select an incorrect stamp article or classification to reduce applicable statutory charges or otherwise circumvent legal requirements.

13.3 Where the Service provides structured options, Developers must use the option that accurately corresponds to the underlying transaction.

13.4 StampMitra may reject, suspend, or require correction of a Transaction where submitted information appears inconsistent, incomplete, fraudulent, or materially incorrect.

14.1 The Developer must verify the required stamp denomination before completing a Transaction.

14.2 The availability of particular denominations may depend on the relevant jurisdiction and Service.

14.3 A technical amount displayed by an API does not override the statutory requirement applicable to the underlying transaction.

15.1 Developers are responsible for the accuracy of document details submitted for an e-Stamp Transaction.

15.2 Such details may include parties, names, addresses, consideration, execution date, instrument type, jurisdiction, document description, purchaser details, or other required information.

15.3 The Developer must review all material details before final submission.

15.4 StampMitra is not responsible for errors introduced by the Developer or End User.

16.1 The Developer must ensure that the correct parties are identified.

16.2 Names, identifiers, addresses, and other details must correspond to the underlying legal transaction.

16.3 StampMitra does not independently determine the legal identity or contractual relationship between the parties to a Document unless the applicable Verification Service expressly performs such function.

17.1 Where an execution date is required, the Developer must provide the legally appropriate date.

17.2 Developers must not manipulate execution dates for the purpose of avoiding applicable legal requirements.

17.3 A timestamp generated by StampMitra or an external system must not be treated as a substitute for the legally relevant execution date unless applicable law provides otherwise.

18.1 Where purchaser information is required, the Developer must provide accurate information.

18.2 The Developer is responsible for ensuring that the person or entity identified as purchaser is appropriately authorised.

18.3 StampMitra does not assume responsibility for the legal consequences of incorrect purchaser information supplied by the Developer.

19.1 Where consideration or transaction value is relevant to stamping, the Developer must provide accurate information.

19.2 The Developer must not intentionally understate, conceal, or manipulate consideration or transaction value to reduce statutory charges.

19.3 StampMitra may reject or suspend transactions that appear materially inconsistent or potentially fraudulent.

20.1 Applicable Stamp Duty and related charges must be paid through the applicable payment mechanism.

20.2 A payment confirmation does not necessarily mean that the underlying e-Stamp instrument has been issued.

20.3 A Transaction may remain pending after payment where external confirmation or issuance is required.

20.4 Developers must not represent a payment as an issued stamp instrument until the applicable issuance status has been confirmed.

21.1 Issuance is subject to successful completion of the applicable transaction process.

21.2 Issuance may depend on external systems and authorities.

21.3 StampMitra may provide an issuance reference, certificate reference, transaction reference, document, or other output where made available by the applicable Service.

21.4 The Developer must preserve the original issued instrument or electronic representation in accordance with applicable legal and business requirements.

22.1 An e-Stamp Transaction may have statuses including, without limitation:

• (a) initiated;
• (b) pending;
• (c) payment pending;
• (d) payment successful;
• (e) processing;
• (f) issued;
• (g) failed;
• (h) rejected;
• (i) cancelled;
• (j) expired;
• (k) reversed; or
• (l) another status defined by the applicable API.

22.2 The Developer must rely on the authoritative API status rather than assuming successful completion based solely on an HTTP success response, payment response, or frontend event.

22.3 Developers must implement appropriate reconciliation logic for pending and asynchronous Transactions.

23.1 Whether an e-Stamp can be corrected depends on applicable law and the applicable issuing process.

23.2 StampMitra does not guarantee that incorrect information can be corrected after issuance.

23.3 Developers must review material Transaction details before submission.

23.4 Where correction is legally unavailable, the Developer may be required to initiate a new Transaction or follow the applicable authority process.

24.1 Cancellation availability depends on the stage and nature of the Transaction and applicable law.

24.2 A Transaction may not be cancellable after issuance or another legally relevant event.

24.3 Cancellation through the StampMitra platform does not override any statutory or authority-specific cancellation procedure.

25.1 Refund eligibility is governed by the StampMitra Billing, API Credits & Refund Policy and applicable Service rules.

25.2 Statutory or authority-controlled amounts may be subject to separate rules.

25.3 StampMitra does not guarantee a refund merely because a Developer requests one.

25.4 Where an external authority determines whether a statutory amount is refundable, StampMitra may be required to follow that determination.

26.1 A Developer must immediately investigate duplicate Transactions or suspected duplicate issuance.

26.2 Developers must not use, sell, transfer, or represent duplicate instruments as independently valid where doing so is unlawful.

26.3 Replacement or reissuance of a lost or inaccessible instrument is subject to applicable law and Service capability.

26.4 StampMitra does not guarantee replacement where the applicable authority does not provide such functionality.

27.1 The following activities are prohibited:

• (a) fabrication of stamp instruments;
• (b) alteration of issued stamp information;
• (c) fraudulent duplication;
• (d) manipulation of Transaction references;
• (e) misrepresentation of issuance status;
• (f) unlawful resale;
• (g) use for fraudulent transactions;
• (h) use of stolen identity information; or
• (i) any other unlawful use.

28.1 Where a Service results in a physical instrument or requires physical handling, the Developer is responsible for lawful custody and use after delivery or transfer.

28.2 StampMitra is not responsible for loss, damage, alteration, destruction, or misuse occurring after lawful delivery unless otherwise required by applicable law or an applicable written agreement.

29.1 Electronic Documents and e-Stamp outputs must be stored securely.

29.2 Developers must protect electronic Documents against unauthorised access, modification, deletion, disclosure, or misuse.

29.3 Developers must not expose downloadable documents through unrestricted public URLs where such exposure would create an unauthorised disclosure risk.

30.1 e-Sign Services facilitate an electronic signature process where supported by an applicable authorised system.

30.2 The availability and legal framework of e-Sign depends on the applicable service, authentication mechanism, jurisdiction, signer, Document, and applicable law.

30.3 StampMitra does not represent that every electronic signature method is legally interchangeable in every jurisdiction or transaction.

31.1 A Signer must have authority to execute the relevant Document.

31.2 The Developer is responsible for ensuring that the person invited to sign is the intended Signer.

31.3 A Developer must not submit a Document for signature by impersonating another person.

31.4 A Developer must not knowingly facilitate unauthorised signing.

32.1 The identity of a Signer may be authenticated using one or more mechanisms supported by the applicable e-Sign Service.

32.2 Authentication does not relieve the Developer from ensuring that the intended person is participating in the transaction.

32.3 Where identity information is supplied by an external system, StampMitra does not independently guarantee the underlying identity information beyond the scope of the applicable Service.

33.1 The Signer must knowingly participate in the signature process.

33.2 The Developer must provide appropriate information regarding the Document and signature action where required by applicable law.

33.3 A Developer must not use deceptive interfaces, hidden controls, misleading language, or other practices to obtain a signature without appropriate awareness and intent.

34.1 The Developer must not create a workflow designed to make a Signer believe that they are performing one action when they are actually executing another.

34.2 Material signature actions must be presented clearly.

34.3 The Developer remains responsible for its user interface and business process surrounding the e-Sign flow.

35.1 Where OTP or another authentication mechanism is used, the Developer must not intercept, manipulate, bypass, or misuse authentication.

35.2 OTPs must not be stored or logged unnecessarily.

35.3 Developers must not ask Signers to disclose authentication secrets to Developer personnel.

35.4 StampMitra may reject or suspend suspicious authentication activity.

36.1 Signers must maintain control of their authentication credentials.

36.2 Developers must not request or retain Signer authentication secrets unless expressly authorised and technically required by the applicable Service.

36.3 Credential sharing is prohibited where it compromises signer authentication or auditability.

37.1 Developers must ensure that the Signer is presented with the correct Document.

37.2 Developers must not replace, modify, or materially alter the Document after the signature process has been completed in a manner that invalidates or misrepresents the signature.

37.3 If a Document must be modified after signature, the Developer must follow an appropriate legally valid process.

38.1 Where an applicable Service provides an audit trail, transaction record, timestamp, signer event, authentication event, or related metadata, Developers must preserve it where legally or operationally required.

38.2 Developers must not alter audit records.

38.3 StampMitra may retain technical records required for security, compliance, reconciliation, dispute handling, and legal obligations.

39.1 A timestamp generated by a Service may reflect the time recorded by the applicable technical system.

39.2 Developers must not represent a system timestamp as a statutory execution date unless legally appropriate.

39.3 Time zone differences may affect presentation of transaction timestamps.

40.1 Where a signature certificate or equivalent technical evidence is provided by an applicable authorised system, the Developer must preserve it where required.

40.2 The legal status of a signature certificate depends on the applicable law and issuing framework.

40.3 StampMitra does not independently issue or certify every electronic signature or certificate.

41.1 A Signature Transaction may fail because of authentication failure, signer abandonment, timeout, external system failure, invalid information, document issues, service restrictions, or other causes.

41.2 A failed signature request must not be represented as completed.

41.3 Developers must implement appropriate retry and reconciliation logic.

42.1 Developers must not automatically create unlimited signature requests.

42.2 Repeated retries must be controlled to prevent duplicate signatures, duplicate transactions, abuse, or confusion.

42.3 Where an existing transaction remains pending, Developers should reconcile the existing transaction before creating a new one where technically possible.

43.1 Revocation or cancellation depends on the applicable Service and law.

43.2 Completion of a signature may create legal consequences that cannot be reversed merely through an API cancellation request.

43.3 Developers must communicate cancellation limitations accurately to End Users.

44.1 StampMitra facilitates technical processes and does not provide a universal legal guarantee regarding the enforceability of every electronically signed Document.

44.2 Legal effect depends on applicable law, signature method, signer identity, consent, intent, Document type, jurisdiction, and surrounding circumstances.

44.3 Developers remain responsible for determining whether a particular signature method is appropriate for their use case.

45.1 StampMitra may facilitate certain legal or business document workflows.

45.2 Unless expressly stated otherwise, StampMitra does not provide legal advice, advocate services, legal opinions, representation, or attorney-client services merely by providing a Document or document-related API.

45.3 A document template or generated Document must not be represented as legal advice.

45.4 Developers should obtain independent professional advice where appropriate.

46.1 The Developer is responsible for the substantive content supplied for a Document.

46.2 StampMitra does not assume responsibility for:

• (a) commercial terms;
• (b) factual statements;
• (c) party obligations;
• (d) representations;
• (e) warranties;
• (f) consideration;
• (g) addresses;
• (h) identity information;
• (i) legal conclusions; or
• (j) other substantive content supplied by the Developer.

47.1 Developers must review Documents before execution, stamping, signing, submission, or delivery.

47.2 A Developer must not rely solely on automated generation without appropriate review where human review is legally or commercially appropriate.

47.3 StampMitra is not responsible for errors caused by inaccurate input.

48.1 StampMitra does not represent that a Document has been notarised merely because it has been generated, stamped, signed, or processed through the platform.

48.2 Where notarisation is legally required, the Developer must arrange the appropriate process.

49.1 StampMitra does not guarantee registration of a Document with any registrar, authority, or governmental office unless a specific Service expressly provides such functionality.

49.2 Stamp duty payment, e-Sign completion, or Document generation does not automatically establish that registration requirements have been satisfied.

50.1 Government authorities may impose additional requirements.

50.2 Developers and End Users remain responsible for satisfying applicable requirements.

50.3 StampMitra may provide technical facilitation without assuming responsibility for the authority's final decision.

51.1 Services may depend on External Systems.

51.2 External Systems may experience outages, maintenance, latency, errors, changes, rejection, rate limits, technical restrictions, or discontinuation.

51.3 StampMitra may be unable to complete a Transaction where an External System is unavailable.

52.1 StampMitra may dynamically route a Transaction through an appropriate Underlying Service Provider, Authorised Source, or External System.

52.2 The Developer is not entitled to select, mandate, or require disclosure of a particular underlying provider unless expressly agreed in writing.

52.3 Provider routing may change for operational, technical, commercial, security, legal, capacity, or continuity reasons.

53.1 Information regarding StampMitra's commercial relationships, provider architecture, routing arrangements, provider identifiers, technical credentials, commercial rates, or internal integration details may constitute confidential information.

53.2 Developers must not attempt to discover, identify, circumvent, contact, contract with, or interfere with underlying providers through technical or other means for the purpose of bypassing StampMitra.

54.1 Developers receive access only to the StampMitra interface and Services made available to them.

54.2 Developers are not entitled to credentials, endpoints, private interfaces, authentication details, or direct access to underlying systems.

54.3 Any attempt to obtain such access is prohibited.

55.1 Certain Services may be subject to third-party terms, government rules, statutory requirements, pass-through conditions, or other applicable requirements.

55.2 The Developer agrees to comply with such requirements to the extent communicated or applicable to its use of the Service.

55.3 The Third-Party & Underlying Services Policy forms part of these Service Terms.

56.1 StampMitra does not guarantee uninterrupted availability of every verification, e-Stamp, or e-Sign Service.

56.2 Availability may depend on external authorities and service providers.

56.3 Service availability is governed additionally by the API SLA & Service Availability Policy.

57.1 Certain Services may be processed asynchronously.

57.2 A successful request acceptance does not necessarily mean final completion.

57.3 Developers must implement webhook, polling, status-check, or reconciliation mechanisms where supported.

58.1 Developers must retain applicable transaction identifiers.

58.2 Transaction identifiers must not be altered.

58.3 Developers must use the correct identifier when requesting status, support, reconciliation, refund, or dispute assistance.

59.1 Developers must implement idempotency where the applicable API supports or requires it.

59.2 Idempotency is particularly important for payment, stamping, issuance, signature, and other potentially irreversible operations.

59.3 Developers must not create duplicate transactions through uncontrolled retries.

60.1 Developers are responsible for reconciling Transactions between their systems and StampMitra.

60.2 A discrepancy must be investigated before the Developer assumes that a Transaction succeeded or failed.

60.3 Payment status, service status, issuance status, and signature status may represent different stages.

61.1 Payment confirmation may only indicate that payment was accepted or recorded.

61.2 A Service may remain pending or fail after payment.

61.3 Developers must communicate status accurately to End Users.

62.1 Developers must take reasonable steps to prevent duplicate Transactions.

62.2 Duplicate Transactions may create separate charges, external requests, or legal consequences.

62.3 StampMitra is not responsible for duplicates caused by Developer retry logic, multiple user submissions, or uncontrolled automation, except where required by applicable law.

63.1 Pending status means that final outcome has not yet been established.

63.2 Developers must not prematurely mark a pending Transaction as failed or completed.

63.3 Developers should use the supported status or reconciliation mechanisms.

64.1 A failed Transaction means the applicable Service did not complete successfully based on the returned status.

64.2 Failure may be caused by Developer input, End User action, external systems, authority systems, payment issues, technical errors, or other factors.

65.1 An external authority or service may reject a Transaction.

65.2 Rejection may be based on legal, procedural, data, eligibility, technical, or other requirements.

65.3 StampMitra does not guarantee reversal of an external rejection.

66.1 StampMitra may apply fraud prevention, risk controls, transaction screening, rate controls, or other safeguards.

66.2 Such controls may delay, reject, restrict, or require additional verification.

66.3 Developers must cooperate with reasonable security and fraud-prevention measures.

67.1 Where identity documents are required, Developers must submit only documents and information lawfully obtained and necessary for the applicable Service.

67.2 Developers must not upload forged or altered identity documents.

67.3 Developers must protect identity documents from unauthorised disclosure.

68.1 Developers must not submit children's personal data unless legally permitted and appropriate safeguards and lawful requirements have been satisfied.

68.2 Where applicable law requires parental or guardian consent, the Developer is responsible for obtaining and documenting such consent.

68.3 StampMitra may restrict Services involving children where appropriate.

69.1 Developers must not submit sensitive information unless necessary for the applicable Service and legally permitted.

69.2 Unnecessary sensitive information must not be transmitted through API fields, metadata, logs, support requests, or free-text fields.

70.1 Processing of personal data through these Services is governed by the StampMitra Developer Privacy Policy and, where applicable, the Data Processing Addendum.

70.2 The Developer remains responsible for its own legal obligations relating to End User data.

70.3 Where StampMitra acts as a processor or equivalent for a particular processing activity, the applicable DPA governs that processing.

71.1 The Developer is responsible for providing End Users with legally required notices.

71.2 Where consent is required, the Developer must obtain valid consent in the manner required by applicable law.

71.3 Developers must not represent that StampMitra has obtained End User consent merely because the API request was accepted.

72.1 Developers must submit only data reasonably required for the Service.

72.2 Developers must not use API fields for unrelated data collection.

72.3 StampMitra may reject or restrict requests containing excessive or unrelated information.

73.1 Developers are responsible for retaining Service outputs where required for their business or legal purposes.

73.2 StampMitra's retention practices are governed by applicable policies, technical requirements, legal obligations, and Service requirements.

73.3 Developers must not assume that StampMitra will retain Documents indefinitely.

74.1 Developers must maintain appropriate controls for storing Documents, identity records, stamp instruments, signature records, and transaction evidence.

74.2 Publicly exposing private Documents is prohibited.

74.3 Developers must restrict access to authorised personnel and End Users.

75.1 Where a Service provides a downloadable Document or instrument, Developers must protect the associated URL, token, identifier, or credential.

75.2 Developers must not expose private download links publicly.

75.3 Developers must not create permanent public mirrors of confidential Documents without lawful authority.

76.1 Developers must comply with the StampMitra API Security Policy.

76.2 API keys, webhook secrets, access tokens, credentials, and other security information must be protected.

76.3 Developers must not place secret credentials in public client-side code.

77.1 Developers must validate webhook authenticity using the security mechanisms documented by StampMitra.

77.2 Developers must protect webhook endpoints.

77.3 Developers must implement replay protection and idempotent processing where appropriate.

77.4 Developers must not treat an unverified webhook as authoritative.

78.1 Developers must correctly handle API errors.

78.2 Developers must not expose internal error information, provider information, credentials, or sensitive diagnostic information to End Users.

78.3 Developers must not repeatedly retry permanent failures.

79.1 Services may be subject to rate limits, transaction limits, geographical limitations, document limitations, provider limitations, or other restrictions.

79.2 StampMitra may modify operational limits in accordance with applicable policies.

80.1 Developers must not use Verification, e-Stamp, or e-Sign Services in high-risk contexts where failure could cause significant harm unless appropriate human review, controls, and lawful safeguards are implemented.

80.2 StampMitra may restrict use cases involving material legal, financial, identity, employment, healthcare, governmental, or other high-impact decisions where appropriate.

81.1 A Verification result must not automatically be treated as the sole basis for a material decision where applicable law requires human review or other safeguards.

81.2 Developers are responsible for their decision-making processes using Service outputs.

82.1 Developers using AI systems with StampMitra Services must ensure that AI-generated outputs do not alter, fabricate, or misrepresent Verification, e-Stamp, e-Sign, or Transaction results.

82.2 AI systems must not be used to bypass authentication, consent, security, or legal requirements.

82.3 Developers remain responsible for actions taken by automated agents using their API credentials.

83.1 The Developer must not represent:

• (a) that StampMitra guarantees legal enforceability;
• (b) that StampMitra guarantees governmental acceptance;
• (c) that a Document is automatically registered;
• (d) that an e-Sign is valid for every purpose;
• (e) that an e-Stamp satisfies every statutory requirement; or
• (f) that a Verification result is an absolute legal determination.

84.1 StampMitra Services are technology and service facilitation tools.

84.2 Nothing in the Services constitutes legal advice.

84.3 Developers remain responsible for obtaining professional advice where necessary.

85.1 Where the Developer is an advocate, chartered accountant, company secretary, consultant, legal-tech provider, professional service provider, or other regulated or professional person, the Developer remains responsible for compliance with professional rules applicable to its activities.

86.1 The Developer is responsible for its End Users.

86.2 The Developer must ensure that End Users receive appropriate information about the relevant Service.

86.3 The Developer must not mislead End Users regarding the role of StampMitra.

87.1 The Developer remains primarily responsible for End User support concerning the Developer Application.

87.2 StampMitra may provide technical support for StampMitra Services.

87.3 Developers must not represent StampMitra support as being responsible for the Developer's own business processes.

88.1 Fees are governed by the StampMitra Billing, API Credits & Refund Policy and applicable commercial terms.

88.2 Government charges, statutory charges, external service charges, and StampMitra fees may constitute separate components of a Transaction.

89.1 Applicable taxes may apply to StampMitra fees and other charges.

89.2 The Developer is responsible for applicable tax compliance in relation to its business and transactions.

90.1 Refund eligibility is governed by the applicable Billing, API Credits & Refund Policy and Transaction-specific terms.

90.2 Refunds are not automatically available solely because a Service was unsuccessful.

90.3 External authority rules may affect the availability or amount of a refund.

91.1 Developers must not initiate fraudulent or abusive chargebacks.

91.2 A legitimate billing dispute should first be raised through the applicable support or billing channel where reasonably possible.

91.3 Fraudulent chargeback activity may result in account restriction or termination.

92.1 External system interruptions may delay Verification, e-Stamp, or e-Sign Transactions.

92.2 Developers must communicate delays accurately.

92.3 StampMitra does not guarantee that an external authority will restore service within any particular period.

93.1 StampMitra may conduct planned or emergency maintenance.

93.2 Maintenance may affect particular Services.

93.3 Security or regulatory changes may require immediate technical changes.

94.1 Changes in law, government policy, technical standards, regulatory instructions, or authority procedures may affect a Service.

94.2 StampMitra may modify, suspend, restrict, or discontinue a Service where reasonably necessary to comply with such changes.

95.1 A change in one State or jurisdiction may affect only certain Services.

95.2 Developers must monitor applicable documentation and Service notices where jurisdiction-specific requirements apply.

96.1 StampMitra does not control decisions made by governmental, regulatory, statutory, judicial, or other external authorities.

96.2 An authority may accept, reject, delay, modify, or request additional information regarding a Transaction.

97.1 An authority or external system may require additional documents or information.

97.2 The Developer is responsible for obtaining and submitting such information where applicable.

98.1 Developers must not knowingly submit fraudulent Documents.

98.2 StampMitra may use available technical and procedural controls to identify suspicious submissions.

98.3 Detection controls do not constitute an absolute guarantee that fraudulent information will be detected.

99.1 Forgery, alteration, fabrication, or manipulation of Documents, stamp instruments, signature evidence, verification results, or transaction records is strictly prohibited.

100.1 Developers must not impersonate End Users, Signers, authorities, businesses, or other persons.

100.2 Developers must not create misleading workflows that obscure the actual identity of the party performing a Transaction.

101.1 A Developer must not cause an electronic signature to be created without appropriate authority and signer participation.

101.2 Credentials or authentication mechanisms must not be used to sign on behalf of another person without lawful authority.

102.1 Developers must not use e-Stamp Services to facilitate fraudulent, fictitious, sham, or unlawful transactions.

103.1 Developers must not circumvent Service controls, jurisdictional restrictions, authentication, payment requirements, eligibility requirements, transaction limits, or security controls.

104.1 Developers must not directly probe, scan, overload, scrape, or interfere with government or authority systems through StampMitra or otherwise.

104.2 Any permitted interaction must occur through the authorised interface provided for the applicable Service.

105.1 Developers must not attempt to identify or exploit vulnerabilities in external systems accessed through StampMitra.

105.2 Security testing must comply with the API Security Policy and applicable authorisation requirements.

106.1 Developers must promptly notify StampMitra where they discover:

• (a) suspected unauthorised access;
• (b) compromised credentials;
• (c) fraudulent Transactions;
• (d) unlawful Document access;
• (e) suspicious signing activity;
• (f) unauthorised disclosure; or
• (g) another material security incident.

107.1 Developers must reasonably cooperate with investigations involving suspected fraud, security incidents, duplicate Transactions, unauthorised signatures, or other material Service issues.

108.1 StampMitra may suspend or restrict a Service or account where reasonably necessary due to:

• (a) security risk;
• (b) fraud;
• (c) unlawful use;
• (d) misuse;
• (e) regulatory requirements;
• (f) external provider restrictions;
• (g) non-payment;
• (h) breach of contract;
• (i) compromised credentials; or
• (j) other circumstances permitted by the Developer Terms of Service.

109.1 StampMitra may immediately restrict a Service where delay could create material security, legal, fraud, financial, operational, or regulatory risk.

110.1 Reinstatement may require remediation, verification, credential rotation, additional information, or other safeguards.

110.2 StampMitra does not guarantee reinstatement following suspension.

111.1 StampMitra may discontinue a Service where reasonably necessary due to legal, technical, commercial, security, operational, external provider, or regulatory circumstances.

111.2 Where reasonably practicable, StampMitra may provide advance notice of material discontinuation.

112.1 StampMitra may provide migration instructions where a Service is replaced or materially changed.

112.2 Developers are responsible for implementing required migration changes within applicable timelines.

113.1 Developers should maintain appropriate records of:

• (a) Transaction identifiers;
• (b) Documents;
• (c) signature events;
• (d) e-Stamp references;
• (e) verification results;
• (f) user consent where required;
• (g) relevant timestamps; and
• (h) reconciliation records.

114.1 Developers must preserve audit information required by applicable law or their own compliance obligations.

114.2 Developers must not fabricate or alter audit trails.

115.1 Support requests relating to a Transaction should include sufficient information to permit investigation.

115.2 Developers should avoid submitting unnecessary personal or sensitive information in support tickets.

115.3 StampMitra may request additional information through secure channels where necessary.

116.1 Transaction information, provider information, technical details, credentials, commercial terms, security information, and non-public Service information may constitute Confidential Information.

116.2 Developers must protect Confidential Information in accordance with the Developer Terms of Service.

117.1 StampMitra retains its rights in its APIs, software, documentation, workflows, interfaces, technical systems, trademarks, service architecture, and other intellectual property.

117.2 The Developer receives only the rights expressly granted under the applicable agreement.

118.1 Documentation may be updated as Services evolve.

118.2 Developers must use current documentation for implementation.

118.3 Undocumented behaviour must not be treated as a guaranteed feature.

119.1 Developers must not build critical business processes around undocumented API responses, hidden endpoints, internal provider identifiers, temporary behaviours, or implementation details.

120.1 Service outputs may be machine-readable, human-readable, or both.

120.2 Developers are responsible for presenting outputs accurately.

120.3 Developers must not modify outputs in a manner that materially misrepresents the underlying result.

121.1 Developers must comply with applicable caching restrictions.

121.2 Sensitive Verification, identity, Document, signature, or e-Stamp data must not be cached insecurely.

121.3 Developers must respect applicable data retention and deletion obligations.

122.1 Where technically supported, Developers may export applicable transaction information subject to security and legal controls.

122.2 Export functionality does not guarantee permanent availability of historical data.

123.1 Termination of the Developer account does not automatically invalidate a legally completed Document, e-Signature, or e-Stamp unless applicable law or authority procedure provides otherwise.

123.2 Developers remain responsible for their legal and recordkeeping obligations after account termination.

124.1 Provisions concerning confidentiality, data protection, intellectual property, payment obligations, liability, audit records, dispute resolution, and other provisions intended by their nature to survive shall survive termination.

125.1 The Developer represents that:

• (a) it has authority to use the Services;
• (b) information supplied is accurate;
• (c) it has appropriate rights to submit End User information;
• (d) its use is lawful;
• (e) its Documents are not knowingly fraudulent;
• (f) its signing workflows are properly authorised; and
• (g) it will comply with applicable law.

126.1 To the maximum extent permitted by law, StampMitra does not guarantee:

• (a) uninterrupted availability;
• (b) universal legal enforceability;
• (c) governmental acceptance;
• (d) accuracy of external source data;
• (e) successful completion of every Transaction;
• (f) availability of every jurisdiction;
• (g) continued availability of every Service; or
• (h) suitability of a Service for a particular legal or commercial purpose.

127.1 Nothing in the Services constitutes a professional legal, tax, accounting, financial, regulatory, or other professional opinion.

128.1 Liability relating to the Services is governed by the liability provisions of the StampMitra Developer Terms of Service and any applicable written commercial agreement.

128.2 Nothing in these Service Terms is intended to create a separate liability standard inconsistent with the governing agreement.

129.1 The Developer's indemnification obligations are governed by the Developer Terms of Service.

129.2 This includes, where applicable, claims arising from unlawful use, fraudulent Documents, unauthorised Transactions, misuse of Services, or violation of applicable law.

130.1 StampMitra is not responsible for failure or delay caused by circumstances beyond reasonable control, subject to applicable law and the Developer Terms of Service.

130.2 Such circumstances may include government outages, authority system failures, telecommunications failures, internet failures, natural disasters, cyber incidents, war, civil disturbance, regulatory changes, or external service disruption.

131.1 These Service Terms are governed by the governing law provisions contained in the StampMitra Developer Terms of Service, subject to applicable Indian law.

132.1 Disputes relating to these Service Terms shall be handled under the dispute-resolution provisions of the StampMitra Developer Terms of Service.

133.1 These Service Terms form part of the StampMitra Developer Policy Framework.

133.2 The following policies may apply:

• (a) Developer Terms of Service;
• (b) Developer Privacy Policy;
• (c) Data Processing Addendum;
• (d) API Acceptable Use Policy;
• (e) Third-Party & Underlying Services Policy;
• (f) API Security Policy;
• (g) API SLA & Service Availability Policy;
• (h) Billing, API Credits & Refund Policy; and
• (i) API Versioning, Suspension & Deprecation Policy.

134.1 In the event of conflict, the order of precedence specified in the Developer Terms of Service shall apply.

134.2 A Service-specific written agreement may supersede these Service Terms where expressly stated.

135.1 StampMitra may update these Service Terms to reflect legal, regulatory, technical, operational, security, or commercial changes.

135.2 Material changes may be communicated through appropriate channels.

135.3 Continued use of the affected Services after the effective date of an update constitutes acceptance to the extent permitted by applicable law.

136.1 If any provision is determined to be invalid or unenforceable, the remaining provisions shall remain effective to the extent permitted by law.

137.1 Failure to enforce any provision does not constitute a permanent waiver of that provision.

138.1 Unless expressly stated otherwise, these Service Terms do not create rights for third parties.

139.1 Assignment of rights or obligations under these Service Terms is governed by the Developer Terms of Service.

140.1 Nothing in these Service Terms creates an agency, partnership, joint venture, employment, franchise, fiduciary, or representative relationship between StampMitra and the Developer.

141.1 The Developer must not represent that it has authority to bind StampMitra or any underlying service provider.

142.1 StampMitra may determine its commercial arrangements, provider relationships, routing arrangements, pricing, and service architecture independently.

142.2 Nothing in these Service Terms creates a requirement for disclosure of confidential commercial arrangements.

143.1 Nothing in these Service Terms permits the Developer to circumvent statutory, regulatory, authority, identity, stamping, signing, payment, or verification requirements.

144.1 Electronic records maintained by StampMitra may be used as evidence of API requests, responses, status changes, authentication events, payment events, or other technical events, subject to applicable law.

145.1 Notices, transaction confirmations, security communications, and policy communications may be delivered electronically.

145.2 Developers are responsible for maintaining accurate contact information.

146.1 These Service Terms are issued in English.

146.2 Translations may be provided for convenience.

146.3 In case of inconsistency, the legally controlling version shall be determined in accordance with the Developer Terms of Service and applicable law.

147.1 The Developer must comply with all laws applicable to its use of the Services.

147.2 This includes applicable information technology, data protection, electronic transaction, evidence, stamping, identity, consumer protection, tax, anti-fraud, and sector-specific requirements, as applicable.

148.1 StampMitra may cooperate with lawful requests from competent authorities.

148.2 Developers must not interfere with lawful investigations.

149.1 StampMitra may disclose information where required by applicable law, court order, regulatory direction, or lawful government request.

149.2 Disclosure will be handled in accordance with applicable law and the Privacy Policy.

150.1 Developers must comply with the StampMitra API Security Policy.

150.2 Material security failures may result in Service restriction or account suspension.

151.1 Where a Developer provides StampMitra-powered Services to End Users, the Developer is responsible for obtaining any contractual acknowledgement or consent required for the Developer's own service.

152.1 Developers must clearly identify their own role where appropriate.

152.2 Developers must not conceal material information about the nature of a Transaction where disclosure is legally required.

153.1 Developers must not make false or misleading claims regarding StampMitra Services.

153.2 Claims regarding government approval, legal enforceability, statutory status, verification accuracy, or signature validity must be accurate and appropriately qualified.

154.1 Use of StampMitra branding is subject to applicable brand guidelines and the rights granted under the Developer Terms of Service.

154.2 Developers must not imply endorsement or official government affiliation.

155.1 StampMitra may investigate suspected misuse, fraud, security incidents, unlawful activity, or material contractual violations.

155.2 The Developer must reasonably cooperate with such investigations.

156.1 Individual Services may contain additional requirements, restrictions, eligibility criteria, transaction limits, or documentation requirements.

156.2 Such requirements may be presented in API documentation, onboarding materials, Service notices, or applicable commercial terms.

157.1 Enterprise customers may receive additional contractual protections, obligations, service levels, or processing terms under a separate written agreement.

157.2 Where an Enterprise agreement expressly conflicts with these Service Terms, the Enterprise agreement shall govern to the extent of the conflict.

158.1 StampMitra provides APIs and technical documentation.

158.2 The Developer is responsible for:

• (a) implementation;
• (b) user interface;
• (c) authentication flow;
• (d) consent flow;
• (e) Document presentation;
• (f) End User communication;
• (g) storage;
• (h) access control;
• (i) reconciliation; and
• (j) compliance of its application.

159.1 StampMitra does not guarantee that use of a Service will result in:

• (a) contract acceptance;
• (b) registration;
• (c) government approval;
• (d) loan or financial approval;
• (e) legal enforceability;
• (f) successful verification;
• (g) successful signature;
• (h) transaction completion; or
• (i) any particular commercial outcome.

160.1 Developers must interpret Service outputs according to the applicable API documentation and transaction context.

160.2 Developers must not infer legal conclusions from technical statuses unless the applicable Service expressly provides such conclusion.

161.1 By using any applicable Verification, e-Stamp, e-Sign, or related Service, the Developer acknowledges that:

• (a) the Services may depend on external systems;
• (b) the Developer is responsible for lawful use;
• (c) transaction information must be accurate;
• (d) signatures require appropriate authority and participation;
• (e) e-Stamp requirements may vary by jurisdiction;
• (f) legal effect depends on applicable law and facts;
• (g) external systems may affect availability and outcomes;
• (h) StampMitra does not provide universal legal advice or guarantees; and
• (i) these Service Terms form part of the contractual framework governing the Services.

162.1 Legal and policy correspondence may be directed to:

[email protected]

162.2 Official platform:

https://developer.stampmitra.in/

• Policy Name: Verification, e-Stamp & e-Sign Service Terms
• Policy Number: 9 of 10
• Version: 1.0
• Status: FINAL — PUBLISHED POLICY
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026
• Legal Entity: BANI GLOBAL INDUSTRIES LLP
• Prepared By: Legal Team
• Legal Contact: [email protected]