• Did you know that consumers return about 20% of the products they purchase online? Online return rates have significantly increased over the years, and they’re especially high compared to in-store purchases. In fact, online return rates are often two to three times higher than digital (in-store) return rates.

    According to research from Capital One, in 2024 alone, consumers in the U.S. returned around $362 billion worth of merchandise from online sales.

    But how exactly are these refunds processed behind the scenes?

    Before 2021: Refunds Were Simple—but Risky

    Prior to 2021, processing refunds was fairly straightforward. Merchants could simply push refund transactions back to customers’ bank accounts without any prior authorization from the card issuer.

    However, this approach had significant drawbacks:

    • Lack of visibility for customers. Many consumers had no way of knowing whether the merchant had actually initiated the refund.
    • Fraud risk. Fraudsters could exploit the system to push credits to unrelated cards, launder money, or create other financial abuse.
    • Delayed processing. Refunds often took 2–3 business days, leading to confusion and increased calls to merchants’ customer service centers.

    Let’s examine how refunds impact payments, risk, and customer experience, comparing before and after the introduction of refund authorization mandates.

    Refunds: Comparing Before vs. After Refund Authorization

    AspectWithout Refund AuthorizationWith Refund Authorization
    PaymentsMerchants could easily process refunds without issuer approval. However, if the card account was closed, the issuer had to figure out how to handle the refund. This only worked if the customer still maintained a relationship with the bank. If the customer severed the relationship entirely, the issuer might either return the refund to the acquirer or leave the payment in limbo.Merchants must first run a refund authorization. If the authorization is successful, they proceed to send the refund to the customer’s account. If the authorization is declined, merchants can reach out to the customer for an alternative card, issue a check, or offer store credit.
    Payments RiskSeveral fraud scenarios existed:
    1. Fraudulent Credits to Random Cards: An employee colluding with fraudsters could key in a refund to a card that never made a purchase.
    2. Money Laundering: Fraudsters could use refunds to “clean” illicit funds by buying expensive goods and refunding them—sometimes even to different cards.
    3. Refund Flipping: A fraudster makes a legitimate purchase, disputes it, and demands a refund. They collect both the chargeback and keep the goods, resulting in a “double dip” fraud loss for the merchant.
    The issuer can verify whether the card was used for the original purchase, check for suspicious activity, and decline transactions to random cards or known refund abusers. This protects both genuine customers and merchants from fraud.
    CustomersWithout refund authorization, customers often had no visibility into the status of a refund after the merchant agreed to process it. If a card was closed due to loss or fraud, customers had to rely on the issuer’s best efforts to receive their money. Even if the merchant offered to issue a check, there was no guarantee, leaving customers confused or even financially stranded if they had severed their relationship with the bank.With refund authorization, as soon as the merchant runs the refund authorization, the customer can see a pending credit on their card. If the transaction is declined, merchant customer service teams can assist the customer by offering alternative options like a check or refund to another card.

    Important Note

    Refunds and reversals are not the same thing.

    • Refunds apply when the original transaction has already been settled (i.e. the funds have moved from the customer to the merchant).
    • Reversals or voids happen when the customer cancels the transaction before settlement—the funds never leave the customer’s account.

    In this article, we’re focusing specifically on refunds.

    Refund Authorization Declines

    Just like regular purchase authorizations, refund authorizations can also be declined. Industry estimates suggest that 6% to 10% of refund authorizations get declined, depending on the quality of the cards involved in the original transactions.

    Common decline reasons include:

    • Account Closed
    • Invalid Transaction
    • Transaction Refused
    • Invalid Account Number
    • Transaction Not Permitted to Cardholder

    Don’t be surprised if you see vague responses like “Insufficient Response” on a refund transaction. Sometimes issuers suppress the true reason for a decline for security or privacy reasons, or technical issues may occur on the issuer’s side.

    What Should Merchants Do If a Refund Authorization Is Declined?

    Both Visa and Mastercard recommend that merchants handle refunds manually in such cases—for example:

    • Issuing a check to the customer.
    • Providing store credit for a future purchase.

    What Happens if a Merchant Sends Refunds Without Authorization?

    If merchants skip the required refund authorization, they’re subject to fees from the card networks:

    • Visa: Charges $0.10 for every refund transaction submitted without authorization.
    • Mastercard: Charges a Processing Integrity Fee ranging from $0.04 to $0.25, depending on the region and program.

    Many merchants choose to perform refund authorizations to avoid these fees. However, some continue paying the penalties because they don’t want to invest in manual refund processes like issuing checks.

    Key KPIs for Refund Authorization

    Refund transactions often don’t get the attention they deserve. However, as discussed, they can signal underlying fraud trends. Regular monitoring helps mitigate fraud risk and keep merchant accounts (MIDs) healthy for normal payment processing.

    Important KPIs include:

    Stay tuned for my next post: How to Implement Refund Authorizations.

  • When investigating a spike in card declines, the first instinct for many payments analysts and product managers is to check the decline response codes. Terms like “Insufficient Funds”, “Do Not Honor”, and “Transaction Refused” are now part of the shared language across the payments industry. Even senior leaders often ask, “Which response code is spiking?”

    Is that a wrong approach? Not entirely—but relying on response codes too heavily can be misleading.

    To understand why, let’s trace how a decline message travels back through the system:

    When a card issuer declines a transaction, the response is passed back through multiple hops:
    Issuer → Card Network (Visa/Mastercard) → Processor → Payment Service Provider (PSP) → Merchant.

    All of this happens in milliseconds, but to optimize speed and reduce complexity, each player in the chain may normalize or simplify the decline response. The level of detail a merchant receives ultimately depends on each player’s philosophy and technical capability.

    Years ago, I spoke with a major U.S. authorizer. I asked why 70% of their declines were labeled as “51 – Insufficient Funds.” Their answer surprised me:

    “Most merchants just want to know if a transaction was approved or declined—they don’t care why. So we simplify.”

    They advised us to start consuming network response codes, which are passed directly from the card networks and tend to be more granular. But that required PSPs to modify their systems to expose those codes.

    Today, most leading PSPs in the U.S. (and likely worldwide) support network response codes. If you’re a merchant not receiving them, ask your PSP.

    Let’s now look at some scenarios where response codes can mislead your analysis:

    1. Processor Switch: If your PSP switches processors (e.g., from one with generic codes to one with granular codes), it might look like certain decline types are suddenly spiking—when in fact, nothing changed except visibility.
    2. Carding or Bot Attacks: Issuers often mask real decline reasons during fraud attempts to avoid helping attackers fine-tune their bots.
    3. Aggressive Retry Strategies: If your dunning partner triggers multiple retries per day, the same decline reason may flood your logs—without providing any new insight.
    4. New PSP or Processor Integration: Any onboarding of a new provider may change the way responses are logged and categorized.
    5. Market Expansion: Launching in a new country may introduce new issuer behaviors that you haven’t previously encountered.

    These are just a few examples. Feel free to comment if you’ve seen other situations that impacted decline response patterns.

    So, if decline response codes aren’t always reliable, what should you look at to begin a proper decline analysis?

    I’ll share my experience in the next blog post. Stay tuned!

  • When I joined PayPal in 2014, I was new to the payments industry—but not new to analytics. I had been working in data analytics for over a decade, so when I was asked to analyze approval rate trends and transaction declines in Brazil, I expected it to be a fairly straightforward task.

    After all, most analytics work boils down to three things:

    • Business understanding
    • Data understanding
    • Basic programming skills

    How hard could it be? All I needed to do was answer two questions:

    1. Who declines a card-funded transaction?
    2. Why do they decline it?

    But answering even the first question—who—turned out to be more complicated than I imagined.

    I spoke with veteran analytics colleagues, product managers, and business leads. They walked me through the transaction flow: the transaction goes from the merchant to the authorizer, to the card network, and finally to the issuer. Initially, I assumed that each player in this chain might influence the approval or decline decision. But after much digging, I learned that in reality, it is the card issuer who makes the final approval or decline decision—not the other players.

    Today, this is fairly well understood—thanks to the wealth of LinkedIn articles and PSP educational content. But in 2014, such information was much harder to find.

    In the specific case of Brazil, I eventually uncovered that the fluctuations in approval rates were not being driven by players in the payments ecosystem at all. Instead, they were caused by merchant-side factors—such as merchant churn, acquisition strategies, and changes in the merchant landscape.

    Later that year, I attended Glenbrook Partners’ Payments 101 training, a three-day deep dive into the payments ecosystem. That experience dramatically improved my understanding of how the ecosystem really works and made me a far more effective payments analyst.

    The biggest lesson? To be a great payments analyst, it takes more than data and programming skills—you need a deep understanding of the payments industry itself: the ecosystem, the players, and the dynamics that influence data trends.

    What has your payments analytics journey been like? I would love to hear your experience!