Legal

GDPR & data protection

How PayBlah approaches personal data for EU and UK contexts. Draft — not formal legal advice.

Scope and honesty

This page summarizes how PayBlah is designed to approach data protection under the UK GDPR, the EU GDPR, and closely related rules that may apply when we offer the service in the United States, United Kingdom, Ireland, and Australia. It is a draft for product readiness — not legal advice, not a certification, and not a claim that PayBlah is “GDPR certified” or already compliant with every obligation in every territory.

PayBlah is subscription software that helps businesses send overdue B2B invoice reminders in their own name. We are not a debt-collection agency; we do not buy debt or contact people as an independent creditor. For full privacy detail see the Privacy Policy. For customer–processor terms see the Data Processing Addendum. For technical controls see Security.

Entity, registered office, DPO appointment, and lead supervisory authority details are not final. Where facts are open, they are marked Open decisions for owner/counsel are listed at the end of this page.

Controller and processor roles

Roles matter because they decide who answers rights requests and who sets the purpose of processing.

PayBlah as controller

We act as a controller (or equivalent) for personal data we collect for our own business operations, for example:

  • Account holder and team-user details for a PayBlah subscription (name, work email, authentication data, billing contacts)
  • Marketing-site visitors and cookie preference records, as described in the Cookie Policy
  • Support and security correspondence sent to us
  • Sales, billing (via Stripe), and affiliate program data once those programmes are live.

PayBlah as processor

When a business customer uses PayBlah to manage receivables and reminders, that customer is typically the controller of personal data about the people and organizations they invoice. PayBlah is designed to act as a processor (or service provider) for that customer data — processing it on the customer’s instructions to run sequences, portals, logs, and related features. Those instructions and security commitments are set out in the Data Processing Addendum and the customer’s subscription terms.

Customers remain responsible for having a lawful reason to contact their invoice parties and for the content of messages sent in their name. PayBlah does not decide whom to chase as an independent business decision outside the customer’s configuration.

Invoice contacts who never signed up

PayBlah’s product surface includes a “debtor portal” and customer records imported from accounting systems or spreadsheets. The people named on those invoices usually did not create a PayBlah account and may never visit payblah.com. Their data reaches us because the business that invoices them connected books, uploaded a file, or entered details to send reminders.

For that population:

  • The business customer is designed to remain the controller and the party primarily responsible for transparency, lawful basis, and handling access or deletion requests that relate to their receivables.
  • PayBlah processes contact details, invoice amounts, message history, and related operational data only to provide the service the customer configured.
  • Messages go out in the customer’s name. We are not designed to market to invoice contacts as our own leads, resell their data, or contact them as a third-party collector.
  • Opt-out and suppression features are designed so email and SMS preferences can be honored; customers should configure and respect those controls.

If someone who was only ever an invoice contact contacts us about their data, we will typically redirect them to the business that used PayBlah and, where appropriate, assist that customer as processor Email hello@payblah.com (privacy) or use the Contact form; legal response times apply (Open decision P-SLA for a stricter public SLA).

Purposes of processing

Depending on role, purposes include:

  • Providing, securing, and improving the PayBlah service
  • Sending invoice reminders and related notices as configured by the customer
  • Syncing invoices and payments with connected accounting systems where the customer enables integrations (for example Xero, QuickBooks Online, or Sage)
  • Billing the subscription, preventing abuse, and meeting legal obligations that apply to us as a business
  • Operating this marketing site and, if accepted, optional analytics (see Cookie Policy)

Lawful bases (where GDPR-style rules apply)

Where the GDPR or UK GDPR applies to processing we control, bases are designed along these lines (final mapping is for counsel):

  • Contract — creating and running a customer account and delivering the subscribed service
  • Legitimate interests — securing the service, preventing fraud or abuse, limited product analytics where appropriate, and B2B marketing where permitted LIA documentation to be completed before launch (Open decision G-LIA)
  • Consent — optional marketing-site analytics cookies and other processing that requires consent under ePrivacy-style rules
  • Legal obligation — tax, accounting, or regulatory duties that apply to PayBlah itself

For processing we perform as a processor, the customer determines the lawful basis for contacting invoice parties and using PayBlah on their receivables. We do not invent a basis on their behalf.

Data-subject rights

Where applicable law grants rights of access, rectification, erasure, restriction, portability, or objection, those rights are designed to be honored as follows:

When PayBlah is controller

Contact hello@payblah.com (or hello@payblah.com) with enough detail to identify your request. We may need to verify identity before acting. You may also have the right to lodge a complaint with a supervisory authority (details below).

When PayBlah is processor

If your personal data appears only because a business used PayBlah on an invoice, please contact that business first. We are designed to assist controllers with rights requests that relate to data in our systems, under the DPA, rather than to re-decide the customer’s relationship with their invoice parties.

Account holders can export operational data from the product where export features are provided; see also Security (“Your data stays yours”).

Security design

PayBlah is designed with structural protections described on the Security page, including:

  • A database per customer tenant for operational isolation
  • API keys stored hashed; tenant secrets and tokens sealed at rest
  • CSRF protection on browser forms, password hashing, optional TOTP two-factor
  • High-entropy debtor-portal links with rate limiting
  • Scoped API keys, rate limits, and signed outbound webhooks
  • Support access that is reason-gated, time-boxed, and audited

No security page is a promise that incidents can never occur. Controls are designed to reduce risk; they are not marketed as formal certifications (we do not list third-party audit marks or similar unless separately published with evidence).

International transfers

PayBlah is built for businesses in the US, UK, Ireland, and Australia. Infrastructure and support may involve processing in more than one country.

Where personal data is transferred internationally in a way that requires safeguards under GDPR-style rules, we intend to use appropriate transfer tools (for example standard contractual clauses or successor mechanisms) and to document sub-processors once vendors are selected. Hosting, email, SMS, and payment providers are not yet named on this draft — see Sub-Processors.

Primary hosting regions and transfer mechanism schedule: Open decision P-REGION / DPA annexes — published when infrastructure is final.

Personal data breaches

If we become aware of a personal data breach affecting data we process, we are designed to investigate, contain, and assess risk without unnecessary delay. Where we act as processor, we are designed to notify the affected customer so they can meet their own notification duties. Where we act as controller, we will notify individuals and authorities when applicable law requires it.

Specific notification timelines, content templates, and on-call procedures remain operational details for counsel and launch readiness Internal incident runbook and customer notification process: Open decision G-INC. Nothing on this page guarantees a regulatory outcome after an incident.

Retention

Retention depends on role and data type:

  • Customer account and billing records — see Privacy Open decision P-RET
  • Invoice, message, and audit data held as processor — held for the life of the customer relationship and then deleted or returned under the DPA see Privacy / DPA Open decision P-RET
  • Security and abuse logs — see Privacy Open decision P-RET
  • Cookie consent records in the browser — until cleared by the user (see Cookie Preferences)

Children

PayBlah is a B2B business tool. It is not directed at children, and we do not knowingly collect personal data from children for the marketing site or product accounts.

Contact and supervisory authority

Privacy and general inquiries: hello@payblah.com · Contact form

Security vulnerability reports: security@payblah.com

Controller identity: PayBlah — see site footer (contact: Richard Brennan)

Data protection officer / privacy lead: DPO not appointed as of this draft (Open decision P-DPO)

Supervisory authority: If you are in the EEA or UK you may have the right to complain to a data protection authority. PayBlah’s lead or primary supervisory authority contact details are not finalized on this draft: For Ireland-related complaints: Data Protection Commission (dataprotection.ie) — confirm primary establishment with counsel (Open decision G-SA). You may also contact the authority in your country of residence where applicable law allows.

Draft website policies for product readiness — have qualified counsel review before public launch in each territory. This page describes how PayBlah is designed to approach data protection; it does not state that PayBlah is certified or fully compliant with the GDPR, UK GDPR, or any other regime until counsel and operational readiness say so.