Category: Chargebacks and Disputes

Retrieval Request

Also known as: Soft Chargeback, Transaction Receipt Request

Simply put

A retrieval request is a formal inquiry, usually started by a cardholder's issuing bank, asking a merchant to provide more information or documentation about a specific transaction that appears on the cardholder's account. It is often used when the cardholder or issuer wants to clarify or verify a charge before deciding whether to dispute it. Because it may precede a formal dispute, it is sometimes informally called a soft chargeback, though it is not itself a chargeback.

Formal definition

A retrieval request is a formalized inquiry initiated by a cardholder's issuing bank (or on behalf of a cardholder) directed to the acquirer and merchant to obtain additional information about a specific transaction, such as a transaction receipt in paper or electronic form. It functions as an information-gathering step regarding a charge and is sometimes referred to as a soft chargeback, but it does not by itself reverse funds or constitute a chargeback. Responding with the requested documentation may help clarify the transaction and, in some cases, reduce the likelihood of a subsequent formal dispute; however, the specific handling, timeframes, and rules governing retrieval requests are set by card brand and network rules, which vary by region and change over time, so practitioners should confirm current requirements against the applicable network's published rules.

Why it matters

A retrieval request is often an early signal in the dispute lifecycle. Because it typically arrives before a cardholder or issuer decides whether to escalate to a formal chargeback, it gives merchants a window to clarify a transaction by supplying documentation such as a transaction receipt. Responding promptly and completely may help resolve a cardholder's confusion about an unfamiliar charge and, in some cases, reduce the likelihood of a subsequent formal dispute. It is important to note, however, that a retrieval request is not itself a chargeback and does not by itself reverse funds.

The informal label "soft chargeback" reflects this pre-dispute positioning, but the terminology can be misleading if it leads teams to treat a retrieval request as a completed reversal. Practitioners should distinguish the information-gathering step from an actual funds reversal, and should recognize that failing to respond adequately may leave the merchant less prepared if the inquiry later becomes a formal dispute.

The specific handling, response timeframes, and consequences of non-response are governed by card brand and network rules, which vary by region and change over time. For this reason, exact procedures and deadlines should be confirmed against the applicable network's current published rules rather than assumed from general descriptions.

Who it's relevant to

Merchants and Merchant Risk Teams

Merchants receiving a retrieval request must locate and provide documentation, typically a transaction receipt in paper or electronic form, within the timeframes set by the applicable network. Treating these inquiries seriously and responding completely may help clarify a charge and, in some cases, reduce the likelihood of a subsequent formal dispute.

Acquirers and Payment Processors

Acquirers route retrieval requests from issuers to their merchants and relay the merchant's response back. They help ensure requests are handled within applicable network timeframes and formats, which vary by region and change over time.

Issuing Banks

Issuers initiate retrieval requests, sometimes on behalf of a cardholder, to obtain additional information about a specific transaction before determining whether to proceed to a formal dispute.

Fraud Analysts and Dispute Teams

For teams managing disputes, a retrieval request can be an early indicator that a charge is being questioned. Distinguishing this information-gathering step from an actual chargeback is important, as it does not reverse funds but may precede a formal dispute.

Inside Retrieval Request

Retrieval Request

A request initiated by an issuer, often on behalf of a cardholder, asking the acquirer or merchant to provide documentation or details supporting a specific transaction. It is typically a request for information rather than a demand for funds, and is distinct from a chargeback.

Transaction Documentation

The supporting records a merchant may be asked to supply, such as a sales receipt, order details, proof of delivery, or descriptor information, used to help the issuer or cardholder identify or verify the transaction.

Requesting Party

The issuer, which may be responding to a cardholder inquiry, a question about a billing descriptor, or an internal need to clarify a transaction before deciding whether to proceed further.

Responding Party

The acquirer and merchant, who compile and return the requested information within timeframes set by applicable card brand and network rules, which vary by region and change over time.

Relationship to Chargebacks

A retrieval request may precede or be unrelated to a chargeback. Failure to respond adequately can, under some network rules, contribute to a subsequent dispute, but the retrieval request itself does not move funds.

Governing Rules

Retrieval request procedures, allowed timeframes, and consequences are defined by individual card brand and network operating rules, which differ by network and region and are subject to change.

Common questions

Answers to the questions practitioners most commonly ask about Retrieval Request.

Is a retrieval request the same thing as a chargeback?

No. A retrieval request is a request from the issuer for a copy of a transaction record or supporting documentation, typically to satisfy a cardholder inquiry or to review a transaction. It is not itself a debit of funds. A chargeback is a separate dispute mechanism that reverses funds. A retrieval request may sometimes precede a chargeback, but responding to one does not guarantee that a chargeback will follow or be avoided, and the two are governed by distinct card brand and network rules that vary by region and change over time.

Does responding to a retrieval request mean I have won or resolved the dispute?

Not necessarily. Fulfilling a retrieval request provides the requested documentation, but it does not by itself resolve or settle any underlying dispute. The issuer may still proceed to a chargeback depending on the outcome of its review, and dispute outcomes are determined under card brand and network rules rather than by the act of responding alone. Treat a timely, complete response as helping support your position rather than as a guaranteed resolution.

What information should a merchant include when responding to a retrieval request?

Include the transaction documentation requested by the issuer, which may involve details such as the transaction record, order and shipping or delivery information, and other supporting evidence appropriate to the transaction type. When handling any records, follow applicable data-handling controls: sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks must not be stored after authorization, and cardholder data such as the PAN should be masked or truncated in accordance with your documented controls. Confirm the exact required contents against current card brand and network rules.

How quickly must a merchant respond to a retrieval request?

Response time frames are set by card brand and network rules and can vary by region, transaction type, and program, and they change over time. Missing an applicable deadline may weaken your position or affect downstream dispute handling. Confirm the current applicable time limits with your acquirer or processor rather than assuming a fixed window.

Do retrieval requests affect PCI DSS scope for the systems that store the supporting documentation?

Systems and repositories that store, process, or transmit cardholder data as part of transaction documentation can fall within PCI DSS scope, and the effect depends on how the data is stored and protected rather than on the label 'retrieval documentation.' Applying masking, truncation, or other approved data-reduction techniques may reduce exposure, but their effect on scope depends on implementation and validation. Confirm scope determinations against the current published PCI DSS.

How can a merchant reduce the operational burden of retrieval requests?

Approaches that may help include retaining organized, retrievable transaction records within your documented retention and data-handling controls, establishing clear internal workflows for responding within applicable time frames, and coordinating with your acquirer or processor on submission channels and requirements. These measures are intended to support timely, complete responses; they do not guarantee any particular dispute outcome, which remains governed by card brand and network rules.

Common misconceptions

A retrieval request is the same as a chargeback.

A retrieval request is generally a request for transaction information or documentation, not a reversal of funds. A chargeback is a separate mechanism that reverses a transaction amount, though an unanswered retrieval request can, under some network rules, contribute to a later dispute.

Merchants can ignore a retrieval request without consequence.

While no funds move at the retrieval stage, failing to respond within the timeframes set by card brand and network rules may weaken the merchant's position or contribute to a subsequent chargeback under those rules, which vary by network and region.

Any transaction data can be included in the response to satisfy the request.

Responses must supply the requested transaction documentation while respecting data protection obligations. Full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks are sensitive authentication data that must not be stored after authorization, so they cannot be furnished from stored records. Cardholder data such as the PAN should be masked or truncated where full display is not required and permitted.

Best practices

Track incoming retrieval requests and respond within the timeframes defined by the applicable card brand and network rules, confirming current requirements against the relevant network's published operating rules rather than assuming fixed deadlines.

Retain permissible transaction documentation such as receipts, order details, and proof of delivery in a manner that supports timely retrieval responses while applying defined controls to any stored cardholder data.

Never store or supply sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PINs, as this data must not be retained after authorization even when encrypted.

Apply masking or truncation to the PAN and other cardholder data in retrieval responses where full values are not required, consistent with PCI DSS requirements confirmed against the current published standard.

Coordinate closely with the acquirer to understand how unanswered or inadequate retrieval responses may contribute to subsequent chargebacks under the governing network rules, which vary by region.

Maintain an auditable workflow for logging, assigning, and documenting each retrieval request and its response to support later dispute handling and internal review.