How can we help?

A chargeback usually moves through these stages:

1. Transaction & dispute -- The cardholder sees a transaction and disputes it with their issuing bank. The issuer reviews the claim and may issue a temporary/provisional credit.
2. Chargeback filed -- If the issuer accepts the dispute, it sends a chargeback through the card network (Visa, Mastercard, etc.). The disputed amount is typically pulled from the merchant/acquirer.
3. Merchant response / representment -- The merchant can either accept the chargeback or fight it by submitting evidence, such as proof of delivery, authorization, refund policy, customer communications, or proof the cardholder participated in the transaction.
4. Issuer review -- The issuer reviews the merchant's evidence. If the merchant successfully disproves the dispute, the chargeback can be reversed and the funds returned to the merchant. If not, the chargeback stands.
5. Pre-arbitration / second dispute -- Depending on the card network and dispute type, the issuer may challenge the merchant's representment. This is essentially another round where the parties can accept the outcome or continue fighting.
6. Arbitration -- For cases that still aren't resolved, the card network can make the final decision. Arbitration can involve additional fees, so most disputes don't make it this far.

A simplified way to think about the cycle is:
Transaction → Customer dispute → Chargeback → Merchant response → Decision → Pre-arbitration → Arbitration

A chargeback affects more than just the transaction amount. The business impact can include:

• Lost revenue -- If a chargeback is upheld, you lose the transaction amount. A $500 chargeback means $500 in revenue is reversed, not just delayed.
• Lost product/service -- You may lose the physical merchandise or service already provided, on top of the revenue.
• Chargeback fees -- Processors and acquirers assess fees for each chargeback, with additional fees for later stages like pre-arbitration or arbitration.
• Higher chargeback ratio -- Card networks monitor dispute volume relative to total transactions. Elevated ratios can trigger monitoring programs, extra fees, or reserves.
• Processing risk -- Excessive chargebacks may lead to increased pricing from processors, held reserves, delayed settlements, or account termination.
• Operational costs -- Employee time spent investigating disputes, collecting documentation, and submitting representments adds up quickly.
• Cash-flow impact -- Unexpected removal of funds can create significant cash-flow pressure, especially with high dispute volume in a short period.
• Fraud and customer-experience signal -- High chargeback rates can indicate issues with fraud, billing confusion, fulfillment problems, or unclear merchant descriptors.

Why second and third disputes matter

Even if a merchant wins the first dispute, the same transaction can come back through pre-arbitration or arbitration. Each round adds fees, time, and risk exposure.

$1,000 sale → 1st dispute → merchant fights and wins → 2nd dispute/pre-arbitration → merchant responds again → arbitration

Even if the merchant eventually wins and keeps the $1,000, they have incurred significant hidden costs (fees, time, documentation, and risk exposure).

Businesses should monitor more than just dollar amounts; they should track chargeback count, rate, dispute stage, win rate, repeat disputes, reason codes, and total financial exposure.

PCI compliance -- usually referring to PCI DSS (Payment Card Industry Data Security Standard) -- requires businesses that store, process, or transmit payment card data to protect that information according to specific security standards. The exact requirements depend on how the business accepts payments and whether card data touches its systems.

At a high level, PCI DSS v4.x requires businesses to:

• Protect cardholder data -- Businesses must know where card data exists, limit its storage, protect stored data, and encrypt cardholder data when transmitted over public networks. Sensitive authentication data, such as CVV/CVC, generally cannot be stored after authorization.
• Secure systems and networks -- Systems involved in payment processing need appropriate security configurations, firewalls/network controls, secure passwords, and hardened configurations.
• Control access -- Employees should only have access to cardholder data when their job requires it. Businesses need appropriate user accounts, authentication, access controls, and physical protections.
• Use strong authentication -- Administrative and other applicable access into the cardholder-data environment generally requires multi-factor authentication.
• Protect against malware and vulnerabilities -- Systems need security patches, vulnerability management, anti-malware protections where applicable, and secure software-development practices.
• Monitor and test security -- Businesses need logging/monitoring, vulnerability scans, penetration testing in applicable environments, and processes for detecting unauthorized activity.
• Maintain security policies -- The company needs documented security policies, defined responsibilities, employee security awareness, incident-response procedures, and appropriate oversight of third-party service providers.
• Validate compliance -- This is the part merchants often notice most. Depending on the merchant's environment and validation requirements, they may complete an annual SAQ (Self-Assessment Questionnaire), undergo external vulnerability scans by an ASV, or, for certain larger/high-risk environments, undergo a formal assessment resulting in a Report on Compliance (ROC).

A simple example

• Business A: Customer enters their card into a payment page hosted entirely by a third-party payment provider. Business A never receives the card number.
• Business B: Customer enters their card information into Business B's application, Business B's servers process it, and the company stores card numbers in its database.

Both have PCI obligations, but Business B has a dramatically larger PCI scope and compliance burden because cardholder data enters its environment.

PCI compliance matters commercially as well as technically. A business that doesn't comply can face processor/acquirer requirements, remediation costs, increased scrutiny, potential fees or restrictions, and significantly greater consequences following a card-data compromise.

When people say “PCI 4.0,” they are usually referring to PCI DSS v4.0.1, published in June 2024 as a limited revision to clarify requirements. Fifty-one “future-dated” v4.x requirements became effective on March 31, 2025.

PCI DSS applies to organizations that store, process, or transmit cardholder data -- or can affect the security of the cardholder data environment.

What’s particularly important about 4.0/4.0.1

There are several changes that businesses should pay close attention to.

• MFA is much broader. PCI DSS 4.x expanded Requirement 8 so MFA applies to all access into the cardholder data environment, rather than focusing primarily on certain remote administrative access scenarios.
• E-commerce/payment-page security became much more important. Requirements 6.4.3 and 11.6.1 address payment-page scripts and detecting unauthorized changes/tampering to payment pages and HTTP headers. PCI SSC specifically identified these requirements as major e-commerce security areas when preparing businesses for the March 2025 deadline.
• Vulnerability scanning requirements matter even for some outsourced environments. For example, PCI SSC specifically notes that SAQ A merchants may now have to provide evidence of passing external vulnerability scans by an Approved Scanning Vendor at least once every three months under Requirement 11.3.2.
• Password requirements are stronger. PCI 4.x strengthened authentication requirements, including password/passphrase requirements and broader MFA expectations.
• Risk analysis is more formalized. Organizations have to conduct targeted risk analyses for certain requirements where PCI allows the organization to determine the frequency of an activity based on its own risk. This is one of the significant structural changes PCI SSC highlighted when introducing v4.0.
• Stored card numbers require stronger protection. For example, if hashing is used to make PANs unreadable, PCI DSS 4.x requires keyed cryptographic hashing for applicable hashing processes. That requirement became effective March 31, 2025.

What does a normal business actually have to do?

This is where PCI gets confusing because not every business has to implement every control in exactly the same way.

A small merchant using a completely outsourced payment page might have a relatively small PCI footprint. A payment processor, gateway, service provider, or merchant storing card numbers can have a dramatically larger one.

For many merchants, the practical annual process looks something like:

Determine PCI scope → identify applicable SAQ → implement required controls → perform required scans/testing → complete SAQ → sign Attestation of Compliance (AOC) → submit validation as required by acquirer/processor.

PCI SSC has different SAQs depending on how the merchant accepts payments, and merchants need to satisfy the eligibility requirements for the particular SAQ they’re using.

And there’s an important distinction for a processor

If you’re looking at PCI from the perspective of a payment processor/merchant services company, there’s another layer:

• A processor may require its merchants to validate PCI compliance annually.
• The processor/acquirer can also have its own PCI responsibilities as a service provider.
• PCI SSC notes that the organization receiving the compliance documentation -- typically a payment brand or acquirer -- determines the specific compliance/reporting requirements.

So “PCI compliant” doesn’t necessarily mean a merchant filled out an SAQ once and they’re done. PCI is an ongoing security obligation, while the SAQ/ROC/AOC is how compliance is validated/documented at a point in time.