> For the complete documentation index, see [llms.txt](https://docs.omni.integratedcommerce.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omni.integratedcommerce.io/glossary/accounts-and-api-access.md).

# Accounts and API access

Definitions of the people, accounts, identifiers, and access concepts used by the Omni-Channel Payment API.

These definitions describe how the Omni-Channel Payment API uses each term. In these docs, "you" means the ISV developer integrating the API; "merchant" means the business accepting payments.

## Account holder

A customer record used to group stored payment methods for one merchant. An account holder lets your application retrieve a customer's saved cards or bank accounts without keeping a separate list of token IDs. The API assigns an `aho_` ID, and you can also identify the record with your own `externalId`. See [Account holders](/payments/account-holders.md).

## API and endpoint

An application programming interface (API) is the set of requests your software can make to another service. The Omni-Channel Payment API lets your backend initiate payments, manage stored payment methods, retrieve transactions, and read settlement reports. An endpoint is a particular HTTP method and path, such as `GET /transactions`, that performs one of these operations.

## API key

A secret credential that identifies the merchant and environment for an API request. Your backend sends the complete key in the `x-api-key` header. A key gives access to its merchant's resources; it must stay out of browser code and public repositories. See [Authentication](/get-started/authentication.md).

## Authentication and access authorization

Authentication establishes who is making an API request by checking the API key. Access authorization determines which resources that caller can use, such as whether a payment method belongs to the key's merchant. The separate payment operation called [authorization](/glossary/payments-and-transactions.md#authorization) reserves card funds.

## Beta and invite only

Beta identifies a feature whose contract can still change while it is being introduced. Settlement reporting is currently in beta and enabled merchant by merchant. Invite only identifies a feature that requires access to be granted before use, such as Svix webhooks. The relevant feature guide states its availability and access process.

## Billing contact

The name and address information associated with the payment method used for a payment, returned as `billingContact` when available. The hosted form collects billing information for processing and verification. A billing contact describes that payment method's billing details; an account holder groups a customer's stored methods. See [Form configuration](/hosted-payment-form/form-configuration.md).

## Cardholder

The person to whom a payment card is issued. In a card checkout, the cardholder supplies the card and may complete an issuer authentication challenge. The cardholder is the payer; the merchant receives the payment.

## Certification

Fiska's review of an ISV's payment integration before it goes live. The review uses test transactions and evidence of configuration, outcome messages, and applicable webhook or browser-result handling to check the flows the integration supports. See [Certification](/going-live/go-live.md).

## Currency and region

Currency is the unit in which a payment or report amount is expressed: `USD` for US dollars or `CAD` for Canadian dollars. A payment method determines the currency of transactions started with it. Region identifies the applicable country, such as `US` or `CA`; it is a different field from currency. See [Request conventions](/get-started/conventions.md#currencies-and-regions).

## Customer

The person or organization paying a merchant for goods or services. A customer can pay with a card, bank account, or stored payment method. When the docs describe the "customer's browser," they mean the checkout browser used by that payer.

## External ID

An identifier assigned by your application to an account holder, supplied as `externalId`. It connects your existing customer record to the API's account holder and can be used wherever `accountHolderId` is accepted. Its format is yours to choose, and the lookup remains within the merchant's scope. See [Account holders](/payments/account-holders.md#two-ways-to-address-an-account-holder).

## Filtering, sorting, and pagination

Filtering selects records that meet conditions, such as a transaction's `referenceId` matching an order's payment attempt. Sorting controls their order, and pagination divides a result set into numbered pages. List endpoints expose these controls through `filters`, `sorts`, `page`, and `pageSize`; the available fields depend on the endpoint. See [Request conventions](/get-started/conventions.md#filtering-sorting-and-paging).

## Fiska

The service provider that exposes the Omni-Channel Payment API and partner portal to ISVs. Fiska connects the integration to payment processing, publishes transaction and account events, and provides settlement and fee information through reporting endpoints.

## Issuer

The financial institution that issued the customer's payment card. In these docs, the issuer makes card approval or decline decisions and performs cardholder authentication for 3D Secure. Issuer results are exposed through transaction response codes and, when applicable, `threeDs` data.

## ISV and partner

An independent software vendor (ISV) is the company integrating payment capabilities into software used by merchants. These docs also call the ISV a partner. An ISV can serve multiple merchants, but each current payment API key accesses the resources of its own merchant.

## Know your business (KYB)

Checks used to establish the identity and business details of a merchant during onboarding and review. The abbreviation also appears in statement fee wording. A fee carrying a KYB-related name does not by itself describe the checks performed or how the fee was calculated; use its reported description and the [fee guide](/settlement-reporting/fee-charges.md#fees-billed-on-a-monthly-statement-or-invoice).

## Merchant

The business accepting payments through the integration and receiving the resulting deposits. Payment methods, transactions, account holders, settlements, and fee charges belong to a merchant. The merchant is also the business billed for processing and service fees.

## Merchant application and onboarding

A merchant application is the information submitted to request a merchant account. Onboarding is the process of collecting that information, reviewing it, requesting any missing details, and setting up an approved merchant. Merchant lifecycle events report progress and decisions; approval creates the merchant account. See [Merchant lifecycle events](/webhooks/events.md#merchant-lifecycle-events).

## Partner portal

The Fiska website where ISVs manage merchant onboarding and related account tasks. Merchant lifecycle events can include a `portalLink` to the relevant record. For eligible ISVs, the portal also provides Svix webhook endpoint configuration, delivery inspection, and replay controls.

## Payment gateway

The service through which payment instructions reach the downstream processing systems and their results return to the API. Gateway errors describe a failure or rejection in that processing path. They can differ from an issuer's decision to decline a valid card payment.

## Payment processor and settlement provider

The downstream service that processes payment activity and reports the transfers and charges used to fund a merchant. In the reporting guides, "settlement provider" identifies the source of settlement and statement data. Its transaction IDs, batches, deposit totals, and fee records support reconciliation with Fiska transactions and the merchant's bank account.

## Pricing template

A reusable set of merchant pricing terms submitted for Fiska review and associated with onboarding links. A pricing-template approval makes those links active. The webhook payload identifies the template by name, region, and version so an ISV can track the decision. See [Merchant lifecycle events](/webhooks/events.md#merchant-lifecycle-events).

## Production and sandbox

Production is the environment for real merchant payment activity. Sandbox is the environment for development and test scenarios, including the published test cards. The payment API uses the same base URL for both and distinguishes them by the API key: `key_live_` or `key_test_`. The Payment SDK also has an environment setting that must match the session. See [Authentication](/get-started/authentication.md#environments).

## Resource and merchant scope

A resource is an object the API stores or reports, such as a transaction, payment method, or settlement. Merchant scope is the ownership boundary applied when the API resolves that object. A caller cannot access another merchant's resource by supplying its ID. See [Resource scope](/get-started/authentication.md#resource-scope).

## Resource ID and ULID

A resource ID is the identifier used to refer to one API object. Many IDs combine a resource prefix with a Universally Unique Lexicographically Sortable Identifier (ULID), such as `trx_` for a transaction. Keep the full ID unchanged. Hosted `sessionId` values and merchant lifecycle event IDs are opaque and need not follow that prefix format. See [Identifiers](/get-started/conventions.md#identifiers).

## Timestamp, UTC, and reporting date

A timestamp identifies an instant, expressed by the API in ISO 8601 format using Coordinated Universal Time (UTC). A reporting date identifies a calendar day, sent as `YYYY-MM-DD`, for selecting settlements or fee charges. A transaction timestamp, settlement date, and fee charge date describe different events and need not fall on the same day.

## Underwriting

The review stage in merchant onboarding where the application is assessed before a decision is made about providing payment services. An application can require more information before review continues. Merchant application status events let the ISV follow this process without treating submission as approval.

## Related

* [Payments and transactions](/glossary/payments-and-transactions.md) - payment resources and operations
* [Hosted forms and SDK](/glossary/hosted-forms-and-sdk.md) - browser integration and cardholder authentication
* [Webhooks and outcomes](/glossary/webhooks-and-outcomes.md) - events, statuses, and errors
* [Settlement and fees](/glossary/settlement-and-fees.md) - deposits, reconciliation, and charges