Developer Onboarding & Verification Policy

1.1 This Developer Onboarding & Verification Policy (“Policy”) establishes the requirements, procedures and governance framework for registration, verification, activation and continued access to the StampMitra Developer Platform.

1.2 The purpose of this Policy is to:

• (a) provide a structured onboarding process;
• (b) distinguish Individual and Organization Developers;
• (c) enable legitimate developers to access Sandbox services;
• (d) apply appropriate verification before Production access;
• (e) protect Developer accounts and API credentials;
• (f) prevent fraud, impersonation and unauthorized use;
• (g) support applicable legal and regulatory requirements;
• (h) maintain accurate account information;
• (i) establish Production eligibility criteria; and
• (j) provide a transparent basis for approval, restriction, suspension and re-verification.

2.1 This Policy forms part of the StampMitra Developer policy framework.

2.2 Use of the StampMitra Developer Platform remains subject to the Developer Terms of Service and all other applicable StampMitra policies.

2.3 Completion of onboarding does not by itself create an unconditional right to Production access.

3.1 This Policy applies to:

• (a) Individual Developers;
• (b) Freelancers;
• (c) Consultants;
• (d) Students;
• (e) Technical founders;
• (f) Independent developers;
• (g) Organizations;
• (h) Companies;
• (i) LLPs;
• (j) Partnerships;
• (k) Startups;
• (l) Educational or research users;
• (m) internal enterprise development teams;
• (n) client-project developers; and
• (o) other persons or entities seeking authorized Developer access.

4.1 StampMitra may support at least the following account types:

• (a) Individual Developer; and
• (b) Organization Developer.

4.2 The account type shall reflect the actual nature of the Developer's use of the platform.

4.3 An Individual Developer is not required to represent themselves as an organization merely to access Sandbox services.

5.1 An Individual Developer may include:

• (a) a freelancer;
• (b) independent consultant;
• (c) student;
• (d) technical founder;
• (e) software developer;
• (f) researcher;
• (g) personal-project developer;
• (h) independent contractor; or
• (i) another individual legitimately developing an application.

6.1 An Organization Developer may include:

• (a) company;
• (b) LLP;
• (c) partnership;
• (d) registered business;
• (e) startup;
• (f) educational institution;
• (g) non-profit organization;
• (h) enterprise;
• (i) government-related organization where permitted; or
• (j) other legally recognized organization.

7.1 An Individual Developer may use StampMitra for an authorized client project.

7.2 The Developer shall ensure that:

• (a) the client has authorized the integration;
• (b) API usage is lawful;
• (c) data submitted through the API is authorized;
• (d) credentials are appropriately controlled; and
• (e) the Developer does not misrepresent the client relationship.

8.1 Freelancers may onboard as Individual Developers where they are legitimately providing development or integration services.

8.2 A freelancer shall not be required to falsely represent themselves as a company merely to access Sandbox functionality.

9.1 Students and educational users may access Sandbox services subject to applicable eligibility requirements.

9.2 Production access may require additional verification depending upon the service and risk level.

10.1 A Developer must satisfy the minimum age and legal capacity requirements applicable to entering into a binding agreement.

10.2 Where applicable law requires parental, guardian or other authorization, the relevant authorization must be obtained.

11.1 Registration shall be completed through an authorized StampMitra Developer channel.

11.2 A Developer may be required to provide:

• (a) name;
• (b) email address;
• (c) mobile number;
• (d) account type;
• (e) country or jurisdiction;
• (f) intended use case;
• (g) organization information where applicable;
• (h) other information reasonably required for onboarding.

12.1 All onboarding information must be accurate, current and not misleading.

12.2 A Developer shall not:

• (a) impersonate another person;
• (b) use fabricated organization information;
• (c) submit false identification;
• (d) misrepresent its business;
• (e) misrepresent its intended use;
• (f) provide misleading ownership information; or
• (g) deliberately conceal material information.

13.1 StampMitra may require verification of the Developer's email address.

13.2 Verification may be performed through:

• (a) OTP;
• (b) verification link;
• (c) authentication flow; or
• (d) another authorized mechanism.

14.1 StampMitra may require verification of a Developer's mobile number.

14.2 Mobile verification may be performed using an OTP or another authorized authentication mechanism.

15.1 OTPs are security credentials.

15.2 Developers shall not:

• (a) share OTPs;
• (b) publish OTPs;
• (c) provide OTPs to another person;
• (d) enter OTPs into untrusted websites; or
• (e) disclose OTPs to persons claiming to be StampMitra support.

16.1 StampMitra shall not ordinarily request a Developer to disclose an OTP through email, telephone, support ticket or ordinary communication.

16.2 Developers should treat requests for OTP disclosure as potentially fraudulent.

17.1 Where password authentication is used, Developers shall maintain a strong and unique password.

17.2 Passwords shall not be shared with:

• (a) clients;
• (b) employees;
• (c) contractors;
• (d) support personnel;
• (e) StampMitra personnel; or
• (f) other third parties.

18.1 StampMitra may provide or require additional authentication controls depending on:

• (a) account type;
• (b) Production access;
• (c) risk;
• (d) organization requirements;
• (e) security events; or
• (f) service sensitivity.

19.1 An account must be controlled by the person or organization legitimately entitled to use it.

19.2 An account shall not be created for the purpose of impersonating another person or organization.

20.1 A person registering an Organization account represents that they are authorized to act for the organization or are otherwise authorized to create the relevant workspace.

20.2 StampMitra may request evidence of such authority where reasonably necessary.

21.1 Organizations may be required to provide, depending upon the level of access requested:

• (a) legal name;
• (b) organization type;
• (c) registered address;
• (d) website;
• (e) authorized representative;
• (f) business contact details;
• (g) registration information;
• (h) tax information where applicable;
• (i) use case;
• (j) intended API services; and
• (k) other relevant information.

22.1 An Individual Developer may be required to provide information reasonably necessary for:

• (a) identity verification;
• (b) account security;
• (c) Production approval;
• (d) billing;
• (e) fraud prevention;
• (f) legal compliance; or
• (g) service-specific requirements.

23.1 StampMitra may apply progressive verification.

23.2 Verification requirements may increase according to:

• (a) Sandbox versus Production;
• (b) API sensitivity;
• (c) transaction volume;
• (d) financial exposure;
• (e) data sensitivity;
• (f) regulatory requirements;
• (g) risk level;
• (h) organization status; and
• (i) service type.

24.1 Sandbox onboarding may be designed as a low-friction development process.

24.2 A Sandbox Developer may generally be required to complete:

• (a) account registration;
• (b) email verification;
• (c) mobile verification where required;
• (d) acceptance of applicable terms; and
• (e) basic use-case information.

25.1 StampMitra may automatically activate Sandbox access after successful completion of applicable registration requirements.

25.2 Automatic activation does not constitute Production approval.

26.1 Sandbox access is intended for:

• (a) development;
• (b) testing;
• (c) integration;
• (d) API exploration;
• (e) webhook testing;
• (f) error handling;
• (g) implementation validation; and
• (h) other authorized testing activities.

27.1 Sandbox may have:

• (a) simulated responses;
• (b) restricted transaction values;
• (c) limited data;
• (d) test credentials;
• (e) rate limits;
• (f) restricted services; and
• (g) other technical limitations.

28.1 Production access may require additional verification and approval.

28.2 Production access is subject to:

• (a) account verification;
• (b) use-case assessment;
• (c) service eligibility;
• (d) security requirements;
• (e) applicable legal requirements;
• (f) risk assessment; and
• (g) any commercial or technical requirements.

29.1 StampMitra may require a Developer to submit a Production application.

29.2 The application may request:

• (a) intended use case;
• (b) application or website;
• (c) expected traffic;
• (d) API services required;
• (e) data categories;
• (f) transaction types;
• (g) target users;
• (h) organization information;
• (i) compliance information;
• (j) security information; and
• (k) other relevant details.

30.1 Production eligibility may consider:

• (a) completed onboarding;
• (b) verified identity;
• (c) legitimate use case;
• (d) security readiness;
• (e) acceptable-use compliance;
• (f) required documentation;
• (g) service-specific requirements;
• (h) account history; and
• (i) applicable legal requirements.

31.1 Completion of Sandbox testing does not guarantee Production approval.

31.2 StampMitra may approve, reject, restrict or request additional information regarding a Production application.

32.1 Production applications may undergo automated, manual or risk-based review.

32.2 Review may involve:

• (a) identity verification;
• (b) organization verification;
• (c) use-case review;
• (d) security review;
• (e) compliance review;
• (f) fraud screening;
• (g) technical review; or
• (h) other appropriate checks.

33.1 StampMitra may verify the identity of:

• (a) Individual Developers;
• (b) authorized representatives;
• (c) organization owners;
• (d) administrators;
• (e) billing contacts; or
• (f) other persons where reasonably necessary.

34.1 Organization verification may include validation of:

• (a) legal existence;
• (b) legal name;
• (c) registered information;
• (d) website;
• (e) authorized representative;
• (f) ownership or control where necessary; and
• (g) other organization information.

35.1 StampMitra may request documents for verification where reasonably necessary.

35.2 Documents may include, depending upon the use case:

• (a) identity documentation;
• (b) organization registration documents;
• (c) authorization letters;
• (d) business documents;
• (e) address information;
• (f) tax information where applicable; or
• (g) service-specific documentation.

36.1 StampMitra shall seek to request only documentation reasonably necessary for the relevant verification purpose.

36.2 Developers should not submit unnecessary documents.

37.1 Documents submitted for verification must be genuine and lawfully obtained.

37.2 Developers shall not submit:

• (a) forged documents;
• (b) altered documents;
• (c) misleading documents;
• (d) documents belonging to another person without authorization;
• (e) expired documents where current documents are required; or
• (f) fabricated information.

38.1 Where appropriate, StampMitra may permit or require unnecessary information to be redacted.

38.2 Developers shall not redact information necessary to complete a lawful verification.

39.1 StampMitra may use authorized external systems, databases, data sources or service providers for verification.

39.2 External verification may be subject to availability, accuracy and applicable legal restrictions.

40.1 Verification may fail, remain pending or require additional information.

40.2 StampMitra does not guarantee that every submitted application will be verified successfully.

41.1 An application may be assigned a status such as:

• (a) Not Started;
• (b) Submitted;
• (c) Under Review;
• (d) Additional Information Required;
• (e) Verification Pending;
• (f) Approved;
• (g) Restricted;
• (h) Rejected;
• (i) Suspended; or
• (j) Closed.

42.1 StampMitra may request additional information where:

• (a) submitted information is incomplete;
• (b) information conflicts;
• (c) verification fails;
• (d) risk is identified;
• (e) the use case requires clarification;
• (f) a service requires additional eligibility; or
• (g) Applicable Law requires further verification.

43.1 If a Developer fails to provide reasonably required information, StampMitra may:

• (a) keep Production access pending;
• (b) restrict functionality;
• (c) reject the application;
• (d) suspend access; or
• (e) request resubmission.

44.1 Verification timelines may vary.

44.2 Timing may depend upon:

• (a) application completeness;
• (b) manual review;
• (c) external verification;
• (d) service complexity;
• (e) regulatory requirements;
• (f) document quality; and
• (g) operational capacity.

44.3 StampMitra does not guarantee a universal verification timeline unless expressly stated.

45.1 StampMitra may charge fees for specific verification, onboarding or Production services where such fees are expressly stated in applicable commercial terms.

45.2 No fee shall be implied merely because verification is performed.

46.1 Developers shall provide an accurate description of their intended API use.

46.2 The use-case description may include:

• (a) application purpose;
• (b) target users;
• (c) transaction type;
• (d) data involved;
• (e) expected volume;
• (f) jurisdictions;
• (g) integration architecture; and
• (h) intended services.

47.1 A Developer shall notify StampMitra where its use materially changes from the approved Production use case and the change may affect:

• (a) risk;
• (b) data;
• (c) transaction type;
• (d) legal compliance;
• (e) volume;
• (f) security; or
• (g) service eligibility.

48.1 StampMitra may apply enhanced review to use cases involving:

• (a) regulated financial activity;
• (b) identity verification;
• (c) government services;
• (d) legal documents;
• (e) e-Stamp;
• (f) e-Sign;
• (g) sensitive information;
• (h) large-scale automated processing;
• (i) high transaction volumes;
• (j) children;
• (k) critical services; or
• (l) other high-risk activities.

49.1 StampMitra may reject or restrict use cases involving:

• (a) fraud;
• (b) identity theft;
• (c) impersonation;
• (d) document forgery;
• (e) unauthorized surveillance;
• (f) unlawful data harvesting;
• (g) credential theft;
• (h) malicious automation;
• (i) prohibited financial activity;
• (j) unlawful activities;
• (k) circumvention of legal requirements; or
• (l) other prohibited use under applicable policies.

50.1 StampMitra may conduct screening or apply restrictions required by Applicable Law concerning sanctioned or restricted persons, activities or jurisdictions.

51.1 A Developer represents that it has the legal capacity and authority necessary to enter into the applicable agreement.

52.1 An Organization Developer shall ensure that the person administering the account has appropriate authority.

52.2 StampMitra may request evidence of authority.

53.1 Organization accounts may designate administrators.

53.2 Administrators may be responsible for:

• (a) team access;
• (b) API credentials;
• (c) billing;
• (d) Production applications;
• (e) security settings; and
• (f) user management.

54.1 Organization Developers may permit authorized team members to access applicable workspaces.

54.2 Each user should use their own authorized account where supported.

55.1 Developers should not share individual login credentials.

55.2 Organization access should be managed through appropriate team permissions where available.

56.1 Production API credentials shall be treated as confidential security credentials.

56.2 Developers shall store credentials securely and restrict access according to least privilege.

57.1 Sandbox credentials and Production credentials are distinct security environments.

57.2 Developers shall not expose Production credentials in:

• (a) public repositories;
• (b) client-side code;
• (c) browser applications;
• (d) screenshots;
• (e) public documentation;
• (f) support requests; or
• (g) other publicly accessible locations.

58.1 Developers shall immediately take reasonable action if credentials are suspected to be compromised.

58.2 StampMitra may revoke or restrict compromised credentials.

59.1 Production applicants may be required to demonstrate reasonable security practices appropriate to their use case.

60.1 StampMitra may request information concerning:

• (a) authentication;
• (b) authorization;
• (c) credential storage;
• (d) webhook security;
• (e) encryption;
• (f) access control;
• (g) infrastructure; and
• (h) incident response.

61.1 Production Developers using webhooks may be required to implement appropriate webhook authentication or signature verification mechanisms.

62.1 StampMitra may offer or require IP allowlisting for certain Production integrations.

62.2 Requirements may vary by service and risk.

63.1 Production access may be subject to API rate limits, concurrency limits and other resource controls.

63.2 High-volume Developers may be required to coordinate anticipated traffic with StampMitra.

64.1 StampMitra may request expected:

• (a) requests per minute;
• (b) requests per day;
• (c) transaction volume;
• (d) peak traffic;
• (e) concurrency; and
• (f) growth expectations.

65.1 Material increases in traffic may require additional review, capacity planning or commercial arrangements.

66.1 Production access may require billing information where applicable.

66.2 Billing information may include:

• (a) billing name;
• (b) billing address;
• (c) tax information where applicable;
• (d) payment information;
• (e) purchase authorization; and
• (f) invoice information.

67.1 StampMitra may request tax information where required for billing, invoicing or Applicable Law.

67.2 Developers shall provide accurate tax information.

68.1 Where GST information is required for a particular commercial or invoicing purpose, the Developer shall provide accurate information.

68.2 An Individual Developer shall not be required to provide a GST registration number merely because the Developer is an Individual, unless required for the relevant transaction or Applicable Law.

69.1 Payment-related verification may be required for:

• (a) paid services;
• (b) subscriptions;
• (c) API credits;
• (d) Enterprise arrangements;
• (e) refunds; or
• (f) fraud prevention.

70.1 StampMitra may use reasonable fraud-prevention mechanisms during onboarding and Production approval.

70.2 Such mechanisms may include:

• (a) account signals;
• (b) identity verification;
• (c) transaction analysis;
• (d) device or network signals;
• (e) risk scoring; and
• (f) external verification services.

71.1 StampMitra may use automated systems to assist onboarding, risk assessment, fraud detection or verification.

71.2 Where required by Applicable Law, appropriate safeguards may be applied to automated decision-making.

72.1 StampMitra may perform manual review where:

• (a) automated verification fails;
• (b) risk is elevated;
• (c) information conflicts;
• (d) the use case is complex;
• (e) Production access is sensitive; or
• (f) Applicable Law requires review.

73.1 A review may result in:

• (a) approval;
• (b) conditional approval;
• (c) additional information request;
• (d) restricted approval;
• (e) rejection;
• (f) suspension; or
• (g) escalation.

74.1 StampMitra may grant Production access subject to conditions.

74.2 Conditions may include:

• (a) lower limits;
• (b) restricted APIs;
• (c) additional authentication;
• (d) IP restrictions;
• (e) enhanced monitoring;
• (f) additional verification; or
• (g) other risk controls.

75.1 Approval for one API or service does not automatically authorize access to every StampMitra API.

75.2 Additional verification may be required for specific APIs.

76.1 Services involving:

• (a) e-Stamp;
• (b) e-Sign;
• (c) identity verification;
• (d) government-connected systems;
• (e) financial transactions; or
• (f) regulated data

may require additional verification.

77.1 Production access may be restricted by API scopes.

77.2 A Developer shall use only scopes authorized for its application.

78.1 StampMitra may apply least-privilege principles to Production access.

78.2 Developers should request only the API capabilities required for their legitimate use.

79.1 StampMitra may display a verification status such as:

• (a) Unverified;
• (b) Email Verified;
• (c) Mobile Verified;
• (d) Identity Verified;
• (e) Organization Verified;
• (f) Production Eligible;
• (g) Production Approved;
• (h) Restricted; or
• (i) Suspended.

80.1 Any verification indicator displayed by StampMitra represents only the scope of verification actually completed.

80.2 Verification shall not be interpreted as an endorsement of a Developer's business, application or products.

81.1 StampMitra may require re-verification where:

• (a) information changes;
• (b) credentials are compromised;
• (c) suspicious activity occurs;
• (d) the use case changes;
• (e) the account remains inactive for a material period;
• (f) law changes;
• (g) risk increases; or
• (h) Production access requires periodic review.

82.1 High-risk or Enterprise accounts may be reviewed periodically.

82.2 The frequency of review may vary according to risk and contractual requirements.

83.1 Organization Developers shall notify StampMitra of material changes in ownership or control where required by the applicable agreement or verification requirements.

84.1 Material changes to an authorized representative may require re-verification.

85.1 Developer accounts shall not be transferred to another person or organization without appropriate authorization.

85.2 StampMitra may require a new verification process following a material transfer.

86.1 An organization undergoing merger, acquisition, reorganization or material ownership change may be required to provide updated information.

87.1 Developers shall maintain accurate legal and commercial information.

87.2 Material name changes may require updated documentation.

88.1 Developers shall update material registered or business address information where required for verification, billing or legal compliance.

89.1 StampMitra may review an organization's website or application to understand:

• (a) business activity;
• (b) intended use;
• (c) customer-facing services;
• (d) API integration;
• (e) compliance signals; and
• (f) legitimacy.

90.1 StampMitra may review the Developer's application, technical documentation or integration where reasonably necessary for Production approval.

91.1 A Developer using StampMitra for a client project may be asked to provide information concerning:

• (a) client authorization;
• (b) application ownership;
• (c) intended users;
• (d) data flow;
• (e) API purpose; and
• (f) security responsibilities.

92.1 White-labeling, resale or commercial redistribution may require separate authorization or contractual arrangements.

92.2 Production approval for ordinary API use does not automatically authorize resale.

93.1 Developers operating multi-tenant applications shall implement appropriate isolation between their customers.

93.2 The Developer remains responsible for its own tenant security.

94.1 Developer verification does not automatically verify the Developer's End Users.

94.2 Where an API service requires End User verification, the Developer shall comply with the relevant service requirements.

95.1 Developers shall obtain any consent, authorization or notice required before submitting End User information to StampMitra.

96.1 Developers shall submit only data reasonably necessary for the selected API service.

97.1 Developers shall not use Production APIs to process children's Personal Data unless the processing is lawful and expressly permitted under the applicable service and law.

98.1 Sensitive or high-risk Personal Data may be subject to additional controls.

98.2 StampMitra may reject use cases involving unnecessary or unlawful submission of sensitive information.

99.1 Developers shall not submit identity documents unless required for the relevant service or verification process.

99.2 Identity documents shall be submitted only through authorized StampMitra channels.

100.1 Developers shall not upload:

• (a) malware;
• (b) malicious scripts;
• (c) unauthorized documents;
• (d) fabricated documents;
• (e) unnecessary sensitive information; or
• (f) content prohibited by applicable policies.

101.1 Documents and verification information shall be submitted only through official StampMitra channels.

101.2 Developers should not send verification documents to unverified persons claiming to represent StampMitra.

102.1 StampMitra shall not ordinarily request a Developer's bank, card, UPI or financial-account OTP through an associate, freelancer, agent or ordinary support communication.

102.2 Developers should not disclose such OTPs to any person claiming to assist with StampMitra onboarding.

103.1 Developers may independently engage consultants, associates or technical service providers to assist with integration.

103.2 Such persons do not automatically become authorized StampMitra representatives.

103.3 Developers remain responsible for protecting their credentials and account information.

104.1 Developers shall not provide API secret keys, passwords, OTP credentials or other security credentials to third-party associates merely because such associates assist with onboarding.

105.1 Developers should verify that onboarding or support communications originate through an authorized StampMitra channel.

106.1 Account recovery may require verification of identity, registered contact information or other account-security information.

107.1 StampMitra may refuse or delay account recovery where ownership cannot reasonably be established.

108.1 A compromised account may be temporarily restricted until security is restored.

109.1 StampMitra may restrict onboarding where it identifies indications of:

• (a) identity fraud;
• (b) impersonation;
• (c) document manipulation;
• (d) automated abuse;
• (e) malicious activity;
• (f) payment fraud;
• (g) prohibited use; or
• (h) other material risk.

110.1 Developers shall not create multiple accounts for the purpose of:

• (a) evading restrictions;
• (b) bypassing rate limits;
• (c) obtaining promotional benefits improperly;
• (d) avoiding verification;
• (e) circumventing suspension; or
• (f) concealing prohibited activity.

111.1 Multiple accounts may be permitted where legitimately required for:

• (a) separate organizations;
• (b) separate projects;
• (c) development environments;
• (d) client segregation; or
• (e) other authorized purposes.

112.1 StampMitra may support workspaces or projects within an account.

112.2 Workspace ownership and access shall be managed according to applicable platform controls.

113.1 Individual projects may require separate verification where their risk or use case differs materially from the Developer's existing approval.

114.1 Developers shall maintain appropriate separation between:

• (a) Sandbox;
• (b) testing;
• (c) staging; and
• (d) Production

environments.

115.1 Developers shall not use real Production Personal Data in Sandbox unless expressly permitted by StampMitra and Applicable Law.

116.1 Developers should use synthetic, test or appropriately anonymized data in Sandbox.

117.1 Sandbox credentials shall not be used to access Production systems.

118.1 Production credentials shall not be used in insecure or public development environments.

119.1 Developers shall follow current StampMitra API documentation and applicable integration requirements.

120.1 Production access may be limited to supported API versions.

120.2 Deprecated or retired API versions may not be eligible for new Production access.

121.1 Production access may require compliance with applicable security requirements including:

• (a) HTTPS;
• (b) credential protection;
• (c) webhook validation;
• (d) secure storage;
• (e) access control;
• (f) appropriate logging; and
• (g) incident response.

122.1 StampMitra may require additional security information for high-risk integrations.

122.2 StampMitra does not guarantee that security review detects every vulnerability in a Developer's application.

123.1 Developers shall report StampMitra security vulnerabilities according to the applicable Security Vulnerability Disclosure Policy.

124.1 Production applicants shall not conduct penetration testing against StampMitra or external provider systems without appropriate authorization.

125.1 High-volume or load testing may require prior authorization.

125.2 Developers shall not use Production as an uncontrolled load testing environment.

126.1 StampMitra may require reasonable traffic estimates before activating high-volume Production access.

127.1 StampMitra may coordinate capacity planning with Developers whose expected traffic may materially affect service resources.

128.1 Production approval may be conditional upon:

• (a) completion of verification;
• (b) security requirements;
• (c) acceptable use;
• (d) payment requirements;
• (e) technical readiness;
• (f) API-specific approval; and
• (g) other applicable conditions.

129.1 Production approval may be communicated through:

• (a) Developer Portal;
• (b) email;
• (c) account dashboard;
• (d) contractual notice; or
• (e) another authorized channel.

130.1 StampMitra may reject an application where:

• (a) information is materially false;
• (b) verification cannot be completed;
• (c) the use case is prohibited;
• (d) legal requirements cannot be satisfied;
• (e) security risk is unacceptable;
• (f) required documentation is not provided;
• (g) the service is unavailable for the proposed use; or
• (h) other legitimate grounds exist.

131.1 StampMitra may invite the Developer to correct deficiencies before reconsideration where appropriate.

132.1 A Developer may reapply after addressing the reasons for rejection where reapplication is permitted.

133.1 A Developer may request review of an onboarding or verification decision through the applicable support or grievance channel.

133.2 Review does not guarantee reversal of the original decision.

134.1 Verification-related grievances shall be handled according to the StampMitra Developer Grievance Redressal Policy.

135.1 StampMitra may temporarily restrict Production access while verification or security concerns are investigated.

136.1 Immediate restrictions may be imposed where necessary to protect:

• (a) security;
• (b) Personal Data;
• (c) End Users;
• (d) financial transactions;
• (e) government-connected services;
• (f) e-Stamp services;
• (g) e-Sign services; or
• (h) other critical systems.

137.1 Access may be restored after:

• (a) verification;
• (b) remediation;
• (c) credential rotation;
• (d) compliance confirmation;
• (e) risk review; or
• (f) other appropriate conditions.

138.1 StampMitra may require periodic confirmation of:

• (a) account information;
• (b) organization information;
• (c) use case;
• (d) security information;
• (e) authorized representatives; or
• (f) Production eligibility.

139.1 StampMitra may apply security measures to inactive accounts, including credential rotation or access restrictions.

140.1 Reactivation of an inactive account may require additional verification.

141.1 A material security event may trigger re-verification.

142.1 A material data breach involving an account may trigger additional security verification before continued Production access.

143.1 Changes in law or regulatory requirements may require additional onboarding or verification information.

144.1 Certain services may require information beyond ordinary Developer onboarding.

144.2 Developers shall provide such information where required for the relevant service.

145.1 Access to government-connected or regulated services may require additional verification or eligibility checks.

146.1 e-Stamp-related API access may be subject to service, jurisdiction, document and transaction-specific requirements.

147.1 e-Sign-related API access may require additional identity, authentication, authorization or technical requirements.

148.1 Verification APIs may be subject to additional restrictions to prevent unauthorized data access, harvesting or misuse.

149.1 Payment-related API functionality may require additional commercial, technical or compliance requirements.

150.1 StampMitra may separately approve API scopes based on:

• (a) use case;
• (b) risk;
• (c) verification;
• (d) service eligibility; and
• (e) contractual terms.

151.1 Higher limits may require:

• (a) Production history;
• (b) traffic information;
• (c) security review;
• (d) commercial arrangements;
• (e) capacity assessment; or
• (f) other requirements.

152.1 StampMitra may require additional controls for high-volume Developers.

153.1 Enterprise Developers may be subject to additional onboarding under an executed Enterprise API Agreement or Order Form.

154.1 Enterprise verification may include:

• (a) corporate information;
• (b) authorized signatories;
• (c) security documentation;
• (d) compliance information;
• (e) expected usage;
• (f) technical architecture; and
• (g) commercial information.

155.1 StampMitra may conduct reasonable due diligence appropriate to the Developer's risk profile.

156.1 Where a Developer is acting on behalf of another organization, StampMitra may request reasonable evidence of authorization.

157.1 Developers shall maintain evidence of client authorization where they access StampMitra services for a client.

158.1 A Developer shall not falsely claim to represent:

• (a) a company;
• (b) government authority;
• (c) financial institution;
• (d) legal entity;
• (e) customer; or
• (f) other organization.

159.1 Impersonation during onboarding may result in immediate rejection, suspension or termination.

160.1 Submission of forged or materially altered verification documents may result in immediate action and may be reported to appropriate authorities where required.

161.1 StampMitra may cooperate with lawful authorities regarding fraudulent onboarding or identity misuse.

162.1 Where legally required or operationally appropriate, StampMitra may perform sanctions or restricted-party screening.

163.1 Where required for a regulated service or applicable legal framework, StampMitra may request additional information concerning relevant risk factors.

163.2 Such requests shall be applied according to the relevant service and Applicable Law.

164.1 Personal information collected during onboarding shall be processed according to the StampMitra Developer Privacy Policy and Applicable Data Protection Law.

165.1 StampMitra's role in Processing onboarding information may differ from its role in Processing API-submitted End User data.

165.2 Role shall be determined according to the actual Processing activity.

166.1 Onboarding information may include:

• (a) identity information;
• (b) contact information;
• (c) account information;
• (d) organization information;
• (e) verification information;
• (f) security information;
• (g) billing information;
• (h) use-case information;
• (i) technical information; and
• (j) compliance information.

167.1 Onboarding information shall be used for purposes such as:

• (a) account creation;
• (b) identity verification;
• (c) Production approval;
• (d) fraud prevention;
• (e) security;
• (f) billing;
• (g) legal compliance;
• (h) service provisioning; and
• (i) support.

168.1 StampMitra shall seek to collect information proportionate to the onboarding and verification purpose.

169.1 Developers shall maintain accurate onboarding information.

170.1 Developers shall update material information when it changes or when StampMitra reasonably requests confirmation.

171.1 Onboarding and verification records may be retained for the period reasonably necessary for:

• (a) service operation;
• (b) security;
• (c) fraud prevention;
• (d) contractual records;
• (e) legal compliance;
• (f) dispute resolution; and
• (g) audit.

172.1 Data may be deleted or anonymized when no longer required, subject to applicable retention requirements.

173.1 Certain information may need to be retained longer due to:

• (a) legal obligations;
• (b) regulatory requirements;
• (c) taxation;
• (d) accounting;
• (e) fraud prevention;
• (f) litigation; or
• (g) other lawful purposes.

174.1 StampMitra shall apply reasonable security measures appropriate to the sensitivity of onboarding information.

175.1 Access to verification information shall be restricted to authorized personnel or service providers with a legitimate business need, subject to applicable law and contract.

176.1 StampMitra may use authorized external verification or data source providers.

176.2 Such providers may process limited information necessary for the relevant verification.

177.1 StampMitra may protect the identity and commercial details of external verification providers where appropriate.

178.1 Verification information may be processed outside India where permitted by Applicable Law and the relevant service arrangement.

179.1 Developers may exercise applicable privacy and data protection rights according to the StampMitra Developer Privacy Policy and Applicable Law.

180.1 An automated verification failure does not necessarily mean that the Developer is ineligible.

180.2 StampMitra may request additional information or perform manual review where appropriate.

181.1 Manual review shall seek to evaluate submitted information according to the relevant eligibility criteria and available evidence.

182.1 StampMitra does not guarantee approval merely because a Developer has:

• (a) completed Sandbox testing;
• (b) submitted documents;
• (c) paid a fee;
• (d) provided an application;
• (e) used another StampMitra service; or
• (f) previously held Production access.

183.1 Production approval may be withdrawn where:

• (a) eligibility changes;
• (b) information becomes inaccurate;
• (c) material risk emerges;
• (d) prohibited activity occurs;
• (e) credentials are compromised;
• (f) legal requirements change; or
• (g) other legitimate grounds exist.

184.1 StampMitra may temporarily restrict access while reviewing:

• (a) verification;
• (b) security;
• (c) fraud;
• (d) legal;
• (e) billing; or
• (f) operational concerns.

185.1 Suspension shall be governed by the Developer Terms, Acceptable Use Policy, API Lifecycle Policy and other applicable agreements.

186.1 Termination shall be governed by the applicable contractual framework.

186.2 Termination does not necessarily require deletion of all records immediately where lawful retention applies.

187.1 StampMitra may restrict reapplication following termination for fraud, abuse, security violations or other serious misconduct.

188.1 A Developer may seek internal review of an onboarding decision through an authorized channel where available.

189.1 Review does not create an automatic right to approval, reinstatement or Production access.

190.1 Formal grievances shall be handled under the Developer Grievance Redressal Policy.

191.1 Customer or technical support does not automatically have authority to approve Production access.

191.2 Production approval shall be performed through authorized processes.

192.1 Developers shall not rely on verbal, informal or unofficial representations that Production access has been approved.

193.1 Production approval is effective only when recorded through an authorized StampMitra system or written contractual communication.

194.1 StampMitra may communicate onboarding requirements through:

• (a) Developer Portal;
• (b) email;
• (c) account dashboard;
• (d) contractual communication;
• (e) support ticket; or
• (f) another authorized channel.

195.1 Developers should verify onboarding communications before submitting sensitive information.

195.2 StampMitra shall not ordinarily request passwords, API secret keys or OTPs through ordinary onboarding communications.

196.1 StampMitra may update this Policy to reflect:

• (a) legal changes;
• (b) security improvements;
• (c) service changes;
• (d) verification requirements;
• (e) technology changes;
• (f) regulatory requirements; or
• (g) operational improvements.

197.1 Material changes shall be communicated according to applicable contractual requirements.

198.1 Policy updates shall not retroactively alter rights or obligations already accrued unless legally permitted and contractually applicable.

199.1 This Policy shall be read with:

• (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;
• (i) Verification, e-Stamp & e-Sign Service Terms;
• (j) API Versioning, Suspension & Deprecation Policy;
• (k) Developer Grievance Redressal Policy;
• (l) Security Vulnerability Disclosure Policy;
• (m) Cookie & Tracking Policy;
• (n) Developer Data Retention & Deletion Schedule;
• (o) API Documentation & Developer License Terms;
• (p) Enterprise API Agreement / Order Form;
• (q) Subprocessor / Service Provider Disclosure Framework; and
• (r) Incident & Breach Notification Procedure.

200.1 In case of conflict:

• (a) mandatory Applicable Law shall prevail;
• (b) executed Enterprise or commercial agreements shall prevail where expressly inconsistent;
• (c) the DPA shall govern Personal Data Processing;
• (d) the Developer Terms shall govern general contractual matters;
• (e) service-specific terms shall govern specific service eligibility;
• (f) this Policy shall govern onboarding and verification matters.

201.1 If any provision is held invalid or unenforceable, the remaining provisions shall continue to the extent permitted by law.

202.1 Failure to enforce a requirement does not constitute a permanent waiver.

203.1 This Policy shall be governed by the laws of India, subject to applicable mandatory statutory requirements.

203.2 Dispute resolution shall be governed by the applicable Developer Terms, DPA, Order Form or other executed agreement.

204.1 Onboarding, verification and legal questions may be directed to:

Legal Team

BANI GLOBAL INDUSTRIES LLP

Email: [email protected]

205.1 By registering for or using the StampMitra Developer Platform, the Developer acknowledges that:

• (a) Sandbox onboarding may be designed as a low-friction process;
• (b) Production access may require enhanced verification;
• (c) Individual Developers may legitimately onboard as individuals;
• (d) Organizations may be required to establish authority;
• (e) submitted information must be accurate;
• (f) false or fraudulent information is prohibited;
• (g) Production approval is not automatic;
• (h) StampMitra may conduct risk-based verification;
• (i) additional information may be requested;
• (j) verification may be performed using authorized external systems;
• (k) access may be restricted for security, legal or compliance reasons;
• (l) credentials must be protected;
• (m) API access is subject to applicable policies; and
• (n) continued access may depend upon continued eligibility.

• Policy Name: StampMitra Developer Onboarding & Verification Policy
• Policy Number: 19 of 19
• Version: 1.0
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026
• Operator: BANI GLOBAL INDUSTRIES LLP
• LLPIN: ACI6373
• Legal Contact: [email protected]
• Prepared By: Legal Team, BANI GLOBAL INDUSTRIES LLP
• Status: FINAL — PUBLISHED POLICY