Key Concepts

Prev Next

When working with Paynetics’ products and services, it is essential to understand the core building blocks of the platform and how they relate to one another. These concepts define how data is structured, how responsibilities are separated, and how payment flows are executed.

The diagram below illustrates the logical relationships between the main entities in the Paynetics platform. This page explains each concept individually and how it fits into the overall model.

Partner

A Partner is the entity that integrates Paynetics’ services and offers them to end customers or uses them for its own business.

Partners operate within their own instance and manage users, merchants, applications, and programs. They define end-customer (Users or Merchants) fees, user flows, and configurations within the limits of their contractual agreement.q

Instance

An Instance is a logically separated environment within the Paynetics platform. Each partner operates within a dedicated instance.

An instance contains all configuration and data related to that partner, including programs, users, merchants, accounts, cards, and transactions. API credentials issued to a partner are  associated with a specific instance.

During partner onboarding, Paynetics provisions:

  • a Sandbox instance for implementation and testing

  • a Production instance for live operation once partner onboarding is completed and the solution is validated

All objects created within the platform belong to exactly one instance.

Program

A Program defines the configuration under which accounts and cards operate.

Programs specify:

  • supported currencies

  • account and IBAN generation rules

  • availability of virtual and physical cards

  • default card behaviour such as limits, fees, usage controls, and wallet enablement

Each account is created under a specific program and references it via a program code. Programs are created and approved by Paynetics for each Instance and Partner during partner onboarding.

Programs establish default behaviour at both the account level and the card level. These defaults can be refined later through API configuration, where applicable.

User

A User represents a natural person within the partner’s instance.

Users may be associated with one or more accounts and may be cardholders for one or more cards. Users are typically created as part of the partner’s end-consumer onboarding flows.

Account

An Account is a payment or e-money account used to hold funds and execute transactions.

Accounts are created under a specific instance and program and are associated with either a user or a merchant. They provide the logical structure under which balances, cards, and transactions are organised.

Common account purposes include:

  • executing card payments and transfers

  • holding settlement funds

  • pre-funding services such as OCT

An account acts as a container for balances rather than holding funds directly.

Balance

A Balance represents an amount of funds held in a specific currency within an account.

An account may have multiple balances, one per supported currency. Balances are assigned payment identifiers such as IBANs or account numbers, depending on the currency.

All monetary operations reference a balance token, which is used in API calls to debit or credit funds, perform transfers, or apply fees.

Virtual Account

A Virtual Account is an account created to support advanced account and card structures.

Virtual accounts are commonly used to enable multiple cards to operate with a shared underlying balance while maintaining separate account and card-level controls. Each virtual account can have its own balance and associated card.

Virtual account balances always share the balances of the account they are linked to, and their value is always 0.

Card

A Card is a payment instrument linked to an account or a virtual account.

Cards can be issued as virtual or physical and can be configured for consumer or business use. Each card is associated with a single account and uses the balance of that account for transactions.

Card behaviour, including limits, fees, usage permissions, and wallet enablement, is defined by the program and card-level configuration.

Application

An Application represents an onboarding request submitted to Paynetics to create a merchant.

Applications capture merchant details, requested products, and configuration. They are submitted via API and generate an application token used for tracking.

Paynetics must approve an application. Upon application approval, a merchant is created.

Merchant

A Merchant is a business entity.

Merchants belong to a specific instance and can be associated with one or more accounts. Merchant configuration and enabled services are subject to underwriting and, where applicable, card scheme approvals for services such as OCT or AFT.

Merchants can be onboarded via API or manually as part of merchant onboarding.

  • API-based merchant onboarding is the recommended approach and supports scale and automation.

  • Manual merchant onboarding is suitable only for low volumes, typically around 10–15 merchants per month, where the effort of building and maintaining an API integration is not justified.

Merchants become operational once merchant onboarding is completed and the corresponding application has been approved.

MID and TID

A MID (Merchant ID) identifies a merchant at the card scheme for the acquiring product. A TID (Terminal ID) identifies a specific payment terminal or acceptance channel.

MIDs and TIDs are linked to merchants and are used during transaction processing to determine routing, permissions, and reporting.

Tokens

Tokens are unique identifiers used throughout the Paynetics platform to securely reference objects.

Tokens exist for instances, programs, accounts, balances, cards, merchants, and transactions. They are mandatory in API calls and ensure secure identification without exposing sensitive data, accurate routing of operations, and consistent handling across services.

For example, a balance token specifies which funds are debited or credited, a card token identifies the card used in a transaction, and a merchant token links activity to a specific merchant.

Partner Onboarding

Partner onboarding is the process through which Paynetics enables a partner to integrate and operate on the platform.

During partner onboarding:

  • a dedicated Sandbox instance is provisioned for implementation and testing,

  • a Production instance is provisioned for live operation once validation is completed,

  • program configuration, commercial setup, and access credentials are established.

Partner onboarding enables the partner to integrate Paynetics APIs and begin creating users, merchants, accounts, and cards within their instance.