Glossary of Concepts

This glossary provides definitions for the terms used throughout the Payment Nexus Operator Guide.

Payment Entities

Term	Definition
Payment Intent Ticket (PIT)	A record that tracks the lifecycle of a customer's intent to make a payment — from creation through to a final outcome. It moves through a series of statuses (see Payment Intent Status Lifecycle below) as the payment progresses: collecting a payment method, authenticating the customer, processing with the PSP, and ultimately succeeding or being cancelled. Each PIT records the amount in the original transaction currency alongside a EUR-normalised equivalent. The PIT represents the intent; the PSP handles the underlying charge attempts directly.
Checkout Intent Ticket (CIT)	A record of a customer-facing checkout session, created when a brand's platform sends a customer to the Payment Nexus checkout flow. The CIT captures the payment amount, currency, and destination URLs for each outcome. The checkout session expires 15 minutes after the URL is opened. When the customer initiates payment, a Payment Intent Ticket is created and attached to the CIT. If the session expires before the customer acts, the CIT remains unlinked to any payment.
Destination URLs	The set of URLs configured on a Checkout Intent Ticket that determine where the customer is sent after the payment resolves. There is one destination for each outcome: Success, Failure, Pending, Cancel, and Completed. Destination on Completed acts as a fallback for Success and Failure — if the specific destination is not set, Payment Nexus redirects to Completed instead. If no applicable destination is configured, the customer stays on a result page within Payment Nexus.
Tenant	An isolated business entity within Payment Nexus — commonly referred to as a brand within the organisation. Tenants relate to CRM vendors the same way PSPs relate to PSP vendors: each tenant can be connected to a CRM vendor via an adapter, and multiple tenants can use the same CRM vendor. Each tenant has its own branding, domain configuration, customer records, and PSP assignments. A single Payment Nexus deployment hosts many tenants, and data is strictly separated between them.
CRM Vendor	A CRM integration — the adapter that connects Payment Nexus to a specific customer relationship management platform. The vendor defines the communication protocol used to exchange customer and payment event data. Multiple tenants can use the same CRM vendor.
PSP Vendor	A payment integration — the adapter that connects Payment Nexus to a specific type of payment processor (e.g. Praxis Nuvillon, Tylt OpenBanking, Passpoint). The vendor defines the capabilities, payment channels, and communication protocol. Multiple PSP accounts can use the same vendor.
Payment Service Provider (PSP)	A specific account with a PSP vendor — the credentials and configuration that identify a particular merchant account or API key set at that provider. Think of the vendor as "Stripe" and the PSP as "our Stripe account". A PSP is a global resource that can be assigned to multiple tenants.
Tenant PSP	The assignment of a PSP to a tenant, with the payment channels enabled for that combination. The same PSP can be assigned to different tenants with different channel configurations.
Tenant Customer	A customer record scoped to a specific brand — the hub for everything Payment Nexus knows about that customer within that brand. Identified by the brand's own customer ID, it holds encrypted PII (name, email, phone, billing and shipping addresses) and links to the customer's payment history and PSP customer accounts. Created by the brand's CRM integration; read-only in the management portal.
PSP Customer Account	A provider-issued account held on behalf of a customer — for example a virtual IBAN, a crypto wallet address, or a stored payment token. When a PSP creates an account for a customer, Payment Nexus records it and links it to both the tenant customer and the PSP. Accounts are created by the PSP integration; operators can view them but cannot create or modify them from the management portal.
Payment Channel	A specific payment method made available to customers in checkout — for example "Credit Card", "GPay", or "Deposit BTC". Each channel comes from a PSP account and carries the PSP's channel type, which determines which category it appears under (Open Banking, Credit Card / GPay / ApplePay, Crypto, or Uncategorized). Operators can customise the channel name and icon shown to customers.
Channel Flow	The checkout interaction style used by a payment channel — for example Form (the customer enters details inline) or Redirect (the customer is sent to the PSP's own page to complete payment). Determined by the PSP integration and cannot be changed by operators. The flow also affects which fields appear in the manual creation wizard's Channel Information step.
Compliance Status	A classification assigned to a tenant customer by the CRM indicating their verification or compliance level (e.g. verified, pending, restricted). PSP restrictions can be configured to allow only customers with specific compliance statuses to access a given PSP's channels.
Domain	A fully qualified domain name (FQDN) assigned to a tenant. Defines how traffic arriving at that hostname is routed into the Payment Nexus system. A tenant can have multiple domains — typically one primary production domain and one or more sandbox domains for testing. Sandbox domains additionally expose PSP integrations in the Development / QA release state, making them visible in checkout for testing before those integrations reach UAT.
Activation	An operator-controlled on/off switch on a whole Tenant or PSP, independent of deletion. When disabled, the entity is treated as if it no longer exists to the public: a disabled tenant's checkout returns Not Found and a disabled PSP is removed from every tenant's checkout, and in both cases their API credentials stop authenticating. Disabling is non-destructive and fully reversible — all records, configuration, links, and payment history are preserved and restored on re-enable. Distinct from Release State (which governs an integration's dev-qa→production pipeline) and from a Tenant PSP link (which enables/disables a single tenant↔PSP pairing rather than the whole entity).

Metrics

Term	Definition
Success Rate	The percentage of Payment Intent Tickets that reached the succeeded status, out of all PITs in the measured scope and period. Formula: succeeded ÷ total × 100. Only succeeded counts as approved — all other statuses (cancelled, processing, requires action, etc.) count as not approved.
Volume	The total value of approved (succeeded) Payment Intent Tickets, expressed in EUR. Each PIT stores a EUR-normalised amount calculated at the time of the transaction using the exchange rate for its currency. Volume always aggregates this normalised EUR figure, not the original transaction currency.
Approved Count	The number of Payment Intent Tickets with status succeeded in the measured scope and period. Used in "by Count" leaderboards and daily count charts.

Payment Intent Status Lifecycle

A Payment Intent Ticket moves through the following statuses:

Status	Meaning
requires_payment_method	Awaiting a payment method from the customer
requires_confirmation	Payment method collected, awaiting confirmation
requires_action	Additional customer action required (e.g. 3DS authentication)
processing	Submitted to the PSP, awaiting a result
requires_capture	Authorised but not yet captured
succeeded	Approved — payment completed successfully
canceled	Terminal non-success state — the payment did not complete

Only succeeded PITs contribute to success rate and volume figures. All other statuses — including processing, requires_action, and canceled — count as not approved.

Payment Intent Ticket Operations

Term	Definition
Disposition	The act of manually setting the outcome of a Payment Intent Ticket that is in a non-terminal status (i.e. not yet succeeded or canceled). Used when a payment needs to be resolved without waiting for an automated PSP response — for example, to mark a payment as succeeded after confirming receipt outside the system.
Disposition Override	The act of changing the outcome of a Payment Intent Ticket that has already reached a terminal status (succeeded or canceled). Requires elevated permission and is used to correct a payment that was resolved incorrectly.

Administration

Term	Definition
Role	A named set of permission assignments. Each capability on a role is set to Granted, Inherited, or Denied. Users can hold multiple roles; their effective permissions are the union of all roles, with Deny taking absolute precedence over Grant.
Capability	A named permission string (e.g. tenant:read, payment_intent_ticket:create) that controls access to a specific action or data within Payment Nexus.
Super Admin	A user flag that bypasses role-based access control entirely. A super admin implicitly holds every capability in the system.
PSP Integration	A versioned software adapter that connects Payment Nexus to a specific PSP vendor. Managed through the PSP Integrations module and progresses through a release pipeline (dev-qa → production) before it can be used in production tenants.
CRM Integration	A versioned software adapter that connects Payment Nexus to a specific CRM platform. Managed through the CRM Integrations module and uses the same release pipeline as PSP Integrations.
Release State	The stage of the release pipeline for a PSP or CRM integration. States progress in order: Development / QA → UAT → Post-Update UAT → Production, and can be rolled back to Deprecated or Suspended. Each integration's current state is shown as a badge on channel cards and PSP records.

Integration

Term	Definition
Access Token	A credential issued by Payment Nexus that an external system (such as a CRM) includes with each inbound API request to prove it is authorised. Each token is scoped to a specific set of permissions and one or more whitelisted IP addresses.
CRM API	The API that Payment Nexus exposes for each brand's domain, through which the brand's CRM system integrates. The API URL for each brand also serves as the address of its interactive API documentation — the reference that should be provided to the CRM vendor during integration. The documentation includes the Webhook Event Payload schema, which the CRM vendor needs to build the endpoint that receives payment event notifications from Payment Nexus.
Webhook Event Payload	The JSON body that Payment Nexus sends to the CRM vendor's own webhook endpoint when a payment event occurs (e.g. a payment succeeded or failed). The structure is defined in the brand's API documentation. The CRM vendor team uses this schema to build the receiving endpoint on their side.
Silent Authentication	A login mechanism where the CRM generates a token via the CRM API and sends the customer directly to a pre-authenticated session, without the customer entering credentials. Used to link a CRM user to a Payment Nexus checkout session.
Incoming Webhook URL	A URL exposed by Payment Nexus that a PSP calls to report a transaction outcome (e.g. a payment confirmed or declined). Payment Nexus acknowledges the notification immediately and processes it in the background. Each PSP has two variants: a standard URL and a sparse URL for PSPs that require plain-text responses.
Sparse Webhook URL	A variant of the Incoming Webhook URL that always responds with plain text. Intended for PSPs that cannot handle structured response bodies. The response code and body text for both success and failure cases can be customised via query parameters (eCode, eText, eError).
Reconciliation	The process by which Payment Nexus checks back with the PSP on payments that have not yet reached a final outcome. Payment Nexus runs reconciliation on a tiered schedule — recent payments are checked frequently, older ones less so — and stops once a payment succeeds or is cancelled. If a PSP notification was missed or delayed, reconciliation ensures the payment is eventually resolved. Operators can also trigger a manual reconciliation check using the Refresh from PSP action on any Payment Intent Ticket.

The Access Token value is shown only once at creation and cannot be retrieved afterwards. If a token is lost, it must be deleted and a new one created.

Debug Tools

Term	Definition
HTTP Requester	A Postman-style request builder built into Payment Nexus. Requests originate from the application server rather than the browser, making it useful for testing PSP and CRM endpoints exactly as the application would reach them.
Pre-Request Script	A JavaScript snippet configured in the HTTP Requester that runs on the server before a request is dispatched. Used to dynamically modify the request — for example, computing a time-sensitive HMAC signature and injecting it as a header.
AMQP Queue	A message queue managed by the LavinMQ broker. Payment Nexus uses queues to process background work asynchronously — inbound PSP webhooks, outbound CRM notifications, and more. The Queues page surfaces publish/consume rates, queue depth, and consumer counts in real time.
Dead-Letter Queue (DLQ)	A holding queue for messages that were rejected or could not be processed by their source queue. Every operational queue has a corresponding DLQ named dlq.{queue-name}. Failed messages accumulate here and can be inspected, replayed to the source queue, or permanently discarded.
Backlog	The total number of messages sitting in a queue — the sum of ready messages (waiting for a consumer) and unacknowledged messages (delivered to a consumer but not yet confirmed). A non-zero backlog means processing has fallen behind or stalled.
Cron Job	A scheduled background task that runs at a fixed interval. Payment Nexus uses a distributed scheduler backed by PostgreSQL to ensure each job runs exactly once per interval even across multiple instances. Most cron jobs are tiered reconciliation jobs that keep Payment Intent Tickets in sync with PSPs and CRMs — recent tickets are checked frequently, older ones less so.

Authentication & Access

Term	Definition
Identity Provider (IdP)	A secure service that manages user identities and verifies who you are when you log in (e.g. Microsoft Azure AD, Okta, or Google Workspace).
Single Sign-On (SSO)	An authentication mechanism that lets you use one set of credentials to access multiple applications.
Authentication	The process of verifying the identity of a user or device.
Session Expiry	A security feature that automatically logs you out after a period of inactivity.
Multi-Factor Authentication (MFA)	A security process that requires two or more forms of identification before granting access.

Directory Features

Term	Definition
Directory	Any list-based module page in the Payment Nexus Management UI (e.g. Tenants, Payment Intent Tickets). All directory pages share a common set of tools for searching, filtering, sorting, and acting on records.
Filter Builder	A UI panel for constructing search conditions against specific record fields. Conditions can be combined with AND or OR logic and grouped into nested condition groups.
Power Search	An advanced search mode where you type raw Lucene query syntax directly into the search field, expressing the same conditions as the filter builder in text form.
Lucene	An open-source query syntax used for full-text search and filtering. In Payment Nexus, it is the underlying format used by the Power Search feature and the filter builder.
Row Action	An operation that applies to a single record in a directory, accessible via buttons in the row or a right-click context menu (e.g. View, Edit, Approve).
Bulk Action	An operation applied to multiple records at once — either a selected subset or all records matching the current search and filters.
Aggregation	A summary statistic computed across all records matching the current search and filters — such as a sum, average, minimum, maximum, or distinct count. Displayed beneath column headers in supported directories.
Auto-Refresh	A directory feature that automatically reloads the results at a regular interval, keeping the view up to date without manual intervention.