Getting started

This section will help you understand not only the key definitions and common terms, but also how Ontime’s onboarding and availability processes work in practice.

In the following sections, you’ll find:

Process Overviews – High-level breakdowns of the four key availability and onboarding flows.

Best Practices – How to reduce data-entry friction and maximise adoption.

Integration Guidance – Understanding how Ontime links with Payroll Provider records.

Schema and API documentation

Authentication and Authorisation processes

Key Considerations – Risks, responsibilities, and dependencies.

Four Core Flows

The Ontime integration splits into an 'Availability & Onboarding' phase and a 'Salary Deduction' phase. These phases are made up of four interlinked flows:

Light Availability Check

A streamlined method for verifying employee presence in payroll data without unnecessary data collection. This is used by Billers to gain early confidence where an Application is likely to be supported for Salary Deduction.

Full Availability Check

A more detailed validation process to get a certain match at the point the Applicant has expressed interest in paying via Salary Deduction.

Onboarding

Passing the Applicant's legal agreement to the Payroll Provider allowing them to perform Salary Deduction on their behalf.

Salary Deduction

Ongoing synchronisation for Ontime to provide Salary Deduction information to the Payroll Provider and for the Payroll Provider to provide confirmation. This process describes the execution, reconciliation, and exception management.

Definitions

Understanding the terminology and core identifiers used for Salary Deduction is essential for successful integration and communication across systems.

These definitions establish a shared language between Billers, Payroll Providers, and Marketplace partners, ensuring that all parties interpret data points consistently

By standardising key identifiers—such as employee records, payroll provider references, and national registration numbers—we minimise ambiguity, streamline onboarding, and maintain compliance with industry and regulatory standards.

Core entities

Name	Definition
Payroll Provider	A provider of payroll services and software. A Payroll Provider typically provides software to multiple Employers and supports multiple Payrolls
Payroll	An Employer may operate multiple distinct Payrolls to serve different “pools” of personnel. Each Payroll instance typically has its own Pay schedule (e.g. weekly, bi-weekly, monthly) and accounting cost centers.
Employer	An entity who may use software or services provided by a Payroll Provider to manage one or more Payrolls.
Employee	A person who is employed by an Employer and may be on a Payroll that is managed by software or services provided by a Payroll Provider.
Biller	A utility or credit company or other firm who wishes to take payments from a person in exchange for a product or service
Applicant	A consumer who may become a customer of a Biller and who may want to pay using Ontime
Product Provider	A company, such as Ontime, who utilises deduction capabilities provided by Payroll Providers to provide services to Billers.

Common Identifiers

Name	Definition
CustomerId	An identifier created by the Biller to uniquely identify a customer. This reference MUST be guaranteed to be unique within the universe of a specific Biller.
EmployeeId	An identifier created by the Payroll Provider that MUST uniquely identify an Employee within the universe of a Payroll.
PayrollId	An identifier created by the Payroll Provider that MUST uniquely identify a Payroll within the universe of a Payroll Provider

Other definitions

Name	Definition
PayDate	The pay date for the pay period being processed by a Payroll Provider for a Payroll. For example 28th of March 2024 could be a PayDate for a monthly Payroll processed in March.
NR Number	National Registration Number. An identifier that MUST uniquely identify an Employee within a jurisdiction
NI Number	National Insurance number; in the UK synonymous with National Registration number
Ontime Platform	A collection of secured REST API endpoints and services provided to Payroll Providers and Billers.

Terms

The terms “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are all to be understood exactly as they are defined in RFC 2119. In order to ensure unambiguous interpretation of this specification, these words are used only to convey the levels of requirement defined by that RFC and have no other meaning in this context.

Term	Definition
MUST, REQUIRED, or SHALL	Indicates an absolute requirement of the specification: any implementation or usage that does not satisfy this clause is non-compliant.
MUST NOT or SHALL NOT	Denotes an absolute prohibition: any implementation or usage that does so is non-compliant.
SHOULD or RECOMMENDED	Signifies a recommended course of action. There may exist valid reasons in particular circumstances to ignore this recommendation, but implementers are encouraged to do so only when those reasons are clearly understood and documented.
SHOULD NOT	Indicates a behavior that is generally undesirable but not strictly forbidden—implementers may choose to deviate only with full awareness of potential consequences.
MAY or OPTIONAL	Denotes a truly optional feature: implementers are free to include or omit it, without affecting conformance.

By adhering to these definitions exactly, readers and implementers can be confident that every requirement and recommendation in this document is stated with precise, universally understood intent. For the full normative definitions, see RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.”

Getting started

In the following sections, you’ll find:#

Four Core Flows#

Definitions#

Core entities#

Common Identifiers#

Other definitions#