Success POS — Data Processing Terms

These Data Processing Terms form part of the agreement between Success Payment S.A. and the Customer for Success POS. They are incorporated into the Success POS General Terms and Conditions of Sale and apply whenever Success Payment processes personal data on the Customer’s behalf.

1. Roles of the parties

For the personal data that the Customer records in, or generates through, Success POS in the course of running its business, the Customer is the controller and Success Payment is the processor within the meaning of Article 4 of Regulation (EU) 2016/679 (“GDPR”). These terms govern that processing, and only that processing.

Success Payment also acts as a controller in its own right, and these terms do not apply to that processing. It does so for the data it needs to enter into and perform the contract with the Customer — the Customer’s company and contact details, the order, the record of the terms accepted, invoicing and payment, the customer relationship, and the security of its own systems. That processing is described in the Privacybeleid. Confusing the two would leave both wrong, so the line is drawn here rather than left to be inferred.

Where payment terminals or payment services are supplied, the acquirers, payment institutions and card schemes involved determine their own purposes and act as controllers for the processing they carry out under their own rules. Those relationships are governed by the separate agreements referred to in clause 10 of the General Terms and Conditions.

The Customer confirms that it has a lawful basis for the personal data it records in Success POS, that it has provided the information its own data subjects are entitled to, and that its instructions to Success Payment comply with data protection law.

2. Subject matter, duration, nature and purpose

The subject matter, duration, nature and purpose of the processing, the categories of personal data and the categories of data subjects are set out in Annex 1.

The processing lasts for as long as Success Payment provides Success POS to the Customer, and afterwards only for the wind-down and retention described in clause 11 and permitted or required by law.

3. Processing on documented instructions

Success Payment processes the Customer’s personal data only on the Customer’s documented instructions, including as regards transfers to a third country, unless required to do otherwise by Union or Member State law to which it is subject. Where such a legal requirement applies, Success Payment informs the Customer of it before processing, unless that law prohibits the notification on important grounds of public interest.

The Customer’s documented instructions are: these terms, the General Terms and Conditions, the order and the configuration recorded on it, the settings and choices the Customer makes in the service, and any further written instruction the parties agree. Providing the service in accordance with those documents is a documented instruction; no separate instruction is needed for ordinary operation, support or maintenance.

If Success Payment considers that an instruction infringes data protection law, it informs the Customer without delay and may suspend the affected processing until the instruction is withdrawn, amended or confirmed.

Success Payment does not sell the Customer’s personal data, does not use it for its own marketing, and does not use it to train models or build products for other customers. It may produce aggregated statistics about the operation of the service that do not identify the Customer, its staff or its guests, and that cannot be attributed to any individual.

4. Confidentiality

Success Payment ensures that the persons authorised to process the Customer’s personal data are bound by an appropriate obligation of confidentiality, whether contractual or statutory, and that the obligation survives the end of their engagement.

Access is limited to the personnel who need it to provide, support or secure the service, and is withdrawn when that need ends.

5. Security of processing

Success Payment implements appropriate technical and organisational measures under Article 32 GDPR, taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of the processing, as well as the risk to the rights and freedoms of natural persons. The measures in force at the date of this version are described in Annex 2.

The measures may be updated as the service evolves. Success Payment does not reduce the overall level of security below that described in Annex 2 for the duration of the agreement. Annex 2 describes measures that are actually implemented; it does not claim any independent assurance standard, audit report or testing programme, and none should be inferred from it.

The Customer remains responsible for the security of what is under its own control: the devices and network at its premises, the accounts and access rights it grants to its own staff, and the confidentiality of the credentials issued to it.

6. Sub-processors

The Customer gives Success Payment a general written authorisation to engage sub-processors for the processing described in Annex 1. The sub-processors engaged at the date of this version are listed in Annex 3.

Success Payment imposes on each sub-processor, by contract, data protection obligations that are at least as protective as those in these terms, and it remains fully liable to the Customer for the performance of that sub-processor’s obligations.

Adding or replacing a sub-processor

Success Payment informs the Customer of any intended addition or replacement of a sub-processor at least thirty (30) days before that sub-processor begins processing the Customer’s personal data, by email to the contact address recorded on the order and by updating Annex 3.

The Customer may object on reasonable data protection grounds within that period, giving its reasons in writing. The parties will then discuss the objection in good faith. If it cannot be resolved, and Success Payment cannot reasonably provide the service without the sub-processor, either party may terminate the affected service on written notice, without charge to the Customer other than sums already due; that is the Customer’s remedy, and it does not entitle the Customer to withhold payment for services already provided.

A replacement made urgently to preserve the security or the availability of the service may take effect immediately, in which case Success Payment informs the Customer as soon as it reasonably can and the objection right above applies from that notice.

7. International transfers

The Success POS infrastructure operated by Success Payment runs in the European Union, in the AWS Europe (Frankfurt) region, and is constrained to that region by an organisation-level control rather than by convention alone.

Where a sub-processor listed in Annex 3 transfers personal data outside the European Economic Area, that transfer takes place only on the basis of a valid Chapter V GDPR transfer mechanism — an adequacy decision, the European Commission’s standard contractual clauses, or another lawful safeguard — together with any supplementary measures required. Annex 3 states the basis relied on for each sub-processor.

Success Payment does not transfer the Customer’s personal data outside the European Economic Area other than as described in Annex 3, unless the Customer instructs it to do so.

8. Assistance with data subject requests

Taking into account the nature of the processing, Success Payment assists the Customer by appropriate technical and organisational measures, insofar as this is possible, in fulfilling the Customer’s obligation to respond to requests to exercise the rights in Chapter III GDPR.

Where a request reaches Success Payment directly from one of the Customer’s data subjects, Success Payment does not respond to it on its own account, unless legally required to. It forwards the request to the Customer without undue delay and, where it can identify the Customer concerned, tells the person to contact the Customer.

Where the Customer can satisfy a request itself using the functions available to it in the service, it does so. Assistance requiring significant work beyond those functions may be charged at Success Payment’s applicable rates, notified before the work is carried out.

9. Assistance with Articles 32 to 36

Taking into account the nature of the processing and the information available to it, Success Payment assists the Customer in ensuring compliance with the obligations in Articles 32 to 36 GDPR — security of processing, notification of a personal data breach, communication of a breach to data subjects, data protection impact assessments and prior consultation of the supervisory authority.

That assistance takes the form, in the first instance, of the information in these terms and their annexes, which is intended to be sufficient for an ordinary impact assessment of a point-of-sale deployment. Further assistance is provided on reasonable request.

10. Personal data breaches

Success Payment notifies the Customer without undue delay after becoming aware of a personal data breach affecting the Customer’s personal data, so that the Customer can meet its own notification obligations.

The notification describes, to the extent known at the time and supplemented as more becomes known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point.

Success Payment does not notify the Customer’s supervisory authority or the Customer’s data subjects on the Customer’s behalf unless the Customer instructs it to do so in writing. Notifying, and deciding whether notification is required, is the controller’s decision.

A notification made under this clause is not, in itself, an admission of fault or liability.

11. Return and deletion

At the end of the provision of Success POS, Success Payment deletes or returns the Customer’s personal data at the Customer’s choice, and deletes existing copies, unless Union or Member State law requires it to keep them.

The Customer may export its business data through the functions available in the service for thirty (30) days from the effective date of termination, as stated in clause 8 of the General Terms and Conditions. The Customer should make its choice within that period; if it does not, Success Payment proceeds to deletion.

Backups are not deleted on demand

Deletion removes the Customer’s personal data from the live service. It does not immediately erase it from backups. Backups exist to restore a system after a failure and cannot be selectively edited without destroying that ability. Data remaining in a backup is not used for any purpose, is protected by the measures in Annex 2, and is overwritten as the backup rotates out of its retention cycle. Saying otherwise would be simpler and would not be true.

Records that Success Payment holds as controller — the order, the invoices, the record of the terms accepted and the accounting records — are not the Customer’s personal data under these terms and are kept for the periods described in the Privacybeleid.

12. Information and audit

Success Payment makes available to the Customer the information necessary to demonstrate compliance with Article 28 GDPR, and allows for and contributes to audits, including inspections, conducted by the Customer or an auditor it mandates.

In practice that obligation is met, in order:

• by these terms and their annexes, and by written answers to the Customer’s reasonable questions;
• by any third-party assurance report Success Payment holds at the time of the request, where one exists;
• by a remote review with the relevant Success Payment personnel;
• and, where those are genuinely insufficient to address a specific and substantiated concern, by an on-site audit.

An on-site audit is arranged on at least thirty (30) days’ written notice, takes place during business hours, is limited to the systems and information relevant to the processing under these terms, must not disrupt the service or compromise the confidentiality or security of other customers, and is limited to once in any twelve-month period unless a supervisory authority requires otherwise or there has been a personal data breach affecting the Customer. The auditor must not be a competitor of Success Payment and must be bound by confidentiality. Each party bears its own costs, save that the Customer bears the cost of a repeat audit within the same twelve-month period.

13. Liability, precedence and changes

These terms do not create a separate or additional liability regime. The limitations and exclusions of liability in clause 17 of the General Terms and Conditions apply to these terms and to their subject matter, in the aggregate and not per document, to the extent permitted by law. Nothing in these terms excludes or limits liability that cannot be excluded or limited by law, including under Article 82 GDPR.

On the subject matter they cover — the processing Success Payment carries out on the Customer’s behalf — these terms prevail over the General Terms and Conditions. On everything else, including duration, charges, termination and liability, the General Terms and Conditions prevail.

These terms are published in versions. The version incorporated into a given order is the one identified by the General Terms and Conditions accepted for that order, and it is recorded with that order. A published version is never modified; a change is a new version, notified in accordance with clause 20 of the General Terms and Conditions where it materially affects an existing subscription. Updates to Annex 3 follow clause 6 above rather than that procedure.

These terms are governed by the law of the Grand Duchy of Luxembourg and are subject to the jurisdiction clause in the General Terms and Conditions.

Annex 1 — Description of the processing

Subject matter and duration

Provision of the Success POS service to the Customer, for as long as the Customer’s subscription is in force, plus the wind-down period in clause 11.

Nature and purpose

Hosting, storage, transmission, display, aggregation, backup and deletion of the Customer’s operational data, for the sole purpose of operating the till, the floor, the kitchen and the back office of the Customer’s venue, and of supporting, maintaining and securing that service.

Categories of data subjects

Determined by the plan the Customer has bought and by what the Customer chooses to record. On any plan:

• the Customer’s personnel who are given access to the till or the management functions (managers, staff with an operator or till identity);
• the Customer’s guests, to the extent that an order, a bill or a table is associated with an identifiable person.

On plans that include customer records, loyalty, gift cards or reservations, the Customer’s guests are recorded as identified individuals. On a plan without those functions, guest data is generally limited to what an order and a bill contain.

Categories of personal data

No special categories of data under Article 9 GDPR are required by the service, and it is not designed to hold them. The Customer should not record health, religious or comparable information in free-text fields such as a reservation note. Full payment card numbers are not recorded by Success POS: card data is captured by the payment terminal or the payment provider and the till holds only the reference and the outcome they return.

Annex 2 — Technical and organisational measures

The measures below are those in place at the date of this version, and they were checked against the running production configuration rather than against a design document. They describe the systems Success Payment operates to provide Success POS. Success Payment does not hold an independent assurance report, and none is claimed here. Where a measure is an organisational commitment rather than something a configuration can show, it is written as a commitment.

Location and separation

• Processing takes place in the European Union, in the AWS Europe (Frankfurt) region. The restriction is enforced by a service control policy applied at the level of the organisation to the accounts that run the service, so an individual deployment cannot place a resource elsewhere.
• Production and non-production run in separate accounts, with separate data stores, separate encryption keys and separate credentials.
• Success POS is a multi-tenant service: customer data is separated logically, within shared infrastructure, rather than by giving each customer their own database or server.

Access control

• Administrative access to the production environment is through a central identity service with individually named accounts. The production account holds no personal login credentials of its own, and there are no shared administrative logins.
• Multi-factor authentication is required for the platform’s highest-privilege administrative role.
• Application components run with machine permissions scoped to the operations they actually perform.
• Success Payment grants access on need, ties it to a role, and withdraws it when the need ends.

Encryption

• Traffic between a browser or a device and the service is encrypted in transit. Public endpoints accept TLS 1.2 and above, and plain HTTP is redirected to HTTPS.
• Connections from the application to its database and to its cache are encrypted in transit, and the cache additionally requires an authentication token.
• The databases, the file storage, the cache and the audit log store are encrypted at rest with customer-managed keys held in the AWS Key Management Service, with automatic annual key rotation enabled. Database backups and snapshots inherit that encryption.
• Application logs are encrypted at rest by the managed log service that holds them.
• Secrets are held in a managed secrets service, encrypted with the same keys, and are resolved at runtime; database credentials are rotated automatically. A secret value is never written into configuration, into infrastructure state or into a log.

Payment data

• Card details are entered on the payment provider’s own hosted page or on the payment terminal. They are not collected, transmitted or stored by the Success Payment website or ordering service, and Success POS holds only the reference and the outcome returned to it.

Network protection

• Public endpoints sit behind a web application firewall using managed rule sets for common attack patterns, known bad inputs, address reputation and injection attempts, together with per-address rate limiting and a separate, tighter limit on authentication endpoints.
• The databases and the cache are not reachable from the internet.
• Network traffic within the production environment is logged.

Logging and traceability

• Application logs are written to a managed log service, each with a defined retention period.
• Administrative and programmatic activity across the accounts that run the service is recorded with log-file validation, to a dedicated audit store and to a separate logging account.
• The platform raises automated alerts on security-relevant events, including bursts of failed authentication, account lockouts, denied enrolments, bulk privilege changes and device revocations.
• The ordering and billing service’s gateway log is deliberately built to exclude request bodies, query strings and headers, so that it cannot become a second copy of customer data or a place a secret can land.

Integrity of records

• Contract evidence is written once and never rewritten. The evidence store keeps previous versions of an object and the application holds no permission to delete from it, so the record of which terms a customer accepted cannot be modified by the application that created it.
• Published legal documents carry a content fingerprint that is verified when the system starts. A published version that has been altered stops the service rather than being served.

Backup and recovery

• The production databases are backed up automatically, retained for fourteen days, and can be restored to a chosen point in time within that window. They carry deletion protection.
• File storage keeps previous versions of an object rather than replacing it.
• Backups are protected by the same encryption and access controls as the systems they are taken from.

Availability

• The customer-facing Success POS services run more than one instance, distributed across more than one availability zone within the region, behind a load balancer that checks their health.
• The payments database runs with a standby in a second availability zone.
• Automated alerts are raised on server errors and on repeated processing failures.

Change and deployment practices

• Application images are tagged immutably, so a deployed image cannot be replaced by a different one carrying the same tag, and are scanned for known vulnerabilities when they are published.
• Changes reach production by a fixed path: a development branch, then a separate pre-production environment, then production. A production deployment is additionally gated by a policy applied at the level of the organisation.
• Runtime platforms are managed services patched by the provider, and database minor versions are updated automatically.

Personnel and incident handling

• Personnel with access to customer data are bound by confidentiality obligations.
• Suspected incidents are investigated on becoming aware of them, contained, and assessed against the notification duty in clause 10.

Annex 3 — Sub-processors

The sub-processors engaged at the date of this version are listed below. Changes follow the notice and objection procedure in clause 6.

The website at success-payment.com is served by a separate hosting provider, which does not process the personal data described in Annex 1. It is identified in the Legal Notice and its role is described in the Privacybeleid.

Acquirers, payment institutions and card schemes are not sub-processors under these terms. They determine their own purposes and act as controllers, as stated in clause 1.

This version is preserved unchanged. If a newer version is published, the version you accepted when you ordered remains the one that governs your order, and it stays available here.