TradePact Learn

TradePact Network Participants, Role Separation, and Protocol Admission Criteria

Learn how TradePact Network participants like InvoiceMediator and PaymentMediator operate under TradePact Protocol v1.0 and the 4 admission criteria.

Published

East Asian corporate governance executives in navy blazers confer at an oak table in a sunlit Singapore boardroom with subtle amber accents.

TradePact Network participants—including InvoiceMediator (invoicemediator.com) and PaymentMediator (paymentmediator.com)—are distinct party-facing engagement brands that operate under TradePact Protocol v1.0 (effective 1 January 2026, operated by ChaseFlow Pte Ltd, UEN 202542183C, Singapore). The protocol enforces a three-layer separation of roles: Participants supply the dedicated engagement domain and payment portal subdomain (pay.<domain>), Infrastructure (operated by ChaseFlow) runs the underlying communication, evidence exchange, and record-keeping rail, and Intelligence (operated by Late Payer Index) handles behavioural reporting. No participant ever holds, routes, or touches funds belonging to a supplier or paying party, and prospective external participants are admitted only if they satisfy four published protocol admission criteria.

This guide is for finance and accounts payable teams verifying invoice correspondence from InvoiceMediator or PaymentMediator on tradepact.network, as well as billing platforms, accounting providers, business service firms, and trade bodies evaluating the TradePact Protocol admission criteria to launch their own engagement brand.

Key Takeaways (TL;DR)

  • Three-layer role separation: TradePact Protocol v1.0 separates the party-facing engagement brand (Participants such as InvoiceMediator and PaymentMediator) from the underlying execution rail (Infrastructure, operated by ChaseFlow) and behavioural reporting (Intelligence, operated by Late Payer Index).
  • Non-custodial settlement: Participants facilitate structured invoice communication, dispute flagging, and payment coordination, but never hold or process funds; payments are settled directly between the paying party and the supplier.
  • Public TradePactID verification: Every registered invoice carries a 15-character TradePactID (for example, 20260813000001A) verifiable at https://tradepact.network under a closed five-field public schema that never exposes company names, contact details, or invoice amounts.
  • Four strict admission criteria: External organisations applying via participants@tradepact.net must supply a distinct engagement brand separate from their primary product brand, display the B2B receivables trust mark on every touchpoint, route all engagement exclusively through network infrastructure, and maintain strict neutrality with no debt collection, debt purchase, or legal enforcement business.
  • Signed-in Participant Console: Approved participants manage their network-owned brand identity (tradepact_brand_participants), verify DNS records for email and pay.<domain> subdomains, and review registered invoices at https://tradepact.network/participant.

What is a TradePact Network participant, and how does the three-layer architecture separate roles?

A TradePact Network participant is an approved receivables engagement brand that communicates with invoice recipients, coordinates payment resolution, and exchanges structured evidence under the shared standards of TradePact Protocol v1.0 (https://tradepact.net/protocol).

In traditional accounts receivable follow-up, a single software tool or agency often blends brand identity, software hosting, and collection incentives into one opaque operation. TradePact Network replaces fragmented bilateral follow-up with a multi-brand B2B receivables engagement infrastructure organized into three distinct layers under one protocol (https://tradepact.net):

Protocol LayerEntity / OperatorPublic & Technical SurfaceCore Responsibility & Scope Limits
Layer 1: InfrastructureChaseFlow (ChaseFlow Pte Ltd, UEN 202542183C, Singapore)Execution rail, /_seam/v1 status projection publisher, and /_portal/v1 portal relayOperates all communication delivery, structured evidence storage, resolution workflows, and cryptographic record-keeping. Never acts as the party-facing engagement brand on participant notices.
Layer 2: ParticipantsInvoiceMediator, PaymentMediator, and approved external participant brandsDedicated brand domain (e.g., invoicemediator.com, paymentmediator.com) and payment portal subdomain (pay.<domain>)Serves as the neutral, party-facing engagement brand for invoice follow-up, dispute flagging, and structured payment coordination. Never self-hosts off-protocol software and never holds or touches party funds.
Layer 3: IntelligenceLate Payer Index (LPI)https://latepayerindex.comAggregates verified, protocol-governed payment behaviour patterns across the network and handles behavioural reporting data correction and disputes. Never conducts invoice follow-up.

Why role separation matters for suppliers and paying parties

Separating the engagement brand from the execution rail and behavioural intelligence ensures accountability at every step of an invoice lifecycle:

  1. Consistent protocol rules across brands: Whether an invoice is managed through InvoiceMediator or PaymentMediator, the underlying communication standards, evidence logging, and status reconciliation follow the same deterministic code path on ChaseFlow-operated infrastructure.
  2. Database and process isolation: As documented in the TradePact architecture (codebase/TradePact/docs/tradepact-app.md, as of commit d167dd515884), the public status site at https://tradepact.network runs as an independent process with its own database (TRADEPACT_DATABASE_URL). ChaseFlow derives the public status projection and publishes it one-way over /_seam/v1; the public status site has no internal concept of a chase workflow, creditor, or debtor.
  3. Clear boundary between resolution and credit reporting: Neither the TradePact Protocol nor any network participant operates as a credit bureau or credit rating agency (https://tradepact.net/protocol). Formal disputes or requests for data correction regarding behavioural reporting are handled separately by the Late Payer Index under its own published procedures.

How do InvoiceMediator and PaymentMediator operate on the TradePact Network?

InvoiceMediator and PaymentMediator operate as active network participant brands governed by TradePact Protocol v1.0, providing neutral post-issuance invoice follow-up, evidence exchange, and payment resolution between commercial suppliers and their customers (https://tradepact.net).

Today, all active participants on the TradePact Network are operated by ChaseFlow (https://tradepact.net). Expansion of the participant layer to eligible external organisations—specifically billing and accounting providers, business service firms, and trade bodies—is open by application through participants@tradepact.net.

1. Non-custodial direct settlement

Every participant on the TradePact Network operates under a strict non-custodial rule (https://tradepact.net/protocol):

  • No custody of funds: Neither InvoiceMediator, PaymentMediator, nor the underlying infrastructure ever holds, pools, routes, or touches funds belonging to a supplier (creditor) or a paying party.
  • Direct commercial settlement: When an invoice recipient views payment details or proposes a payment arrangement on a participant's portal (pay.<domain>), the actual transfer of funds occurs directly between the paying party and the supplier's designated bank account or payment facility.
  • Not a debt collector or enforcement agency: Network participants facilitate structured communication and early dispute resolution from invoice issuance onward. They do not purchase distressed debt, charge contingent collection commissions on recovered balances, or initiate legal enforcement proceedings.

2. Public verification via TradePactID on tradepact.network

When a finance team receives an email, letter, or portal link from InvoiceMediator or PaymentMediator, the correspondence carries a 15-character TradePactID (formatted as an 8-digit registration date, a 6-digit sequence number, and a 1-letter checksum, such as 20260813000001A) alongside the B2B receivables trust mark.

Any recipient can verify the authenticity of the notice at https://tradepact.network (see our verification walkthrough in How to Verify Third-Party Invoice Correspondence and Participant Notices). To protect commercial confidentiality, the public record renders a strict five-field closed schema (codebase/TradePact/docs/tradepact-app.md, as of commit d167dd515884):

  1. TradePactID: The canonical 15-character protocol reference.
  2. Status: Strictly one of Paid, Unpaid, or Unknown.
  3. Masked invoice number: A partially masked reference allowing the recipient to match their internal ledger without exposing sensitive identifiers publicly.
  4. Invoice date: The issue date of the registered invoice (YYYY-MM-DD).
  5. Managing participant: The registered name and content-addressed logo of the participant brand managing the record (e.g., InvoiceMediator or PaymentMediator).

Individual lookup pages never publish supplier names, buyer names, contact details, or invoice currency amounts, and every record response carries X-Robots-Tag: noindex, nofollow and Cache-Control: no-store headers (explained in detail in Masked Invoice Lookup Privacy and Data Minimization on the TradePact Network).


What are the four TradePact Protocol admission criteria for prospective participants?

The TradePact Protocol admission criteria are the four mandatory governance, technical, and neutrality requirements published in TradePact Protocol v1.0 (https://tradepact.net/protocol, effective 1 January 2026) that an organisation must meet to operate a participant brand on the network.

Under the model "Bring the brand. We run the rail." (https://tradepact.net), billing and accounting platforms, business service firms, and industry trade bodies can offer structured receivables engagement under their own dedicated brand using ChaseFlow's embedded receivables engagement rail, without building or staffing an in-house receivables operation. Every application submitted to participants@tradepact.net is evaluated against the following four criteria:

CriterionProtocol RequirementWhy the Standard Exists
1. Distinct Engagement BrandThe applicant must supply a dedicated engagement brand—including a separate domain name, brand identity, and payment portal subdomain (pay.<domain>)—that is distinct from the applicant's primary commercial product brand.Preserves clear role separation for the invoice recipient so third-party protocol mediation is never confused with a billing software vendor's core product support or marketing emails.
2. Display of the B2B Receivables Trust MarkThe participant must display the TradePact Network mark on every party-facing touchpoint, including all invoice correspondence and pay.<domain> portal pages.Gives invoice recipients an immediate, recognisable signal that the communication is governed by the TradePact Protocol and verifiable via TradePactID on tradepact.network.
3. Exclusive Routing Through Network InfrastructureAll party communication, evidence exchange, dispute resolution workflows, and record-keeping must run exclusively on network infrastructure operated by ChaseFlow.Prevents shadow channels, unlogged off-protocol contact, and fragmented audit trails. Participants do not self-host or modify the underlying protocol execution engine.
4. Neutrality & No Conflicting Financial InterestThe participant must hold no conflicting financial interest in the outcome of registered invoices and must not operate a debt purchase, debt collection, or legal enforcement business.Protects the neutrality of the shared receivables record (https://tradepact.network/learn/what-is-a-shared-receivables-record) and ensures engagement remains constructive rather than adversarial.

Grounds for decline or revocation of participant status

Under TradePact Protocol v1.0 (https://tradepact.net/protocol), ChaseFlow Pte Ltd reviews applications against the four criteria above and declines or revokes admission when an organisation:

  • Proposes to send receivables follow-up directly from its main commercial software or corporate marketing domain rather than a dedicated participant brand domain.
  • Operates a contingent debt collection agency, purchases overdue receivables for its own account, or conducts legal enforcement litigation.
  • Seeks to self-host part of the communication or payment portal workflow outside the ChaseFlow-operated rail, which would break the integrity of the shared receivables record.
  • Omits the TradePact Network mark or TradePactID verification reference from recipient-facing notices.

Commercial terms and onboarding arrangements for external organisations applying to operate a participant brand are reviewed during the application process via participants@tradepact.net.


How does the signed-in Participant Console (/participant) manage brand identity and technical onboarding?

The TradePact Participant Console (https://tradepact.network/participant) is the authenticated web interface on the status host where approved participant owners onboard their brand, manage network-owned brand metadata, verify DNS configuration, and inspect registered invoices (codebase/TradePact/docs/participant-area.md, as of commit d167dd515884).

While public TradePactID lookup pages are strictly read-only, /participant provides a secure operational boundary between the TradePact Network registry (tradepact_brand_participants) and ChaseFlow's execution engine:

1. Authenticated handoff and session security

  1. Single-use identity handoff: Selecting Participant sign-in on tradepact.network initiates a 10-minute state-cookie handoff to ChaseFlow's /tradepact/sign-in endpoint, which authenticates the user and returns a single-use, 60-second authorisation code.
  2. Server-to-server redemption: The TradePact process redeems the code server-to-server over an authenticated identity header (x-tradepact-identity-key).
  3. Short-lived session revalidation: The resulting session cookie (Secure, HttpOnly, SameSite=Lax) stores only a SHA-256 digest in TradePact's database, expires absolutely after four hours, and rechecks participant active status with ChaseFlow every two minutes (or every 20 seconds while a newly created brand is syncing).

2. Network-owned brand registry (tradepact_brand_participants)

With BRAND_PARTICIPANTS_ENABLED active in production (codebase/TradePact/docs/participant-area.md, as of commit d167dd515884), the TradePact Network registry is the authoritative source of truth for a participant's public identity:

  • First-brand onboarding (/participant/brands/new): An approved participant owner with no existing brand can register their first engagement brand by supplying the brand name, home country, contact email address, and postal address. The server mints a UUID, locks ownership (owner_user_id), and syncs the record with ChaseFlow's periodic participant sweep.
  • Identity and logo management: Participant owners manage their brand name, contact emails, postal address, and logo bytes directly in the registry. Logo images are stored by content hash in tradepact_participant_logos so public invoice records on tradepact.network render without depending on private internal application URLs.
  • DNS verification for email and pay.<domain> portals: The console displays the required DNS records provisioned by ChaseFlow for outbound email authentication and the pay.<domain> payment portal subdomain, including an interactive Test check that validates live DNS propagation before any sending identity is activated.
  • Registered invoice directory (/participant/brands/:id/invoices): Participant owners can view and filter (Unpaid, Paid, Unknown) the invoices registered under their brand, displaying the exact five public fields shown on the public status page (TradePactID, masked invoice number, invoice date, and status).

Frequently Asked Questions

What is the relationship between InvoiceMediator, PaymentMediator, and TradePact Network?

InvoiceMediator and PaymentMediator are network participant brands operating under TradePact Protocol v1.0 on the TradePact Network (https://tradepact.net). Both brands are currently operated by ChaseFlow Pte Ltd (UEN 202542183C, Singapore). They act as the party-facing engagement layer for structured invoice follow-up and payment coordination, while ChaseFlow operates the underlying infrastructure rail and tradepact.network publishes the verifiable status record for each TradePactID.

Does a TradePact Network participant hold or process payment funds?

No. Under TradePact Protocol v1.0 (https://tradepact.net/protocol), neither the TradePact Network nor any participant brand (including InvoiceMediator and PaymentMediator) ever acts as a payment processor, escrow agent, or custodian of funds. No participant holds or touches money belonging to a supplier or a paying party; all invoice settlements are paid directly between the commercial counterparties.

What are the four admission criteria to become a TradePact Network participant?

To be admitted under TradePact Protocol v1.0 (https://tradepact.net/protocol), an applicant must: (1) provide a distinct engagement brand with a separate domain and pay.<domain> subdomain independent of its primary commercial product brand; (2) display the TradePact Network trust mark on every party-facing correspondence and portal page; (3) route all communication, evidence exchange, and record-keeping exclusively through ChaseFlow-operated network infrastructure; and (4) hold no conflicting financial interest in invoice outcomes and operate no debt collection, debt purchase, or legal enforcement business.

How can an invoice recipient verify a notice from InvoiceMediator or PaymentMediator?

Locate the 15-character TradePactID (for example, 20260813000001A) printed on the email or payment portal notice and enter it directly into the public lookup at https://tradepact.network. A genuine registered record returns the TradePactID, current status (Paid, Unpaid, or Unknown), masked invoice number, invoice date, and the managing participant's name and logo. If the lookup returns a 404 Not Found response, no public record exists for that identifier.

Why is PaymentMediator in Microsoft documentation unrelated to TradePact Network?

Search results for "PaymentMediator" often surface legacy Microsoft Universal Windows Platform (UWP) developer documentation for the Windows.ApplicationModel.Payments.PaymentMediator software class. That Microsoft API class is an operating-system developer interface and has no connection to PaymentMediator (paymentmediator.com), the B2B receivables engagement participant operating under the TradePact Protocol.

How does an external organisation apply to operate a participant brand on the TradePact Network?

Billing and accounting software providers, business service firms, and industry trade bodies can apply by contacting participants@tradepact.net (https://tradepact.net/protocol). ChaseFlow reviews the proposed engagement brand domain, neutrality posture, and technical readiness against the four published protocol admission criteria before provisioning access to the signed-in Participant Console at https://tradepact.network/participant.


Explore the Receivables Engagement Infrastructure

Whether you are verifying a participant notice on tradepact.network or evaluating how protocol-governed receivables engagement works in practice, you can see the underlying workflow directly.

Watch the customer journey, the interactive demo and get started for free

Have a TradePactID from an invoice?

Look up a TradePactID on the network →
← All articles