PRIVACY NOTICE

PRIVACY NOTICE

1. Introduction

This Notice provides information on the processing of personal data carried out in the course of providing the MeetPly appointment booking service (the Service), pursuant to Articles 13–14 GDPR and to the Hungarian Act CXII of 2011 on Informational Self-Determination and Freedom of Information (Infotv.). This Notice is an inseparable annex to the General Terms and Conditions (GTC) and is to be read together with them; unless provided otherwise, its defined terms have the meaning given to them in the GTC.

The Service is software designed to serve multiple providers (Subscribers), and therefore two parties process data in the booking chain, with distinct responsibilities (section 3). If you have booked an appointment with one of these providers, the processing relating to you is primarily that provider's processing; we act on that provider's instructions (section 6).

Who appears in this Notice? The defined terms are set out in the GTC; the summary below is provided for orientation only:

• Provider ("we") — SolvePly Kft. (section 2), the operator of MeetPly.
• Subscriber ("the provider with whom you booked") — the business or sole trader (gym, hairdresser, medical practice, trainer and so on) that uses MeetPly as a subscriber and manages its own appointments in it.
• Workspace user — the natural person acting on behalf of the Subscriber (owner, administrator, staff member) who has an account in the administration interface.
• End User — the natural person who books an appointment through a Subscriber's public booking page, embedded booking interface or integration channel.
• Data subject ("you") — any natural person whose personal data we process.

The concepts of controller and processor, and which role we act in for which category of data, are set out in section 3.

This Notice is information, not consent: there is nothing to accept, but it is worth reading.

2. Controller details

3. Data protection roles — who is the controller for what?

The controller is the party that decides why and how the data is processed; the processor is the party that processes it on the controller's instructions and does not use it for its own purposes.

The details of the processor relationship with the Subscriber are set out in the Data Processing Agreement (DPA) under Article 28 GDPR: https://meetply.com/jogi/dpa

4. Place of processing, safeguards and the source of the data

4.1. The Provider stores and processes the data within the European Union, in accordance with the principles set out in Article 5 GDPR.

4.2. Transfers to third countries. Affiliates of two of our processors may also operate outside the European Union.

Stripe. Our contracting partner is Stripe Payments Europe, Limited (Ireland); its affiliates — including Stripe, Inc. (United States of America) — may also process data in a third country. The safeguard for the transfer is the standard contractual clauses (SCC) adopted by the European Commission or — where the US entity concerned falls within the scope of the framework — the EU–US Data Privacy Framework (DPF). The safeguard applicable at any given time is set out in Stripe's data processing agreement, which is publicly available on Stripe's website.

Google Calendar. If the Subscriber uses the separately activated Google Calendar mirroring described in section 6.2, the contracting entity in the European Economic Area is Google Ireland Limited (Ireland); its affiliates may also process data in a third country. The safeguard for the transfer is the European Commission's standard contractual clauses (SCC) or, within the scope of the Commission's adequacy decision, the DPF, in accordance with Google's data processing terms as applicable from time to time. This channel operates only if the Subscriber or its staff member expressly activates it for the resource concerned; the scope of data transferred to Google is narrow and contains no personal data of the person booking (section 9).

4.3. The source of the data:

• directly from you — registration, acceptance of an invitation, provision of billing data, contacting us, or making a booking on the public or the embedded booking interface;
• from the Subscriber — inviting a staff member, recording a booking in the administration interface;
• from an integration (programmatic) channel — another system (for example a chatbot platform or the Subscriber's own system) may also create a booking through the Service's REST API and MCP interface. In that case the name, e-mail address and phone number of the person booking are transferred by the calling system, accompanied by a short-lived, digitally signed identity assertion. We process this data as the Subscriber's processor, in the same way as data provided on the public page. Responsibility for informing the users of the calling system and for the legal basis lies with the operator of the calling system and with the Subscriber; on this channel evidence of acceptance is not necessarily created (5.4);
• automatically, from use of the Service — logs, security and abuse-prevention data (5.5).

5. Categories of data processed, purposes and legal bases

Sections 5.1–5.10 describe the Provider's own processing: sections 5.1–5.6 set out the specific categories of data, purposes and legal bases, while sections 5.7–5.10 contain provisions on cookies, children's data, special categories of data and automated decision-making that apply across all categories. Booking data — where we act as processor — is dealt with in section 6.

The nature of providing the data and the consequences of failing to do so [Article 13(2)(e) GDPR]: providing the data listed in the tables below is in every case a precondition for using the function stated in the Purpose column, and is not the subject of GDPR consent. If you — or a staff member acting on behalf of the Subscriber — do not provide the data concerned, the related function cannot be used: without an account there is no login, without billing data there is no subscription, and without the name and e-mail address of the person booking there is no booking. Where this is not the case (for example, where a field is optional), the relevant table row or the text below it states so expressly.

5.1. Workspace user accounts (owner, administrator, staff member)

Balancing of interests (invited accounts): the scope of data processed is narrow (work e-mail address, name, permissions), the data subject receives the access in the course of their work, can access their account at any time, and may object.

5.2. Staff time-off requests, work organisation

The reason given in the request is visible only to the owner and administrators of the workspace and never appears in the notification e-mails sent out.

5.3. Subscription, payment of fees, billing

Where a claim connected with the payment of fees is enforced, the legal basis is Article 6(1)(f) GDPR — legitimate interest.

Stripe's role is twofold. In respect of subscription and billing data, Stripe is the Provider's processor (section 9). However, in respect of payment card data and Stripe's own regulatory obligations (PCI-DSS, fraud prevention and anti-money laundering), Stripe acts as an independent controller under its own privacy policy — the Provider has no access to that data.

5.4. Evidence of acceptance of the legal documents

Two important limitations: (a) we do not ask for acceptance of the privacy notice, because it is information under Article 13 GDPR and not consent — the version reference linked to the booking therefore refers to the GTC; (b) the evidence is not created on two channels: on the programmatic (API/MCP) channel not necessarily (4.3), and for a booking recorded in the administration interface by the Subscriber or its staff member not at all — in that case the person booking does not use the booking interface and therefore does not accept the terms (section 21.3 of the GTC).

5.5. Operational security, logging, abuse prevention, rate limiting

Our principle: logs do not contain End User names, e-mail addresses, phone numbers or booking comments, nor any payment/billing data or secrets — only technical identifiers.

5.6. Contact, support, complaint handling

The retention period is based on Section 17/A(7) of the Hungarian Consumer Protection Act (Fgytv.), which prescribes 3 years for the retention of a complaint and the substantive response to it. The 5-year rule applicable to audio recordings of complaints made by telephone does not apply to us, because we accept complaints exclusively by electronic means — on our website and by e-mail (section 16.1 of the GTC). We apply the 3-year retention period uniformly, irrespective of the legal status of the complainant.

5.7. Website, cookies

The Service does not use analytics or marketing cookies; the analytics and marketing categories of the cookie settings bar operating on meetply.com are currently empty. Cookies — together with their lifetime in the browser — are covered by a separate Cookie Notice: https://meetply.com/jogi/cookie

5.8. Children's data

The Service is designed for business use: user accounts are given to businesses and their staff, and therefore our own processing is not directed at children.

In the case of a booking, the controller is the provider concerned. If, because of the nature of the service, a person under the age of 16 may also book (for example education or sports training), ensuring the legal basis required for processing the child's data — including the consent or authorisation of the holder of parental responsibility (Article 8 GDPR) — is the obligation of the provider (controller). Hungary has not made use of the derogation under Article 8(1) GDPR: the age limit is 16 years, as provided by default in the GDPR (the Infotv. does not set a different, lower age limit for information society services).

5.9. Special categories of data

The Service does not request and does not intentionally process data falling under Article 9 GDPR. However, the free-text comment that can be written for a booking, and the service name chosen by the Subscriber, may indirectly carry such data as well (in particular in the case of healthcare or therapeutic activities). Assessing whether this results in processing under Article 9 GDPR, and ensuring the necessary legal basis, is the responsibility of the Subscriber (controller); the Provider recommends the use of neutral names (section 6.3 of the DPA).

5.10. Automated decision-making — and what we do not do

• We do not use automated decision-making or profiling within the meaning of Article 22 GDPR.
• Acceptance of a booking is determined by the fact of available capacity and the absence of a conflict, not by any evaluation of the data subject. The booking rules (for example a daily cap on the number of bookings, or "the same customer once a day") are limits set in advance by the Subscriber and applied to everyone in the same way.
• Any evaluative entry connected with a booking — for example recording a no-show — is always made by a human in the administration interface; the system does not determine this automatically. We do not operate any automatic block list or blacklist: no one is excluded from booking on the basis of their earlier bookings. Rate limiting (5.5) is a technical safeguard against automated abuse, not an evaluation of the data subject.
• The Service has no artificial intelligence / large language model layer: we do not transfer the data to any provider operating a language model, and we do not use it for model training. If an external system integrates through our programmatic interface, that is its own processing (4.3).
• We do not build advertising profiles, and we do not sell or rent out personal data.

6. Booking data — where we act as processor

The controller for the processing described in this section is not the Provider but the Subscriber with whom you booked the appointment. In this area the Provider acts exclusively as a processor, on the Subscriber's documented instructions; the purposes and the legal basis are determined by the Subscriber (typically performance of a contract: reserving the appointment). The detailed processor obligations are set out in the DPA.

Retention. Once the retention period set for the Subscriber's calendar has elapsed, we delete or anonymise the personal data of the booking (name, e-mail address, phone number, comment), while retaining the statistical data. The default is 365 days; the Subscriber may depart from it. The cancellation link is valid for 30 days from being sent; after that the link cannot be used, while the stored hash is deleted not under a separate deadline but together with the booking, when the booking's retention period expires (section 4.5 of the DPA). We retain the log of notifications sent for 90 days.

How does deletion take place? Enforcement of the retention period currently takes place not through a scheduled, automated process but manually, under a documented procedure: deletion is carried out on the Subscriber's instruction, or upon expiry of the retention period, by a staff member of the Provider designated for that purpose, within the deadline set by the GDPR (section 4.5 of the DPA). We state this limitation for reasons of transparency; automatic enforcement of the retention period is under development.

Recipients. The Subscriber and the staff members authorised by it (a staff member sees the names of the participants belonging to their own resource, with their contact details partially masked), as well as our processors listed in section 9 (hosting, e-mail delivery). No other Subscriber sees the data — we store the data separated at database level.

Embedded booking interface. The embedded booking interface appears on the Subscriber's website, but the data is received directly by our server.

6.1. Calendar feed (ICS)

The Subscriber may request a feed (ICS) for its calendar: this is a link that can be inserted into its own calendar application (for example Google Calendar, Apple Calendar, Outlook) and that makes the appointments of that calendar continuously available — 7 days into the past and 62 days into the future.

What does the feed contain? At every level, the time of the appointment, the name of the resource (for example the staff member or the room) and a link pointing to the administration interface. What is shown about the appointment beyond that is set by the Subscriber per calendar, at three levels:

None of the levels contains your e-mail address, phone number or the comment written for the booking. The name of the service is chosen by the Subscriber — see section 5.9.

The default for every calendar is the "Service only" level. The level that also includes the name must be expressly activated by the Subscriber, and we log any change to the setting. Activation affects the entire time window of the feed — that is, also bookings already recorded and upcoming.

Who receives the data? The calendar application whose operator has received the link from the Subscriber. This transfer is not initiated by us: the calendar application downloads the feed on the basis of the link. Which provider it chooses, and with whom it shares the link, is the Subscriber's decision and responsibility — in this area the calendar provider concerned is not a processor of the Provider. (This is different from the Google Calendar mirroring described in section 6.2, where the data is sent out by our system.)

How long is it available, and what happens on deletion? The feed always shows the time window set out above, without a stored copy of its own: if we delete or anonymise the personal data of the booking on expiry of the retention period or at your request — as described above — that data also disappears from the feed. However, what the calendar application has already downloaded and stored is removed neither by resetting the level, nor by replacing the link, nor by the deletion carried out by us — its removal can be initiated with the operator of the calendar application concerned, or with the Subscriber.

Anyone who knows the link can access the above data without a separate login, and the Subscriber must therefore not share it and must replace it in the event of compromise. The link can be replaced at any time — the earlier link immediately becomes invalid, and this is the primary means of withdrawing access.

6.2. Google Calendar mirroring (optional, activated by the Subscriber)

If someone in the workspace connects a Google calendar to a resource — typically to their own staff resource — we copy the appointments of that resource one-way into the Google calendar they have selected. The copied event contains the name of the service and of the resource, the time and the occupancy count — but not the name, e-mail address, phone number or comment of the person booking. The mirroring does not read any data back from the Google calendar. Creating, maintaining and terminating the connection is the decision of the Subscriber or of the staff member concerned; when the connection is disconnected we delete the stored access key and also revoke the access at Google. The data stored for the connection is described in section 5.1, and the safeguard for the transfer in section 4.2.

6.3. "Add to Google Calendar" link

The confirmation may contain a link with which you can save the appointment to your own calendar. By clicking the link, you transfer the data to your calendar provider; we do not send any data to Google for this link to work. (This is different from the separately activated calendar mirroring described in section 6.2.)

6.4. Where should you submit your request?

Primarily to the provider with whom you booked. We will forward any request submitted directly to us without undue delay, and we will also assist within our own competence.

7. Your rights

Under Articles 15–22 GDPR, you may request:

• access [Article 15] — information on whether we process data about you, what data, for what purpose, to whom we disclose it and how long we retain it; you may also request a copy;
• rectification [Article 16] — correction of inaccurate data, completion of incomplete data;
• erasure [Article 17] — within the limits of retention obligations based on law (e.g. invoices);
• restriction of processing [Article 18] — for example while accuracy is contested;
• data portability [Article 20] — your data processed by automated means on the basis of a contract or consent, in machine-readable form or transmitted to another controller;
• to object [Article 21] to processing based on legitimate interest; in that case we review whether our interest genuinely prevails;
• to withdraw your consent [Article 7(3)] where the processing is based on consent — there is currently no such processing among our own processing activities.

You may submit your request at info@meetply.com. We will respond to the request without undue delay and at the latest within 1 month; for a complex request this may be extended by a further 2 months, of which we will notify you. Fulfilment is free of charge.

What does erasure extend to? Erasure does not stop at a single database row: it extends to the data stored in the database, to the related files in the object storage and — in respect of the personal data stored in it — to the notification records as well. The Service does not operate a search or vector index or embeddings, and therefore no such copy is created (5.10). Operational logs contain technical identifiers, not End User names, e-mail addresses, phone numbers or booking comments (5.5), and they expire according to their own retention period. In backups, erasure takes effect through the rotation of the backups, as they expire — the retention period of the backups is at most 30 days (section 4.5 of the DPA) — and we ensure that data previously erased is not returned to processing after a restore. Data that we are required by law to retain cannot be erased (in particular accounting vouchers, 5.3), nor can data that is necessary for the enforcement of claims — for such data, narrowing of access and restriction of storage apply. For the calendar feed described in section 6.1, erasure also takes effect in the feed, but it does not extend to copies already downloaded from it and stored by a third party.

If the request concerns data for which we are not the controller (booking data), we forward the request to the Subscriber and inform you accordingly. Where justified, we may ask for further data to identify you — solely in order not to disclose someone else's data.

8. Remedies

Please raise your complaint with us first: info@meetply.com.

You may lodge a complaint with the supervisory authority:

You may also turn to the courts; the action may — at your choice — also be brought before the regional court of your place of residence or place of stay (Section 23 of the Infotv.).

9. Processors and other recipients

The Google Calendar row applies exclusively to those workspaces and resources where the Subscriber or its staff member has expressly activated the mirroring; the contracting entity and the safeguard for the transfer are set out in section 4.2. The Accountant row refers to the Provider's accounting service provider as engaged from time to time; we will disclose its name at a data subject's request.

The calendar feed described in section 6.1 is not included in this group: it is downloaded, on the basis of the link, by the calendar application chosen by the Subscriber, and therefore in this area the calendar provider concerned is not a processor of the Provider but a recipient determined by the Subscriber's own decision as controller (section 6.1; section 6.2 of the DPA).

Stripe's role in this table is likewise twofold: in respect of subscription management and the related data it appears as a processor; however, in respect of payment card data and its own regulatory obligations (PCI-DSS, AML/KYC) it is an independent controller — see section 5.3.

We engage a processor exclusively subject to acceptance of the data processing terms under Article 28 GDPR, and we apply the diligence required by Article 28(1) when selecting one. If the set of processors is extended, or if a processor changes, we will notify you in advance under the procedure set out in the DPA.

Self-hosted components. The Provider runs the identity management software that handles login and account management (Ory Kratos) and the object storage on its own servers located in the EU, on Hetzner's infrastructure — these are not separate processors but components of the system, and account data is therefore not transferred to the company called Ory. We do not keep the PDF files of invoices in our own storage: we relay them to the Subscriber from the invoicing partner's system, through our own server.

Other recipients. The Subscriber and the users authorised by it in respect of booking data (section 6); authorities and courts where required by law, within the limits of that requirement; legal counsel and auditor in respect of the enforcement of claims and of accounting and tax obligations; the integration clients authorised by the Subscriber, through the programmatic interface (API key), on the basis of the Subscriber's decision (4.3). We inform the data subject of any disclosure of data due to a request from an authority or a court, or due to the enforcement of claims — unless the law provides otherwise.

Beyond this we do not disclose personal data to any third party. We notify Subscribers in advance of any change to the list of processors, in the manner set out in the DPA.

10. Data security

10.1. Taking into account the state of the art, the costs of implementation and the nature and risks of the processing, we apply, among others, the following measures:

• separation between Subscribers in the database, in separate schemas, enforced on the server side (not by hiding the interface);
• role-based and calendar-level access management according to the principle of least privilege; partial masking of participants' contact details in the staff view;
• encrypted communication (TLS); passwords stored exclusively as non-reversible cryptographic hashes and never in their original form anywhere;
• access keys belonging to external providers that must be decryptable for operation — for example the refresh key for the Google Calendar connection — stored encrypted, with a key identifier;
• session cookies with the HttpOnly and Secure attributes;
• rate limiting on the booking and cancellation interfaces; storage of cancellation identifiers as hashes and their single use;
• logging without personal data, masking of secrets in logs;
• encrypted backups and a recovery procedure;
• security review built into the development and operations process.

10.2. In the event of a personal data breach we act in accordance with Articles 33–34 GDPR: where the breach affects us as controller, we notify the NAIH within 72 hours of becoming aware of it and, in the case of high risk, we also inform the data subjects. If the breach concerns data in respect of which we act as processor, we notify the Subscriber without undue delay; notification of the authority is the Subscriber's obligation (section 4.6 of the DPA).

11. Amendment of this Notice

We may amend this Notice unilaterally, in particular where our processing, the functions, the set of processors or the legal environment change. Amendment takes place by issuing a new version; we do not rewrite the text of earlier versions retrospectively. We notify Subscribers of material amendments by electronic means and in the interface of the Service. The version in force — with its version number and date — is available at https://meetply.com/jogi/adatkezeles

12. Governing legislation

GDPR; Infotv. (Act CXII of 2011); Civil Code (Act V of 2013); Accounting Act (Act C of 2000); VAT Act (Act CXXVII of 2007); Act on the Rules of Taxation (Act CL of 2017); E-Commerce Act (Act CVIII of 2001); Consumer Protection Act (Act CLV of 1997).

Language. This document is an English translation of the Hungarian-language Privacy Notice and is provided for convenience only. In the event of any discrepancy or inconsistency between the Hungarian version and this translation, the Hungarian version shall prevail.