Data processing

Two roles, depending on whose data it is

Pleezpay sells payment orchestration software and advice on payments. On this page, “you” is the merchant that holds, or is considering, a Pleezpay agreement, and “we” is Pleezpay.

We are the controller for people who deal with Pleezpay itself: visitors to our website, prospects, partners and the people who log in to customer accounts. We set the purposes and the means of that processing, and the Privacy notice explains it.

We are your processor for the payment and shopper data we handle when you trade through us. You set the purposes and the means, so you are the controller. Under California law our role is called a service provider. Either way, we touch that data only as your customer agreement and the DPA allow.

Data we hold on your behalf

“Customer data” is the personal data that passes through the platform for you. It includes payment sessions and the metadata attached to them, the billing and contact details a shopper types into the checkout, order references, and the records we keep of webhooks and disputes. It also includes any configuration or support details that you or your authorised users send us so we can run the service.

Card details typed on the hosted payment page are a separate case. They go to whichever connected provider is processing that payment, and it treats them under its own terms, its own regulatory permissions and its obligations to the card schemes. The DPA records where that line falls. Nothing in it turns Pleezpay into an acquirer, a payment institution or a member of a card scheme.

When a provider acts for itself

The DPA governs only what we do for you. Connected payment providers also handle payment and card data, and they do so under their own terms, permissions and decisions about which merchants to onboard.

For purposes such as preventing fraud, screening against sanctions, controlling financial crime and reporting to regulators, a provider can be an independent controller: it decides on its own how to use what it receives. Processing a provider does in that capacity is outside our responsibility, and its terms apply apart from the DPA. The Subprocessors page names every provider that receives customer data via the platform, and what each one does with it; the provider’s own privacy notice covers the detail.

Inside the agreement

The DPA carries the clauses that data protection law expects a controller and its processor to agree. Here is what each one says, grouped by what it is for.

What is processed, and why

Scope and term

Whatever processing the services you subscribe to need. It lasts as long as your customer agreement, followed by the period for handing back or erasing the data.

Purposes

Opening and running payment sessions, sending each payment to a connected provider, turning provider statuses into one consistent status, sending webhooks, reconciling results, reporting, support, and handling refunds and disputes. Any other use needs a documented instruction from you first.

Whose data, and which kinds

One annex sets out whose data it is: shoppers, payers, your staff and authorised users, and anyone else an order names. It also sets out the data itself, for example names, email addresses, billing addresses, phone numbers, payment and order references, which method was used and its status, details of the device and network captured during checkout, and messages exchanged about a dispute.

How we work with your data

Your instructions

We act only on what you have documented: the agreement and the DPA, plus whatever settings you choose in the dashboard or send through the API. If we think an instruction would breach data protection law, we say so. If a law obliges us to process data, we tell you beforehand, unless that same law prevents us.

Our people

Anyone allowed to work on customer data is under a duty of confidentiality and can reach only what their job requires.

Security

Technical and organisational measures matched to the risk. The security annex points to the controls on our Security page, which lists the controls we run and the claims we don’t make. We don’t claim ISO, SOC 2 or PCI DSS certification.

Subprocessors

By signing, you authorise in writing, in general terms, the subprocessors named on the Subprocessors page. Before adding or replacing one, we warn you within the notice period the DPA fixes. You can object for sound data protection reasons. If we can’t resolve the objection, the DPA lets you end the service it affects. Each subprocessor takes on obligations equivalent to ours, and we remain answerable to you for its performance.

When you need our help

Requests and assessments

When someone asks for access to customer data, or for its correction, deletion or portability, or wants to restrict or object to its use, we help you respond, and we forward any such request sent to us instead. We also support your data protection impact assessments and any consultation you must hold with a supervisory authority before processing starts, as far as the kind of processing and what we know allow.

A personal data breach

If a breach affects customer data, we tell you without undue delay and inside the window the DPA sets. We give you what you reasonably need to make your own notifications, and we work with you to contain and fix it. Telling you is not an admission that we were at fault.

Audits and evidence

We share the information you reasonably need to confirm we keep to the DPA, we complete security questionnaires, and we permit audits and inspections, by you or by an independent auditor you choose. The DPA sets how often, with how much notice, under what confidentiality and covering what scope.

Endings and limits

When the service ends

You choose whether we hand customer data back or erase it. We do either inside the period the DPA gives, then remove any copies left. Where an accounting, tax, legal or dispute duty makes us keep something, we keep it for that reason alone, protect it under the DPA, and erase it once the duty lapses.

Liability

Your customer agreement’s exclusions, caps and remedies also govern the DPA, other than where data protection law forbids that.

Data from Europe, the UK and Switzerland

Pleezpay is based in the United States. Customer data is processed there and wherever our subprocessors work.

Customer data that comes from the EEA, the UK or Switzerland travels under these safeguards:

• EEA data: standard contractual clauses in the version adopted by the European Commission in 2021 — module three when you are yourself a processor, module two when you are a controller.
• UK data: those clauses, plus the International Data Transfer Addendum from the Information Commissioner’s Office.
• Swiss data: those clauses with the changes the Federal Data Protection and Information Commissioner (FDPIC) asks for. The FDPIC acts as competent authority, data subjects in Switzerland fall within the clauses’ protection, and each mention of the GDPR means the Federal Act on Data Protection.

Where the transfer is covered by another recognised mechanism, such as an adequacy decision, we may use that in place of the clauses. Ask, and we send you a transfer impact assessment for your own review: it covers the receiving country’s laws and practice, which safeguards apply, and the extra measures we depend on.

US state privacy laws

The California Consumer Privacy Act (CCPA), as amended, and comparable laws in other US states set terms for anyone acting as a processor, contractor or service provider. The DPA includes them for the personal information those laws cover. In short, we commit to:

• use customer data only for the particular business purposes the agreement names;
• never sell it, and never share it;
• keep, use and disclose it only within our direct relationship with you, and never for some other commercial end;
• keep it apart from personal information we get elsewhere, unless those laws permit combining it;
• protect its privacy to the standard the law sets for you;
• let you know if we find we can no longer keep these commitments;
• allow you reasonable steps to verify what we do, and to halt and remedy any unauthorised use; and
• help you answer consumers who ask to know, correct, delete or limit.

Our subprocessors are held to the same requirements.

Ask for a copy

You can have the DPA before you sign anything, so your legal and compliance people have time to read it. Send an email to [email protected] headed “DPA request”, and tell us:

1. who is contracting: the legal entity’s name, its registered address and the jurisdiction it is in;
2. who signs, and their role;
3. which of these places your personal data comes from, if any: the EEA, the UK, Switzerland or California. That tells us which transfer clauses and US state terms to attach; and
4. what the DPA is for: a plugin integration, hosted checkout, an advisory engagement, a platform order form or another product or agreement.

You get back the current DPA with its annexes — the description of processing, the security measures, the subprocessor list and the transfer clauses — ready to sign with the customer agreement. If your regulator means you must use your own DPA template, send it and we will look at it, provided we both agree how far it reaches, when it applies and where it departs from our standard terms.

This page and the signed DPA

Here our Data Processing Agreement (DPA) is described in plain words; the description itself binds no one, and no contractual obligation starts or changes because of it. You sign the DPA and the customer agreement together. From then on, it overrides this page and the Privacy notice wherever it applies.

Read next

• Privacy notice — our own processing, where we are the controller.
• Subprocessors — every vendor and connected provider on the current list.
• Security — the controls the security annex relies on, and where we stand on certification.
• General terms — the commercial terms the DPA sits under.
• Acceptable use policy — the limits on how the service may be used.