Data Processing Addendum

This Data Processing Addendum ("DPA") is part of the Mercayo Merchant Terms of Service ("Terms") between the Merchant and Wahenam International ("Mercayo"). It applies automatically when the Merchant accepts the Terms. Words defined in the Terms have the same meaning here. If the DPA and the Terms conflict on personal data, the DPA prevails.

1. Definitions

The terms "Data Fiduciary", "Data Processor", "Data Principal", "personal data", "processing", "personal data breach", "consent" and "Board" have the meanings given in section 2 of the Digital Personal Data Protection Act, 2023 ("DPDP Act").

2. Roles

2.1 For Store Personal Data, the Merchant is the Data Fiduciary and Mercayo is its Data Processor. This DPA is the valid contract that section 8(2) of the DPDP Act requires before a Data Fiduciary engages a Data Processor.

2.2 For personal data about the Merchant, its staff and its Mercayo account, Mercayo is a Data Fiduciary, and Mercayo's Privacy Policy applies, not this DPA.

2.3 The Merchant remains responsible for complying with the DPDP Act for Store Personal Data, including where Mercayo processes it (section 8(1)). Each party is responsible for its own obligations under this DPA.

2.4 Until the relevant provisions of the DPDP Act are in force, this DPA also serves as the contract under which the Merchant (a "body corporate", for the purpose of section 43A of the IT Act) has Mercayo collect, receive, store and process information on its behalf, as the SPDI Rules contemplate.

3. Details of the processing

4. Mercayo's obligations as Data Processor

4.1 Instructions. Mercayo processes Store Personal Data only on the Merchant's documented instructions. These are: the Terms, this DPA, the Merchant's configuration of the Service (its settings, switches and connected accounts), and written instructions the Merchant gives through support. The only exception is where Indian law requires Mercayo to do otherwise. In that case Mercayo will tell the Merchant before processing, unless the law forbids it.

Mercayo will tell the Merchant if, in its opinion, an instruction breaks the law. Mercayo may refuse such an instruction.

4.2 No other use. Mercayo will not:

• sell Store Personal Data;
• use it for its own marketing;
• combine it with another store's data;
• use it to profile Data Principals for anyone other than the Merchant.

The limited platform-security records described in section 3.4 of Mercayo's Privacy Policy are the only exception: IP logs, rate-limit counters and abuse signals, kept for security and legal compliance only.

4.3 Confidentiality. Everyone at Mercayo who can access Store Personal Data is bound by confidentiality and given only the access their role needs.

4.4 Security. Mercayo implements the measures in Annex 2, which are reasonable security safeguards under section 8(5) of the DPDP Act and rule 6 of the DPDP Rules. Mercayo may improve them over time, but will not materially weaken them.

4.5 Assistance. Taking into account the nature of the processing, Mercayo helps the Merchant meet its obligations, including for Data Principals' rights (section 7), breaches (section 6), security, and any Board inquiry.

4.6 Support access. Mercayo staff access the Merchant's store admin only as section 8 of the Terms allows. Every support session is recorded in Mercayo's internal log. A Full session cannot see payment keys, manage staff, or bulk export customers unless the task requires it and Mercayo's owner enables it for that session.

4.7 Legal requests. If an authority asks Mercayo for Store Personal Data, Mercayo will:

• check that the request is lawful;
• send the authority to the Merchant where reasonable;
• tell the Merchant, unless the law forbids it;
• disclose only what is legally required.

5. Sub-processors

5.1 General authorisation. The Merchant authorises Mercayo to engage the Sub-processors in Annex 1. Mercayo will ensure that each is bound by a written contract with data-protection obligations no less protective than this DPA. Mercayo remains responsible to the Merchant for each Sub-processor's performance.

5.2 Changes. Mercayo will publish its Sub-processor list at mercayo.com/legal/dpa (Annex 1) and give at least 15 days' notice by email or in the admin before adding or replacing a Sub-processor, except in an emergency (for example, to keep messages flowing if a provider fails). In an emergency, notice follows as soon as possible.

If the Merchant objects on reasonable data-protection grounds, the parties will discuss it in good faith. If they cannot resolve it, the Merchant may end the affected service, or the Terms, and receive a pro-rata refund of prepaid fees.

5.3 Merchant-Connected Services are not Sub-processors. The Merchant chooses them and contracts with them directly. It must have its own agreement with each, covering personal data where needed. Mercayo sends them only what the Merchant's configuration requires.

6. Personal data breaches

6.1 Notice to the Merchant. Mercayo will notify the Merchant without undue delay, and in any case within 24 hours, after becoming aware of a personal data breach affecting Store Personal Data.

6.2 What the notice contains, as far as known at the time:

• the nature, extent, timing and location of the breach;
• the categories and approximate number of Data Principals and records concerned;
• the likely consequences;
• the measures taken or proposed to contain it and reduce harm;
• what Data Principals can do to protect themselves;
• a contact at Mercayo.

Mercayo gives further details as they become known, and a written report of the cause and remedy within 72 hours of becoming aware, or as soon as possible after that.

6.3 The Merchant's duties. As Data Fiduciary, the Merchant must:

• intimate the Board and each affected Data Principal under section 8(6) of the DPDP Act and rule 7 of the DPDP Rules, without delay;
• give the Board a detailed report within 72 hours of becoming aware of the breach, or any longer period the Board allows.

On request, Mercayo will:

• draft the intimations for the Merchant's approval;
• send them to affected shoppers through the store's messaging (email, SMS) if the Merchant asks;
• provide the information the Board needs.

6.4 CERT-In. Mercayo will report cyber security incidents on its own systems to CERT-In within 6 hours of noticing them, as the CERT-In Directions require, and will tell the Merchant it has done so. If the Merchant is itself required to report the incident, Mercayo will give it the information it needs to do so in time.

6.5 No admission. A notification is not an admission of fault or liability.

7. Data Principals' rights

7.1 The flow.

1. A shopper's request to access, correct, erase, withdraw consent, nominate, or complain goes to the Merchant, through the store's contact or grievance page.
2. If Mercayo receives a request about a store directly, it will pass it to the Merchant without undue delay, within 2 working days, and tell the requester it has done so. Mercayo will not answer it itself, unless the Merchant asks it to or the law requires.
3. The Merchant decides the request and answers it within the time the law allows: under the DPDP Rules, within 30 days, and never more than 90; for consumer complaints under the Consumer Protection (E-Commerce) Rules, 2020, acknowledgement within 48 hours and resolution within one month.

7.2 Tools. Mercayo provides, or will provide, admin tools for the Merchant to:

• find a shopper's data by phone or email;
• export it (access);
• correct it;
• erase or anonymise it, while keeping what the law requires (for example, issued GST invoices, which the CGST Act requires to be kept and which Mercayo freezes against change);
• record a withdrawal of consent, which stops reminders and other marketing for that store at once.

Until a tool exists for a request, Mercayo will carry out the Merchant's written instruction within 10 working days.

7.3 Erasure versus legal retention. When a shopper asks for erasure, the Merchant decides. Data the Merchant must keep by law (for example, tax invoices and the order data they contain, under the CGST Act, 2017, sections 35–36) is kept for that period only, and used for nothing else. Everything else is erased or anonymised.

8. Cross-border processing

Mercayo's primary servers are at Mumbai, India. Some Sub-processors process Store Personal Data outside India (Annex 1). The Merchant authorises these transfers.

Mercayo will:

• not transfer Store Personal Data to any country the Central Government restricts under section 16 of the DPDP Act;
• comply with any conditions the DPDP Rules impose on transfers;
• keep CERT-In logs within India, as the CERT-In Directions require.

9. The Merchant's obligations

9.1 The Merchant has a lawful ground for all Store Personal Data it has Mercayo process, and gives Data Principals the notice that section 5 of the DPDP Act requires. Mercayo's storefront privacy template is a starting point. The Merchant must name Mercayo as its processor.

9.2 Consent for marketing. Before switching on abandoned-bag reminders, review requests or other marketing, the Merchant makes sure valid consent is collected: free, specific, informed, unconditional and unambiguous, given by a clear affirmative action (DPDP Act, section 6(1)). For SMS, consent must also meet the TRAI TCCCPR rules. The Merchant uses the consent controls that the Service provides, and does not upload contact lists without consent.

9.3 The Merchant gives Mercayo only the instructions that the law allows, and keeps its shoppers' data accurate when it is used to make decisions about them (section 8(3)).

9.4 Children. If the Merchant's store is directed at children, or knowingly processes data of people under 18, the Merchant must obtain verifiable parental consent (section 9 of the DPDP Act and the DPDP Rules), and must not track, monitor behaviour, or target advertising at children. The Service is not designed for that use without further safeguards. The Merchant must tell Mercayo before enabling it.

9.5 The Merchant appoints its grievance officer or contact person and publishes their details (DPDP Act, section 8(9); E-Commerce Rules, rule 4(4)).

10. Return and deletion

10.1 During the term, the Merchant can export Store Personal Data from the admin at any time.

10.2 When the Terms end or a store closes, the Merchant has 30 days to export its data. Mercayo then deletes Store Personal Data from its live systems within 30 days, and from backups within 30 days as they are overwritten. On request, Mercayo confirms deletion in writing.

10.3 Mercayo may keep Store Personal Data after this only where Indian law requires it. In that case it is kept confidential, used for nothing else, and deleted when the period ends.

10.4 Mercayo's own internal audit records (for example, a record that a support session took place) are not Store Personal Data and follow Mercayo's Privacy Policy.

11. Audits and information

11.1 On request, and no more than once a year (or after a breach, or when a regulator requires it), Mercayo will give the Merchant the information reasonably needed to show that Mercayo complies with this DPA. This includes a description of its security measures and of any independent assessment it has.

11.2 If that information is not enough, or the Board or another regulator requires it, the Merchant may audit Mercayo's compliance:

• on 30 days' notice;
• during business hours;
• at the Merchant's cost;
• through an independent auditor bound by confidentiality;
• without access to other merchants' data or Mercayo's security secrets;
• in a way that does not disrupt the Service.

11.3 If the Board calls for information from the Merchant under the DPDP Act, Mercayo will cooperate reasonably and promptly.

12. Liability and term

12.1 This DPA lasts as long as Mercayo processes Store Personal Data.

12.2 Liability under this DPA is subject to the limitations in section 17 of the Terms, including the separate limit for a personal data breach in 17.3(e). Each party is responsible for penalties imposed on it by the Board for its own breach, to the extent the law allows.

Annex 1 — Sub-processors

Not Sub-processors (no Store Personal Data sent by Mercayo):

• Bhashini (MeitY): translates Mercayo's system texts only.
• Google Fonts: serves fonts directly to the shopper's browser. Google receives the shopper's IP address and browser data when the font loads, but not from Mercayo.

Merchant-Connected Services (the Merchant's own providers):

• Razorpay, for shopper payments into the Merchant's own account;
• Shiprocket and Shipway, the Merchant's own courier aggregator account;
• the Merchant's own Cloudflare zone, for a custom domain;
• the Merchant's own WhatsApp Business number (later);
• the Merchant's own email domain or sender (later).

Annex 2 — Security measures

These are the measures in place on the date of this DPA, described as they are built.

Isolation between stores

1. All stores share one PostgreSQL database. Every store-owned table carries a store_id, and row-level security is enabled and forced on each, so the database itself refuses to read or write another store's rows.
2. Each API request gets a short-lived database token for one store. The powerful service role that bypasses row-level security is reserved for listed platform tasks, each of which filters by store.
3. Automated tests prove, for every table, that one store cannot read, list, count, change or delete another's rows. They also check that a broken policy is detected. Stored files sit under per-store paths.

Access control

1. Staff rights are checked by the database (app.has_permission) on each request, never taken from a sign-in token. Roles and permissions are per store.
2. Admin sessions use HttpOnly, Secure, host-only (__Host-) cookies with SameSite=Lax, which browser scripts cannot read.
3. Mercayo staff access:
   • Mercayo's console is gated by a check against Mercayo's staff list on every request, never cached.
   • Changes to a store's settings require a reason and are written to an append-only audit log.
   • Support sessions run on a separate host, from a single-use link (32 random bytes, stored only as a SHA-256 hash, valid 10 minutes), with a session of at most 8 hours, also stored only as a hash.
   • Each session is checked on every request, can be ended at once by the store or by Mercayo, and is always recorded in Mercayo's internal log.
   • Payment keys, staff management and customer export are withheld from support sessions by default.

Secrets and codes

1. Merchant secrets (payment-gateway key secrets, webhook secrets, courier credentials, Cloudflare tokens) are encrypted with AES-256-GCM:
   • a 256-bit key kept outside the database;
   • a fresh random 96-bit nonce per secret;
   • the store's id bound in as authenticated data, so a secret copied to another store will not decrypt;
   • versioned, so the key can be rotated.

Secrets are never returned to any screen.

1. One-time codes are never stored. Only a salted SHA-256 hash is kept (a random salt for each code), with expiry (10 minutes), a limit of 5 attempts and single use.

Network and application

1. TLS for all traffic. Cloudflare in front of Mercayo's own addresses, for DDoS protection. Real client addresses are trusted only from known proxies.
2. Rate limits per address, per phone number and per order on sign-in, sign-up, one-time codes, order look-ups, checkout and search.
3. A strict Content Security Policy on storefronts. The only outside script allowed is Razorpay's checkout, and only on the checkout page. Card and UPI details are entered in Razorpay's own frame and never reach Mercayo's servers.
4. Webhooks from payment and courier providers are verified by signature or shared secret, and repeats are ignored.
5. Issued GST invoices and credit notes are frozen: the database refuses any change or deletion.

Operations

1. Servers: key-only administrator access over SSH, a firewall, and only required services running. Production is never used to build software. Releases are smoke-tested and rolled back automatically if they fail.
2. Backups:
   • nightly database, file and configuration backups;
   • kept 30 days;
   • continuous database logs for point-in-time recovery.
3. Logging and monitoring: access and security logs kept at least 180 days in India; clocks synchronised to NTP sources as the CERT-In Directions require. Uptime monitoring checks the Service around the clock and alerts Mercayo's team.
4. Incident response, as in section 6, including CERT-In reporting within 6 hours.