Legal

Data processing addendum

Processor terms for customer personal data in the product. Draft for pre-launch review.

Status of this draft

This Data Processing Addendum (“DPA”) is a draft website policy for product readiness. It describes how PayBlah is designed to process personal data on behalf of business customers. It is not an executed contract until accepted under signed or click-through terms approved by counsel, and it does not claim that PayBlah is certified or fully compliant with any particular data-protection law.

PayBlah provides accounts-receivable reminder software. It is not a debt-collection agency. The customer remains the creditor; messages are designed to go out in the customer’s name. Related reading: Privacy Policy · GDPR & Data Protection · Security · Sub-Processors · Terms of Service Refunds & Cancellation GDPR Data Request.

Open commercial and entity facts are marked Open decisions for owner/counsel are listed at the end of this page. Do not treat draft clauses as executed until signed.

Parties and roles

Customer means the business entity that subscribes to PayBlah and configures reminder sequences, imports or syncs invoices, and instructs the service.

PayBlah means PayBlah (primary contact: Richard Brennan), the provider of the PayBlah service.

For Customer Personal Data (defined below), Customer is the controller (or equivalent under applicable law) and PayBlah is the processor (or service provider), processing only to provide the service and related support. PayBlah remains controller of its own account, billing, security, and marketing-site data, which are outside the core of this DPA (see Privacy Policy).

Subject matter

The subject matter of the processing is personal data that Customer uploads, syncs, or generates through the PayBlah service in connection with B2B receivables management — including invoice parties’ contact details, invoice amounts and statuses, reminder and message content, portal activity, promises to pay, opt-outs, and audit metadata needed to operate the product.

The service is designed for business-to-business invoices. Customer must not use PayBlah for consumer debt collection, harassment, or other uses prohibited by the Acceptable Use policy and Terms of Service.

Duration

Processing under this DPA continues for the duration of Customer’s subscription and any post-termination period required to delete or return Customer Personal Data, or longer if retention is required by law applicable to PayBlah.

Open decision D-WIND (wind-down period after notice)

Nature and purpose of processing

Nature of processing includes collection (from Customer systems and inputs), storage, organization, retrieval, transmission (email/SMS/portal as configured), logging, display in Customer’s account UI, backup as part of service operations, and deletion.

Purpose is limited to:

  • Providing automated and manual invoice-reminder workflows configured by Customer
  • Syncing invoice and payment state with connected accounting tools or imports
  • Operating debtor-portal links, payment-link handoffs to payment providers Customer enables, promises to pay, letters workflows, and activity queues where the plan includes those features
  • Maintaining audit trails, consent/suppression records, and security controls
  • Providing customer support and reason-gated platform support access when Customer requests help
  • Improving reliability and preventing abuse of the multi-tenant service, without using Customer Personal Data to market to invoice contacts as PayBlah’s own leads

PayBlah does not use Customer Personal Data to buy or sell debt, and does not contact invoice parties as an independent collector.

Categories of data and data subjects

Data subjects

  • Invoice contacts and related business representatives of Customer’s customers (often people who never signed up for PayBlah)
  • Customer’s own staff users who operate the PayBlah account (to the extent their activity is logged in the tenant)

Categories of personal data (illustrative)

  • Invoice contacts — names, business email addresses, phone numbers used for SMS where enabled, company names, postal fields if used for letters
  • Invoice and receivables data — invoice identifiers, amounts, currencies, due dates, payment status, aging-related fields Customer chooses to store
  • Messages and channel metadata — reminder content as templated/configured, send timestamps, delivery-related status PayBlah receives, portal views, replies captured in product workflows, opt-out/STOP records
  • Operational and security logs — user actions in the account, API access metadata, support-session audit entries

Special-category data is not required to use PayBlah. Customer must not instruct PayBlah to process special-category or similarly sensitive data unless a written addendum expressly allows it Open decision D-BAN (counsel).

Card payment details for end payers are designed to be handled by the payment provider Customer uses via payment links; PayBlah is designed not to store full card numbers (see Security).

Customer instructions

PayBlah will process Customer Personal Data only on documented instructions from Customer, unless required to do otherwise by applicable law (in which case PayBlah will inform Customer unless legally prohibited).

Documented instructions include:

  • The features Customer enables in the product (sequences, channels, approvals, pauses, never-chase flags, imports, integrations, API/webhooks)
  • Configuration Customer saves (templates, schedules, branding, portal settings)
  • Support requests Customer opens that require PayBlah to access tenant data
  • Written instructions Customer sends through agreed channels instructions via in-app settings and hello@payblah.com / support@payblah.com (PayBlah / Richard Brennan (see footer) for postal)

Customer is responsible for the lawfulness of its instructions, for providing required notices to data subjects where Customer is controller, and for not instructing processing that would cause PayBlah to breach applicable law or the acceptable-use rules.

If PayBlah reasonably believes an instruction violates applicable data-protection law, it may notify Customer and pause that instruction until clarified Open decision D-INSTR (counsel).

Security measures

Taking into account the nature of the service, PayBlah implements technical and organizational measures designed to protect Customer Personal Data, consistent with the public summary on Security, including:

  • Database-per-tenant isolation — operational data for each customer is designed to live in its own database with its own database user, so isolation is structural rather than a shared-row filter alone
  • Sealed secrets — tenant database passwords, OAuth tokens, and webhook secrets are sealed at rest; readable by the system, not casually by people
  • Hashed API keys — API keys are stored hashed; bearer API access is scoped and rate-limited, without session-cookie API auth
  • Account hardening — password hashing, CSRF protection on browser forms, optional TOTP two-factor with recovery codes
  • Portal link design — high-entropy bearer tokens, rate limiting, and failure responses designed to resist token enumeration
  • Signed webhooks — outbound webhooks signed with timestamp windows so Customer can verify freshness and authenticity
  • Audited support access — platform support sessions are reason-gated, time-boxed, and audited, failing closed until dual-control requirements are met
  • Append-only activity history — message and user actions land in an audit trail designed for evidence of what was sent and when

These measures describe product design. They are not a warranty of uninterrupted security, and they are not marketed here as third-party audit certifications unless separately published with evidence.

Customer is responsible for securing its own accounts (strong passwords, 2FA where available, careful role assignment, safe handling of API keys and portal links it shares).

Sub-processing

Customer authorizes PayBlah to engage sub-processors to deliver the service (for example hosting, email delivery, SMS delivery, and payment infrastructure), subject to written terms that impose data-protection obligations no less protective in substance than those in this DPA, as required by applicable law.

Current list status: specific vendor names are not yet selected for public listing. PayBlah commits to publishing sub-processors at subprocessors with notice before launch, and to updating that list when material sub-processors are added Draft 30 days — Open decision SP-NOTICE.

Do not rely on any invented vendor names. If a name is not on the sub-processors page, it is not an authorized public claim.

Assistance with data-subject rights and compliance

Taking into account the nature of processing, PayBlah will provide reasonable assistance to Customer, through product features and support, so Customer can respond to data-subject requests (access, deletion, correction, restriction, portability, objection) that relate to Customer Personal Data in the service.

Invoice contacts who never created a PayBlah account should generally contact Customer first; PayBlah will assist Customer as processor rather than act as a second controller for that receivables relationship (see GDPR & Data Protection).

PayBlah will also provide reasonable assistance with Customer’s data-protection impact assessments and consultations with authorities, limited to information available about PayBlah’s processing Open decision D-DPIA (counsel).

Personal data breach notice

PayBlah will notify Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data, with information reasonably available at the time to help Customer meet its own notification duties. Further updates will follow as the investigation progresses.

Open decision D-BREACH (counsel — notification window)

Notification under this section is not an admission of fault or liability.

Deletion and return

On termination of the service, or upon Customer’s written request, PayBlah will delete Customer Personal Data or return it to Customer in a reasonable export format, except where retention is required by applicable law or needed for short-term backups that then expire on a rolling schedule.

Timelines are not finalized on this draft:

  • Open decision P-RET (export window)
  • Open decision P-RET (deletion)
  • Open decision P-RET (backups / certificate)

Until those numbers are confirmed by the owner and counsel, Customer should not assume a specific day-count from this page alone.

International transfers

Where PayBlah processes Customer Personal Data in a country that requires a transfer mechanism under GDPR-style rules, PayBlah will implement an appropriate safeguard (such as standard contractual clauses or a successor tool) for the relevant transfer, and will reflect primary regions and mechanisms once infrastructure choices are final.

Open decision D-XFER (SCCs/IDTA annexes + regions)

Information and audit

On written request, and no more than Draft: once per 12 months (Open decision D-AUDIT) except after a breach or material security concern, PayBlah will make available information reasonably necessary to demonstrate compliance with this DPA. On-site audits, if any, will be subject to reasonable notice, confidentiality, security constraints, and cost allocation agreed in writing Open decision D-AUDIT (counsel).

Public security descriptions on security may be used as a starting point but do not replace contractual audit rights once finalized.

Order of precedence and liability

If this DPA conflicts with the Terms of Service on a data- protection topic, the DPA is intended to control for that topic once both are executed in final form. Liability caps, indemnities, and governing law remain as set in the commercial terms unless counsel drafts a specific DPA override Open decision D-LIAB (counsel).

Questions: hello@payblah.com · security reports: security@payblah.com · Contact form.

Draft website policies for product readiness — have qualified counsel review before public launch in each territory. This DPA draft describes intended processor terms and product security design; it is not an executed agreement and does not state that PayBlah is certified or fully compliant with the GDPR, UK GDPR, or any other regime until counsel and operational readiness confirm otherwise.