Category: Transaction Processing

Settlement

Simply put

In payments, settlement is the step where the money for approved transactions actually moves between the parties, typically resulting in funds being transferred to the merchant's account. It happens after a transaction is authorized and completes the exchange of value. Note that the evidence provided here primarily describes the legal meaning of settlement rather than the payments meaning, so details specific to payment settlement should be confirmed against authoritative payments sources.

Formal definition

The evidence packet supplied for this term addresses settlement in the legal or litigation sense, defined by the Legal Information Institute as an agreement that ends a dispute and results in voluntary dismissal of related litigation, and by other sources as the process of resolving a legal dispute before final judgment. These definitions do not describe settlement as the term is used in payment processing, where settlement generally refers to the post-authorization clearing and funding process by which transaction value is transferred among cardholders, merchants, acquirers, issuers, and networks. Because the provided evidence does not contain payments-domain material, a precise practitioner-level definition of payment settlement, including its relationship to authorization, clearing, and network settlement windows, cannot be sourced from this packet and should be drawn from card brand and network operating rules and other authoritative payments references, which vary by network and region.

Why it matters

In payment processing, settlement is the stage at which value actually moves, distinguishing an approved transaction from a funded one. Authorization confirms that an issuer has approved a transaction and reserved or verified available funds, but authorization alone does not put money in the merchant's account. Settlement completes that exchange of value, and the delay between authorization and settlement is where reconciliation, funding disputes, and certain fraud and chargeback processes operate. Practitioners who conflate authorization with settlement risk misjudging when funds are final and when liability may still shift.

It is important to note that the evidence packet supplied for this term describes settlement in the legal or litigation sense — an agreement resolving a dispute and dismissing related litigation — rather than the payments sense. Because of this, the mechanics of payment settlement, including its relationship to clearing, network settlement windows, and funding timelines, cannot be sourced from the provided evidence and should be confirmed against card brand and network operating rules and other authoritative payments references. Those rules vary by network and by region, and exact timings, cut-off windows, and funding arrangements differ accordingly.

Using precise, sourced terminology matters here because settlement intersects with fraud and chargeback handling, but the governing details are set by card network and brand rules rather than by any single technical standard. Teams should not assume that settlement finality eliminates the possibility of later chargebacks or disputes; those remain governed by network rules that change over time and differ by region.

Who it's relevant to

Merchants and merchant risk teams

Merchants rely on settlement to receive funds for approved transactions, so understanding the gap between authorization and funding is essential for cash-flow planning and reconciliation. Merchant risk teams should confirm settlement timing and funding rules against their acquirer agreements and applicable network rules, which vary by region.

Acquirers and payment processors

Acquirers and processors operate the clearing and settlement flows that move value among the parties. They are responsible for aligning settlement processing with card brand and network operating rules, which govern the specific windows and procedures and differ by network and region.

Fraud analysts and chargeback teams

Settlement finality does not eliminate the possibility of later disputes; chargeback and dispute processes are governed by card brand and network rules that change over time and vary by region. Analysts should be precise about whether a transaction is authorized, settled, or subject to dispute, as the applicable rules and liability differ at each stage.

Compliance officers

Because the evidence for this term does not cover the payments meaning of settlement, compliance staff drafting policies or controls that reference settlement should source payments-specific definitions and timing from authoritative card brand and network references rather than from general or legal-domain sources.

Inside Settlement

Authorization vs. settlement

Settlement is the phase in which funds are actually moved between the acquirer, card networks, and issuers, following an earlier authorization that reserves or approves the transaction amount. Authorization confirms the account can support the transaction; settlement completes the transfer of value. The two are distinct steps in the transaction lifecycle.

Clearing and funds transfer

Settlement typically follows a clearing process in which transaction records are exchanged among participants so that net amounts owed between acquirers and issuers can be calculated and the corresponding funds moved. Timing, batching, and net settlement mechanics vary by processor, network, and region.

Batch submission

Merchants and processors commonly submit captured transactions in batches for settlement. The captured amount may differ from the originally authorized amount depending on the transaction type and any adjustments permitted by network rules.

Data handled during settlement

Settlement processing involves cardholder data such as the PAN, and systems and files that store, process, or transmit this data fall within PCI DSS scope. Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs must not be retained after authorization, including in settlement files, even if encrypted.

Scope-reduction techniques in settlement flows

Truncation, masking, tokenization, encryption, and hashing may be applied to cardholder data within settlement records to reduce exposure. These transform data differently, and their effect on PCI DSS scope depends on implementation and validation rather than on the label alone.

Network and brand rules governance

Settlement timing, interchange, and related financial rules are governed by card brand and network rules and by acquirer agreements. These rules vary by region and change over time.

Common questions

Answers to the questions practitioners most commonly ask about Settlement.

Does settlement mean the transaction was authorized, so authorization and settlement are the same step?

No. Authorization and settlement are distinct steps. Authorization is the real-time step where the issuer approves or declines a transaction and typically places a hold on the cardholder's available funds; it does not move money. Settlement is the later process by which the approved transactions are cleared and funds are actually transferred between the acquirer and issuer, generally in batches. A transaction can be authorized but never settled (for example, if the authorization is voided or expires), so treating the two as the same step can misstate what has actually occurred financially.

Once a transaction settles, does that mean the funds are final and cannot be reversed?

No. Settlement transfers funds through the clearing process, but it does not make the transaction immune to later reversal. Chargebacks, disputes, refunds, and adjustments can occur after settlement, and the timing and rules for these are governed by card brand and network rules, which vary by region and change over time. Settlement should be understood as a clearing and funds-movement step, not as an irrevocable final state.

Do settlement records need to include full sensitive authentication data to process the transaction?

No. Settlement operates on approved transactions and does not require retention of sensitive authentication data. Sensitive authentication data, such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, must not be stored after authorization, even when encrypted. Settlement processing may involve cardholder data such as the PAN, but where the PAN is retained it must be protected under the applicable PCI DSS controls, and techniques such as truncation, masking, or tokenization may be used depending on implementation and validation.

How does storing PAN in settlement or batch files affect PCI DSS scope?

Systems that store, process, or transmit cardholder data, including batch and settlement files that contain the PAN, are generally in scope for PCI DSS. The scope impact depends on how the data is handled: applying tokenization, truncation, or masking can reduce what is exposed, but their effect on scope depends on the specific implementation and validation, not on the label alone. Readers should confirm the applicable controls against the current published PCI DSS rather than assuming fixed requirement numbers, as numbering and wording differ between versions.

What controls apply to settlement files during transmission and storage?

Settlement files that contain cardholder data should be protected in line with the applicable PCI DSS requirements for protecting stored data and securing transmission over networks. This can include protecting the PAN when stored, using strong cryptography for transmission across open or public networks, and restricting access on a need-to-know basis. Because requirement numbering and wording differ between PCI DSS versions, confirm the specific control language against the current published standard.

How should discrepancies between authorized and settled amounts be handled operationally?

Differences between authorized and settled amounts can arise from partial captures, tips, incremental authorizations, or voided transactions, and are typically addressed through reconciliation between authorization records, capture or batch records, and the settlement report. Any adjustments, refunds, or disputes that follow are subject to card brand and network rules, which vary by region and change over time. This is an operational reconciliation concern rather than a change to the security requirements governing the underlying cardholder data.

Common misconceptions

Authorization and settlement are the same event, so an approved authorization means the merchant has been paid.

Authorization approves and may reserve an amount, but the actual movement of funds occurs during settlement, which is a separate step that typically follows capture and clearing. An approved authorization does not by itself guarantee completed funding, and the settled amount can differ from the authorized amount under applicable network rules.

Because sensitive authentication data was needed for authorization, it can remain in settlement files as long as it is encrypted.

Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks must not be stored after authorization, even when encrypted. This restriction applies to settlement files and any downstream systems that handle transaction records.

Tokenizing or encrypting PANs in settlement records automatically removes those systems from PCI DSS scope.

Tokenization, encryption, truncation, masking, and hashing transform data in different ways, and their impact on scope depends on how they are implemented and validated, not on the label applied. Whether a settlement system is descoped must be assessed against the current published standard.

Best practices

Confirm that no sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs or PIN blocks) is retained in settlement or batch files after authorization, and verify this through data-discovery and file inspection.

Map settlement data flows and inventory every system that stores, processes, or transmits PAN or other cardholder data to establish accurate PCI DSS scope, validating the current published requirement wording rather than assuming a fixed requirement number.

Where feasible, apply truncation, masking, or tokenization to cardholder data in settlement records to reduce exposure, and validate the chosen technique's actual effect on scope rather than relying on its label.

Reconcile captured and settled amounts against authorizations to detect discrepancies, and document handling of adjustments consistent with applicable card brand and network rules.

Track changes to card brand, network, and acquirer settlement rules by region, since timing, interchange, and related terms vary and change over time.

Apply access controls, logging, and monitoring to settlement systems and batch files, and periodically confirm that retention practices align with the current PCI DSS requirements.