Payments glossary: 24 terms and the boundaries that matter

Open banking and the participants

Open banking

Access to payment-account information or payment-initiation services through interfaces, with the relevant user permission and provider controls.

In practice: Identify whether a feature reads data or initiates a payment; those are different permissions.

PSD2 — Second Payment Services Directive

The EU payment-services framework that includes rules for account information, payment initiation and Strong Customer Authentication.

In practice: A sandbox can illustrate PSD2 mechanics without being a regulated payment service provider.

AISP — Account Information Service Provider

A provider of services that present information about a user’s payment accounts.

In practice: Reading a balance is not permission to spend it.

PISP — Payment Initiation Service Provider

A provider that initiates a payment order at a user’s request from an account held with another payment service provider.

In practice: Initiation and the payment’s eventual outcome need separate records.

ASPSP — Account Servicing Payment Service Provider

The payment service provider that provides and maintains a payer’s payment account.

In practice: Do not assume every participant in a payment flow is the account-holding bank.

Reference context: European Commission: payment services. Definitions are concise engineering explanations, not quotations from legislation or scheme rules.

Consent, authentication and mandates

Payment consent

The payer’s agreement to execute a payment or a defined series of payments.

In practice: Keep payment consent separate from account-data access and from a generic website login. Compare consent, SCA and agent authority.

SCA — Strong Customer Authentication

Authentication using at least two independent elements from knowledge, possession and inherence, under the applicable payment-services requirements.

In practice: A completed authentication step is not a settlement receipt.

Dynamic linking

Binding the authentication for an applicable remote electronic payment to the amount and payee.

In practice: Changing those details is not a harmless edit after approval. See Article 5 of the SCA regulation.

Agent payment mandate

A bounded record of what a particular software agent may do on an owner’s behalf.

In practice: In these ZILLQ guides, it includes terms such as payees, spending limits and expiry; it is not a universal industry schema. Explore mandate design.

SEPA Direct Debit mandate

The payer’s authorization for a creditor to collect payments by direct debit and for the payer’s bank to act on those collection instructions.

In practice: This is distinct from an agent policy for proposing credit transfers. See the EPC’s Direct Debit schemes.

Reference context: PSD2: definitions, consent and authentication. Definitions are concise engineering explanations, not quotations from legislation or scheme rules.

SEPA transfers and recipient checks

SEPA — Single Euro Payments Area

The area in which harmonised euro payment schemes operate across participating countries.

In practice: SEPA is a payment context, not a login standard or a synonym for the eurozone.

SCT — SEPA Credit Transfer

A euro credit transfer under the EPC’s SCT scheme, initiated on the payer’s side.

In practice: A credit transfer and a creditor-initiated direct debit follow different flows. See the EPC’s SCT overview.

SCT Inst — SEPA Instant Credit Transfer

The EPC scheme for instant euro credit transfers, with its own availability and execution requirements.

In practice: An instant rail does not make every browser callback or internal dashboard update instantaneous. See the EPC’s SCT Inst overview.

IBAN — International Bank Account Number

A standardised identifier for a bank account.

In practice: Valid format and check digits do not prove ownership, the intended beneficiary or merchant trustworthiness.

VoP — Verification of Payee

A check of supplied recipient details, such as an IBAN and name, against the receiving provider’s records.

In practice: A match is useful recipient evidence, not confirmation of payment settlement or a guarantee that a purchase is safe. Compare the VoP results. See the EPC’s VoP scheme.

Reference context: European Payments Council: credit transfers. Definitions are concise engineering explanations, not quotations from legislation or scheme rules.

Payment outcomes and reliable processing

Payment initiation

The act of submitting a payment instruction into the payment-service flow.

In practice: A successfully created payment resource is not proof that the beneficiary has been credited.

Settlement

The completion of the transfer of funds that discharges the relevant payment obligation within the payment arrangement.

In practice: An API’s “settled” label must be read within that provider’s contract. It may only be observable for some destinations.

Reconciliation

Matching payment instructions and provider outcomes to the corresponding account or ledger records.

In practice: Match references, amount, currency and destination; a matching timestamp alone is weak evidence. Investigate a pending payment.

Idempotency

A property that lets a repeated logical operation avoid creating an additional effect.

In practice: In payment APIs, key scope, request matching and retention rules are provider-specific. Test replay and changed-payload cases.

Webhook

An HTTP notification from one service to another about an event.

In practice: Validate its origin and handle duplicate or delayed delivery. Notification arrival order should not be treated as the authoritative payment order.

Reference context: TrueLayer: one provider’s status model and payment event reference. Definitions are concise engineering explanations, not quotations from legislation or scheme rules.

Identity and agentic payments

OAuth 2.0

A framework for granting a client limited access to protected resources.

In practice: Detailed transaction permissions can be carried with Rich Authorization Requests; the services still need to enforce them.

OpenID Connect (OIDC)

An identity layer on top of OAuth 2.0 that lets a client verify the end user’s authentication and obtain identity claims.

In practice: An ID token and an access token have different purposes. See OpenID Connect Core.

EUDI Wallet — European Digital Identity Wallet

A wallet framework for digital identity and electronic attestations, including use cases involving payment authentication.

In practice: ZILLQ offers wallet emulation with synthetic credentials; it does not claim to be a certified national wallet. Use the EUDI wallet testing guide.

Agentic payments

Payments in which a software agent helps choose, prepare or initiate a transaction within delegated authority.

In practice: Autonomy can vary. The agent’s recommendation, permission to spend and payment outcome should remain distinguishable. Read the agentic payments guide.

Reference context: IETF: OAuth security best current practice and EUDI payment authentication. Definitions are concise engineering explanations, not quotations from legislation or scheme rules.