Privacy Policy

Razorpay Software Limited — Agent Studio & Slash

PART A — GENERAL PROVISIONS

1. Introduction

Razorpay Software Limited (“RSL”, “we”, “us” or “our”) operates agentic artificial-intelligence software products through which AI-powered software agents (“Agents”) execute queries and tasks on behalf of a business that has signed up for the relevant services (the “Merchant”, “you” or “your”). Each such product (a “Product”) is described in a Product Annex in Part B of this Policy.

This Privacy Policy (the “Policy”) is the single privacy policy of RSL. It explains how RSL collects, uses, discloses, secures, retains and otherwise processes Personal Data in connection with the Products, and the respective responsibilities of RSL and the Merchant in relation to that data. It is designed to reflect RSL’s role as a data processor and third-party service provider (“TSP”) that provides Agent infrastructure and Agents for the Merchant’s convenience, and to give effect to RSL’s obligations under the Digital Personal Data Protection Act, 2023 (“DPDPA”) and other applicable laws of India (“Applicable Law”).

This Policy forms part of, and should be read together with, the terms and conditions applicable to each Product (the “Terms”) and is incorporated into the Terms by reference. Capitalised terms not defined here have the meaning given to them in the Terms. In the event of a conflict between this Policy and the Terms on a data-protection matter, this Policy prevails to the extent of the conflict, unless the Terms expressly state otherwise. “Data Fiduciary”, “Data Processor” and “Data Principal” have the meanings given to them in the DPDPA.

2. Structure of this Policy

RSL maintains this single Policy for all of its Products. It has two parts:

• Part A (this part) contains the general provisions that apply to every Product: RSL’s roles, common definitions, the consent and authorization framework, AI-processing terms, disclosure and sub-processing, cross-border transfers, security, retention, Data Principal rights, breach notification, Merchant responsibilities, grievance redressal and governing law.
• Part B contains one Product Annex per Product. Each Annex describes that Product, the categories of Personal Data it processes, its permitted purposes, how its Agents act and are governed, and any retention, localisation or responsibility provisions specific to it.

Each Product Annex forms an integral part of this Policy for the corresponding Product. In the event of a conflict between Part A and a Product Annex in respect of that Product, the Product Annex prevails to the extent of the conflict. When RSL introduces a new Product, a new Product Annex is added to Part B and the cover page is updated, without altering the provisions of Part A except where expressly stated; such an addition takes effect in accordance with Section 15 (Changes to this Policy).

3. Scope and Applicability

This Policy applies to all Personal Data that RSL processes in the course of making the Products and their Agents available, including data:

• accessed or retrieved from Authorized Data Sources pursuant to a valid Merchant Authorization;
• provided to RSL directly by the Merchant or its authorised representatives (for example, during sign-up, configuration of Agents and connectors, or through a Product’s dashboard or API);
• processed by Agents on the Merchant’s behalf, including data relating to the Merchant’s customers, end users, personnel or contractors, as described in the applicable Product Annex; and
• generated by a Product in the course of operating the Agents, such as Service Outputs, audit-trail records and operational telemetry.

Where the Merchant also uses other Razorpay group products, the privacy notice applicable to those products (available at https://razorpay.com/privacy/) continues to apply to those products. This Policy does not govern the independent data-handling practices of Authorized Data Sources, third-party AI model providers or the Merchant itself, each of which is responsible for its own compliance under its own terms.

4. Our Role — Data Processor / TSP

Each Product involves two distinct roles for RSL:

4.1 RSL as Data Processor / TSP (Merchant-side data)

With respect to Personal Data processed through the Agents on the Merchant’s behalf, as identified in the applicable Product Annex (“Merchant-Side Data”, which may comprise End Customer Data, Merchant Content or both), the Merchant is the Data Fiduciary and RSL is the Data Processor acting on the Merchant’s behalf and under its documented instructions, engaged under a valid contract in accordance with Section 8(2) of the DPDPA. RSL provides the Agent infrastructure and Agents as a technology and software service; it determines neither why the Merchant engages with the individuals concerned nor the underlying commercial purpose of that engagement. RSL processes End Customer Data to deliver the Services the Merchant has configured, for the Permitted Purpose and in accordance with the Merchant’s instructions (as covered in this Policy).

The Merchant’s documented instructions to RSL comprise: (a) the Terms; (b) this Policy, including the applicable Product Annex; (c) the Merchant Authorization(s) granted through the Product; (d) the Merchant’s configuration of Agents, connectors, approval gates, scopes and thresholds; (e) the Merchant using the Product and submitting requests or tasks to the Agents; and (f) any further written instructions issued through the dashboard. RSL will process Merchant-Side Data only on such instructions, except where Applicable Law requires otherwise, in which case RSL will inform the Merchant of that legal requirement before processing, unless the law prohibits such notice.

4.2 RSL as Data Fiduciary (limited data)

With respect to the Personal Data of the Merchant’s authorised representatives and account users that RSL collects to establish and operate the Merchant’s account, for example, names, work email addresses, phone numbers (including numbers used for two-factor authentication), sign-in and authentication records, roles and memberships, and dashboard-usage records (collectively the “Account User Data”), RSL is the Data Fiduciary. For that limited category of data, RSL is directly responsible to those individuals as Data Principals under the DPDPA, and the provisions of this Part A apply to RSL directly.

4.3 What this means in practice

5. Common Definitions

The following terms are used throughout this Policy. Each Product Annex may define additional Product-specific terms. Other capitalised terms carry the meaning given in the Terms.

6. Consent and Merchant Authorization

Merchant Authorization. The Merchant grants RSL explicit, specific and revocable authorization, through the applicable Product or another mechanism RSL designates, to access, retrieve, process, store and use Merchant-Side Data from named Authorized Data Sources, solely for that Product’s Permitted Purpose. A Merchant Authorization constitutes part of the Merchant’s documented processing instructions to RSL. Each Product Annex describes the authorization mechanisms specific to that Product.

Account user consent. At sign-up, RSL presents account users with a notice in accordance with Sections 5 and 6 of the DPDPA, describing the Account User Data collected and the purpose of processing, the manner in which they may exercise their rights, and the manner in which they may complain to the Data Protection Board of India. The notice is available in English and, on request, in any language specified in the Eighth Schedule to the Constitution of India.

Consent for Merchant-Side Data is the Merchant’s responsibility. Because the Merchant is the Data Fiduciary for Merchant-Side Data, the Merchant is solely responsible for establishing and maintaining a lawful basis under the DPDPA and other Applicable Law, including all required notices and consents, before such data is disclosed to, or processed by, RSL. The Merchant warrants that its disclosure of Merchant-Side Data to RSL does not violate Applicable Law.

Disclosure of automated systems. Where an Agent interacts with, sends communications to, or processes content authored by individuals, the Merchant is solely responsible for disclosing to those individuals, in clear and conspicuous language, that automated AI systems are used, where such disclosure is required by Applicable Law or by the Merchant’s own commitments. RSL is not responsible for the adequacy of the Merchant’s disclosures.

Withdrawal and revocation. The Merchant may at any time, through the applicable dashboard or connected surface, disable any specific Agent, revoke any Merchant Authorization, or disconnect any connector, without affecting other elements of the Services. On revocation, RSL will cease invoking the relevant Agent for the Merchant and will retain the associated audit trail as described in Section 11. As a technical limitation, a pause or revocation prevents Agents from starting a fresh run; an Agent run already in progress will complete or may be cancelled using the controls the Product provides. Product-specific revocation mechanics are described in the applicable Annex.

7. Automated Processing and AI

The Products are built on agentic AI technology and may incorporate or be powered by AI models operated by RSL and by third-party providers. RSL is responsible for the integration and configuration of such models and for data minimisation in AI processing.

Service Outputs are generated by AI models and are non-deterministic; they may contain inaccuracies and may resemble outputs generated for other Merchants. The Merchant must independently verify Service Outputs before relying on them for business-critical decisions, and must not use them as the sole basis for decisions relating to credit, employment, insurance or other regulated outcomes unless the Merchant is itself authorised to make such decisions and has independently verified the output. The Merchant must not use Agent outputs, without meaningful human review, to make decisions producing a legal or similarly significant effect on a Data Principal.

The current list of third-party AI model providers, the data shared with them and their respective regions of processing is maintained in the Sub-Processor Registry. RSL applies data minimisation so that only data necessary for the requested Service is shared with a model provider. RSL contractually requires model providers engaged as Sub-Processors to observe data-protection obligations equivalent to those in this Policy and, where applicable, not to train their foundation models on the Merchant’s data other than as permitted.

Guardrails. RSL maintains content and safety guardrails appropriate to each Product, including filters against the generation of unlawful, defamatory, discriminatory or sexually explicit content and, where applicable, defences against malicious instructions embedded in processed content. The Merchant must not attempt to bypass these guardrails.

8. Sensitive and Children’s Data

The Products are business tools and are not designed to process special categories of data or the Personal Data of children. The Merchant must not upload or query, and must not configure Agents to process, Personal Data of children or persons with a lawful guardian, or otherwise sensitive Personal Data, except where it is strictly necessary for a Service and the Merchant has obtained all consents required under Applicable Law (see Sections 6 and 13).

9. Purposes of Processing

As a Data Processor, RSL processes Merchant-Side Data only for the purposes for which the Merchant, as Data Fiduciary, has instructed it. Those purposes (the “Permitted Purpose”) are described per Product in the applicable Annex and in each case include:

• Delivering the Services the Merchant has configured for that Product, including Authorised Purpose (as defined in the Terms);
• Operating and securing the Product: authentication, access control, tenant isolation, rate limiting, maintaining audit trails, monitoring for malfunction, fraud, abuse and security threats, and pausing, cancelling or overriding Agents where necessary;
• Metering and billing: measuring usage and cost for attribution, plan limits and invoicing; and
• Improving the Services and analytics: using current or historic data to improve Agent behaviour, models, routing and guardrails, while de-identifying and anonymising Personal Data where required, and using aggregated, de-identified data for analytics and service improvement.

RSL will not process Merchant-Side Data for any purpose that is incompatible with the Permitted Purpose or the Merchant’s instructions. For Account User Data, RSL processes such data for account administration, service delivery, security, legal compliance and service communications, on the basis of the consent obtained at sign-up or another lawful basis under the DPDPA (including Section 7(a) of the DPDPA where the individual has voluntarily provided the data for the specified purpose).

10. Disclosure of Personal Data and Sub-Processors

RSL discloses Personal Data only as necessary to deliver the Services and for the Permitted Purpose, to the following categories of recipients:

• Sub-Processors — third parties (including AI model providers, cloud-hosting, communication-delivery and security providers) engaged by RSL to help deliver the Services, as listed in the Sub-Processor Registry. RSL imposes on each Sub-Processor data-protection obligations that are at least equivalent to those in this Policy.
• Authorized Data Sources — to the extent necessary to execute an action the Merchant has instructed.
• Razorpay group systems and affiliates — to the extent authorised by the Merchant under the Terms and permitted by Applicable Law, and subject to equivalent protections, including shared Razorpay platform systems (such as identity and account infrastructure) described in the applicable Product Annex.
• Professional advisors, auditors and regulators — where required to demonstrate compliance, or where compelled by Applicable Law or a competent authority.
• Successors — in connection with a merger, acquisition or sale of all or substantially all of RSL’s assets, subject to notice as required under the Terms.

Sub-Processor changes. RSL maintains the Sub-Processor Registry and updates it when Sub-Processors are added or replaced. Where a change is reasonably likely to affect the processing of the Merchant’s Personal Data materially, RSL will notify the Merchant through the dashboard or by email.

11. Audit Trail

RSL maintains an append-only audit trail of Agent activity under the Merchant’s account for each Product, recording (among other things) the invocation identifier, timestamp, trigger source, Agent and model invoked, the Sub-Processor providing the model, the inputs, outputs and actions taken, and the outcome. The Merchant can view, search and export its own audit trail through the dashboard or an API. Access to audit trails within RSL is restricted to a named control population on a least-privilege basis and is itself logged.

12. Cross-Border Transfers

Some Sub-Processors, including certain AI model providers, may process Personal Data outside India. RSL transfers Personal Data outside India only to countries not restricted by the Central Government under Section 16 of the DPDPA and subject to Applicable Law, and only where the recipient is bound by data-protection obligations equivalent to those in this Policy. The regions in which each Sub-Processor processes data are recorded in the Sub-Processor Registry. Product-specific localisation commitments (for example, for financial data or identity data) are set out in the applicable Product Annex.

13. Data Security

RSL implements industry-standard technical and organisational security measures designed to protect Personal Data against unauthorised or unlawful access, loss, alteration, disclosure or destruction, in accordance with Section 8(5) of the DPDPA. These measures include, as appropriate:

• encryption of data in transit and at rest, and secure key management;
• role-based access controls on a least-privilege basis, with authentication and access logging;
• network security, monitoring and threat-detection controls, tenant isolation, and the ability to pause or override malfunctioning Agents;
• confidentiality obligations binding all personnel authorised to process Personal Data;
• secure software-development practices, content guardrails and data-minimisation controls in AI processing; and
• periodic testing, review and independent audit or certification of security controls.

The Merchant is responsible for safeguarding its own API credentials, access tokens and authentication details, for configuring approval gates, scopes and access appropriately, and for notifying RSL immediately of any actual or suspected unauthorised access to its account. No method of transmission or storage is completely secure, and RSL cannot guarantee absolute security.

14. Data Retention and Deletion

RSL retains Personal Data only for as long as necessary to fulfil the Permitted Purpose and to comply with Applicable Law, consistent with Section 8(7) of the DPDPA. The following framework applies to every Product; Product-specific retention rows appear in the applicable Annex:

On expiry of the applicable retention period, RSL deletes, anonymises or de-identifies the relevant Personal Data. Where deletion is not technically feasible immediately (for example, in secure backups), RSL isolates the data from further processing until deletion is possible.

15. Data Principal Rights and Assistance to the Merchant

The DPDPA gives Data Principals rights in respect of their Personal Data, including the right to access information about processing (Section 11), the right to correction and erasure (Section 12), the right to grievance redressal (Section 13), and the right to nominate another individual to exercise their rights (Section 14).

For Merchant-Side Data (RSL as Processor): because the Merchant is the Data Fiduciary, requests from the individuals concerned should be directed to, and are the responsibility of, the Merchant. Where such an individual contacts RSL directly, RSL will, unless legally required to act, refer the request to the relevant Merchant. RSL will provide reasonable assistance to the Merchant, through appropriate technical and organisational measures and taking into account the nature of the processing, to enable the Merchant to respond to Data Principal requests and to meet its obligations under the DPDPA.

For Account User Data (RSL as Fiduciary): the individual may exercise their DPDPA rights directly with RSL by contacting the Data Protection Officer (Section 18). RSL will respond within the timelines prescribed under Applicable Law and may verify the identity of the requester before acting.

16. Personal Data Breach Notification

RSL maintains procedures to detect, investigate and respond to personal data breaches. On becoming aware of a personal data breach affecting Merchant-Side Data, RSL will notify the Merchant without undue delay, and in any event as required to enable the Merchant, as Data Fiduciary, to meet its own notification obligations to the Data Protection Board of India and affected Data Principals under Section 8(6) of the DPDPA. RSL’s notification will include, to the extent available, the nature of the breach, the categories and approximate volume of data affected, the likely consequences and the measures taken or proposed. For Personal Data where RSL is the Data Fiduciary, RSL will itself make any notifications required under Applicable Law.

17. Merchant Responsibilities as Data Fiduciary

Because the Merchant is the Data Fiduciary for Merchant-Side Data, the Merchant is responsible for, and warrants that it will:

• establish and maintain a lawful basis, and provide all notices and consents, required under the DPDPA and other Applicable Law before disclosing Merchant-Side Data to RSL or configuring Agents to process it;
• issue lawful processing instructions and configure Agents, connectors, approval gates, scopes and thresholds appropriately for its business;
• disclose the use of automated systems to affected individuals where required, and honour opt-outs;
• not use Agents to process children’s data or sensitive Personal Data except as strictly necessary and lawfully consented;
• respond to Data Principal requests and grievances relating to Merchant-Side Data; and
• comply with the Product-specific responsibilities set out in the applicable Product Annex.

RSL provides the technical means to deliver the Services; responsibility for compliance with data-protection and sector regulations in respect of the individuals concerned rests with the Merchant.

18. Grievance Redressal, Data Protection Officer and Contact

Your privacy is important to us. Any questions, complaints or requests regarding the processing of Personal Data under this Policy may be addressed to our Data Protection Officer or Nodal Officer using the details below.

We aim to acknowledge and resolve grievances within the timelines prescribed under Applicable Law. A Data Principal must first exhaust the grievance-redressal mechanism above; if a Data Principal is not satisfied with the resolution, they may have the right to approach the Data Protection Board of India in accordance with the DPDPA.

19. Changes to this Policy

RSL may update or modify this Policy from time to time, including by adding, amending or withdrawing a Product Annex, to reflect changes in the Products, our practices, or Applicable Law. The updated Policy will be posted with a revised effective date. The Merchant’s continued use of the Services after the effective date of an updated Policy constitutes acceptance of it. We encourage the Merchant to review this Policy periodically.

20. Governing Law and Jurisdiction

This Policy is governed by and construed in accordance with the laws of India, without regard to conflict-of-laws principles. The courts of Bengaluru, Karnataka have exclusive jurisdiction over any dispute arising out of or in connection with this Policy.

PART B — PRODUCT ANNEXES

Annex 1 — Razorpay Agent Studio

A1.1 The Product

Razorpay Agent Studio (the “Platform” for the purposes of this Annex) is an agentic AI platform through which Agents autonomously execute queries and tasks on behalf of the Merchant in relation to its business operations, for example, transaction and settlement queries, dispute and chargeback response, subscription recovery, abandoned-cart re-engagement, RTO/COD risk screening, cashflow insights, customer-support automation, and Merchant-configured communications to the Merchant’s customers and end users (“End Customers”), as more particularly described in Agent Studio Terms.

Merchant-Side Data for this Product means End Customer Data: all data (including Personal Data) relating to End Customers that is processed by RSL on the Merchant’s behalf, together with Merchant business and transaction data retrieved from Authorized Data Sources.

A1.2 Categories of Personal Data

Voice data and biometric identification. Call recordings, transcripts and related voice data are processed to deliver the Service, for example, call handling, transcription, quality review and dispute resolution, and are not used to create or match voiceprints for biometric identification purposes.

Financial data and payment-instrument data. Where the Services involve financial or payment data originating from RBI-regulated Authorized Data Sources, RSL processes it strictly as a technology service provider and stores it in India. RSL is not a payment system operator or a banking entity, and does not itself hold any such licence.

A1.3 How the Agents act and are governed

• Read Actions — queries, retrievals and analytics that do not transmit data to any third party or initiate any communication.
• Communications Actions — sending email, SMS, WhatsApp, voice or other outbound messages to End Customers.
• Transactional Actions — actions with financial, contractual or regulatory consequence, such as dispute responses, refund initiations, subscription retries and chargeback representments.

The dashboard provides controls by which the Merchant may require manual approval for any class of action, or for any action exceeding a configurable threshold (by monetary value, recipient volume or otherwise). Where the Merchant has not configured such controls, RSL’s default classification (as published in the Agent Studio documentation) applies.

A1.4 Product-specific localisation and retention

All Merchant Data and End Customer Data originating from RBI-regulated Authorized Data Sources is stored in India. In addition to the retention framework in Part A, Section 14:

A1.5 Product-specific Merchant responsibilities

When Agents send communications on the Merchant’s behalf, the Merchant must comply with communications regulations, including DLT registration and approved templates, the WhatsApp Business Solution Policy, TRAI’s Telecom Commercial Communications Customer Preference Regulations, 2018, and the Information Technology Act, 2000. RSL provides the technical means to deliver communications; responsibility for compliance rests with the Merchant.

Annex 2 — Razorpay Slash

A2.1 The Product

Razorpay Slash (the “Platform” for the purposes of this Annex) is an agentic AI software-engineering platform through which Agents perform engineering and knowledge tasks, reviewing pull requests (including security checks), answering questions about the Merchant’s code and documentation, and turning task descriptions into draft code changes, on the Merchant’s own repositories and workspaces, in accordance with Slash Terms. In this Annex, references to the “Merchant” are to the “Customer” as defined in the Slash Terms.

Merchant-Side Data for this Product means Merchant Content: all data (including Personal Data) contained in the code, repositories, pull requests, issues, messages, documents, prompts and task instructions that the Merchant connects to or submits through the Platform. Merchant Content is engineering material and routinely embeds Personal Data incidentally, for example commit author names and email addresses, which RSL processes solely as part of the Merchant Content, as Data Processor, for the Permitted Purpose.

A2.2 Categories of Personal Data

Usage rule. The Merchant should not deliberately route production Personal Data, payment-instrument data or secrets through the Platform; Slash is a software-engineering tool, not a data-processing pipeline for such data.

A2.3 How the Agents act and are governed

• Read Actions — cloning and reading repository contents, retrieving messages, searching, and producing analyses or answers, without changing any Merchant system.
• Write Actions — creating branches, commits and draft pull requests in the Merchant’s repositories, and posting review comments, results and notifications back to the originating surface.
• Execution Actions — running tests, scripts, build steps, or CI checks, or executing commands, where such capability is in scope.
• Restricted Actions — actions outside the configured allowlists are blocked by Platform policy.

Agents never merge code autonomously: code changes are delivered as draft pull requests that a human in the Merchant’s organisation must review and approve before they take effect, and any run can be cancelled mid-flight. Each task executes in an isolated, sandboxed environment scoped to the Merchant’s tenant, using credentials scoped to that Merchant’s installation, with per-tenant secret storage and controlled network egress. RSL maintains layered prompt-injection defences designed to detect and block malicious instructions embedded in Merchant Content, together with per-Merchant allow lists constraining the tools, skills and plugins available to each surface.

A2.4 Authorization and revocation mechanics

Each Merchant Authorization for this Product is scoped: the GitHub App operates only on repositories the Merchant selects, and the Slack app operates only in the workspace where it is installed. The Merchant may revoke by uninstalling the GitHub App or the Slack app, removing a repository from scope, or disconnecting a connector. Removal of an account member is effected on Razorpay’s account platform and, as a technical limitation, becomes fully effective by that member’s next access-token refresh.

A2.5 Product-specific localisation and retention

Identity and account data of Merchant representatives (including phone numbers used for two-factor authentication) is stored in Razorpay’s production systems located in India. Working copies of Merchant repositories exist only for the duration of a task’s execution and are deleted with the task sandbox. Retention of stored Merchant Content, task records and audit-trail entries follows the framework in Part A, Section 14.

A2.6 Product-specific Merchant responsibilities

The Merchant must inform its personnel, where required by Applicable Law or its own policies, that AI Agents operate in the connected repositories and workspace and may process the content they author there; Agent-generated contributions are attributed as such (through the Agent’s bot identity and co-author records). The Merchant must review all Service Outputs, including every draft pull request, through a human before they take effect.