Data processing

What this page is

This page explains how Pleezpay handles personal data for its customers and what our Data Processing Agreement (DPA) contains. Customers, and prospective customers evaluating Pleezpay, can request the DPA itself. It is signed together with the customer agreement. Once signed, the DPA takes precedence over this page and over the Privacy notice for the processing it covers. This page is a plain explanation, not the agreement. It does not create or change a contractual obligation.

Controller and processor

Pleezpay provides payment orchestration software and payments advisory. For the personal data of our own website visitors, prospects, partners and customer account holders, we decide why and how the data is used, so we are the controller. The Privacy notice describes that processing.

When we process payment and shopper data for a merchant customer, the customer decides why and how it is processed and is the controller. We are its processor (or its service provider under California law), and we process that data only under the customer agreement and the DPA.

Customer data here means the personal data we handle for a customer through the platform: payment sessions, payment metadata, shopper contact and billing details entered at checkout, order references, webhook records and dispute records. It also covers configuration and support information the customer or its authorised users give us so that we can run the service for them.

Card data entered on the hosted payment page goes to the connected payment provider that processes the payment. That provider handles it under its own terms, regulatory permissions and card scheme obligations. The DPA describes this boundary. It does not make Pleezpay an acquirer, a payment institution or a card scheme member.

What the DPA covers

The DPA holds the terms data protection law requires between a controller and a processor. In plain terms:

Subject matter and duration

The processing needed to provide the subscribed services, for as long as the customer agreement runs, plus the return or deletion period at the end.

Nature and purpose

Creating and running payment sessions, routing payments to connected providers, normalising payment status, delivering webhooks, reconciling outcomes, supporting refunds and disputes, reporting and customer support. We don’t process customer data for any other purpose without a documented instruction.

Categories of data and data subjects

An annex lists the personal data involved (such as name, email address, billing address, phone number, order and payment references, payment method type and status, device and network details captured at checkout, and dispute correspondence) and the people concerned (shoppers and payers, the customer’s staff and authorised users, and anyone else named in an order).

Documented instructions

We process customer data only on the customer’s documented instructions: the agreement, the DPA and the configuration the customer sets in the dashboard or through the API. We tell the customer if we believe an instruction breaks data protection law, and we tell the customer before any processing a law requires, unless that law forbids telling them.

Confidentiality of personnel

People authorised to process customer data are bound by confidentiality, and their access is limited to what their role needs.

Security measures

Technical and organisational measures suited to the risk of the processing. The DPA’s security annex refers to the controls published on our Security page, which says what is in place and what we don’t claim. We make no PCI DSS, SOC 2 or ISO certification claims.

Subprocessors

The customer gives general written authorisation for the subprocessors on the Subprocessors page. We give advance notice of a planned addition or replacement within the notice period in the DPA. The customer may object on reasonable data protection grounds, and if we can’t find a solution, the customer may terminate the affected service as the DPA sets out. We pass equivalent obligations to each subprocessor and stay responsible to the customer for how they perform.

Assistance

We help the customer answer data subject requests about customer data — access, correction, deletion, restriction, objection and portability — and help with data protection impact assessments and prior consultation with a supervisory authority, taking into account the nature of the processing and the information available to us. If a request reaches us directly, we pass it to the customer.

Personal data breach

We notify the customer of a personal data breach affecting customer data without undue delay and within the period in the DPA, give the information the customer reasonably needs for its own notifications, and cooperate on containment and remediation. Notifying is not an admission of fault.

Deletion or return at the end

At the customer’s choice, we return or delete customer data after the service ends, within the window in the DPA, and delete any remaining copies. Data that legal, tax, dispute or accounting duties require us to keep is kept only for that purpose, stays protected under the DPA and is deleted when the duty ends.

Audit and information rights

We make available the information reasonably needed to show compliance with the DPA, answer security questionnaires, and allow audits, including inspections, by the customer or an independent auditor the customer appoints, under the frequency, notice, confidentiality and scope conditions in the DPA.

Liability

Liability under the DPA follows the caps, exclusions and remedies in the customer agreement, except where data protection law does not allow it.

International transfers

Pleezpay is US based and processes customer data in the United States and in the countries where its subprocessors operate. Where customer data comes from the European Economic Area, the United Kingdom or Switzerland, the DPA includes the European Commission’s 2021 standard contractual clauses: module two where the customer is a controller, and module three where the customer is itself a processor. For UK data, the International Data Transfer Addendum issued by the Information Commissioner’s Office supplements the clauses. For Swiss data, the clauses are adjusted as the Federal Data Protection and Information Commissioner (FDPIC) requires: references to the GDPR are read as references to the Federal Act on Data Protection, the FDPIC is the competent authority, and Swiss data subjects are covered. Where an adequacy decision or another recognised mechanism applies, we may rely on that instead.

On request, we provide a transfer impact assessment that describes the laws and practices of the destination country, the safeguards in place and the supplementary measures we rely on, so the customer can complete its own assessment.

California and other US state privacy laws

For personal information covered by the California Consumer Privacy Act, as amended, and similar US state privacy laws, the DPA contains the terms those laws require of a service provider, contractor or processor. Under it, we:

• process customer data only for the specific business purposes in the agreement;
• don’t sell or share it;
• don’t keep, use or disclose it outside our direct business relationship with the customer, or for any other commercial purpose;
• don’t combine it with personal information from other sources, except as those laws allow;
• give it the same level of privacy protection the law requires of the customer;
• tell the customer if we decide we can no longer meet these obligations;
• let the customer take reasonable steps to check our compliance, and to stop and fix unauthorised use; and
• help the customer respond to consumer requests to know, delete, correct and limit.

We pass the same requirements on to our subprocessors.

Payment providers as independent controllers

The DPA covers the processing we do for the customer. Connected payment providers process payment and card data under their own terms, regulatory permissions and merchant onboarding decisions. For fraud prevention, sanctions screening, financial crime controls and regulatory reporting, a provider may act as an independent controller and decide for itself how it uses the data it receives. The Subprocessors page lists each provider that receives customer data through the platform and the role it plays, and each provider’s own privacy notice describes its processing. We are not responsible for processing a provider carries out as a controller, and provider terms apply separately from the DPA.

How to request the DPA

Email [email protected] with “DPA request” in the subject, and include:

• the legal entity name, registered address and jurisdiction of the contracting customer;
• the name and role of the person who will sign;
• whether personal data from the European Economic Area, the United Kingdom, Switzerland or California is in scope, so we attach the right transfer clauses and state law terms; and
• the product or agreement the DPA relates to, such as a platform order form, hosted checkout, a plugin integration or an advisory engagement.

We reply with the current DPA and its annexes (processing description, security measures, subprocessor list and transfer clauses) for signature alongside the customer agreement. If you are evaluating Pleezpay, you can request the DPA before signing so your legal and compliance teams can review it. If your own regulatory position requires your own DPA template, we can review it, subject to both parties agreeing the scope, timing and any differences from our standard terms.

Related documents

• Privacy notice: how we handle personal data as controller.
• Security: the published controls the DPA’s security annex refers to, and our current certification status.
• Subprocessors: the current list of subprocessors and connected providers.
• General terms: the commercial framework the DPA sits within.
• Acceptable use policy: what customers may and may not do with the service.