Mastercard 4871 Chargeback: Chip Liability Shift Lost/Stolen/NRI Fraud

Build the chip-processing record first

Retrieve the terminal, entry mode, chip/EMV data, authorization response, and transaction ID for the disputed sale. Confirm every exhibit maps to the same payment attempt and amount.

If the system shows fallback or keyed entry, preserve that path rather than describing the sale generically as chip-enabled. The actual transaction path matters more than the store's terminal capability in the abstract.

Present verification data without identity claims

If PIN, signature, no-CVM, or another verification result is retained, show the actual result and processor definition. It can describe how the terminal handled verification, but it does not independently establish that the named cardholder was physically present.

Avoid language such as 'PIN proves the customer made the purchase.' Keep the claim at the level the transaction record supports.

Check liability indicators and exceptions

Capture any liability-shift or related indicator the processor exposes and verify its meaning against provider/network documentation. Do not infer protection from a generic fraud-screen label.

If the processor case indicates an exception or different treatment, follow the live case. The merchant should not force a favorable interpretation from a simplified dashboard field.

Use commercial evidence to identify the sale

An itemized receipt, signed service record, or pickup event can help show what was purchased and connect the merchant's record to the transaction. Place it after the technical payment evidence.

If customer communication mentions the purchase, use it as context only. Do not treat a familiar account or prior transaction as proof against a lost/stolen/NRI fraud allegation.

Look for terminal or process weaknesses

Review repeated fallback, manual entry, terminal failures, and staff exceptions around similar transactions. A technically weak path can create recurring exposure even when the goods were legitimately provided.

Document any configuration change made after the case and verify it with test transactions rather than assuming the operational fix worked.

Keep rule conclusions current

Mastercard's chargeback guide specifically names 4871 in the fraud-related family, but procedural details can change. Confirm current rules and processor actions before filing.

Retain the raw technical record and outcome so future cases can be compared by terminal and transaction path, not merely by reason-code label.

Example: 4871 with PIN result and alternate recipient

A chip transaction records a verification result, but the commercial receipt shows goods were picked up by an authorized employee of the purchaser's company. The merchant can document the payment process and pickup authorization separately; neither fact alone proves the named cardholder personally used the card.

A careful packet avoids that identity leap and lets the processor/network apply current liability rules to the technical transaction data.

Describe verification results exactly as recorded

When a 4871 case includes chip or cardholder-verification data, copy the terminal/processor result faithfully and avoid translating it into a personal-identity claim. A PIN or other verification outcome is a transaction-system fact; it does not authorize the merchant to state that a named cardholder necessarily performed the transaction.

Combine the technical record with the commercial transaction and fulfillment record, then verify current liability treatment through the processor/acquirer. This keeps the merchant factual while allowing the network rules—not an overstatement in the rebuttal—to determine the consequence of the chip data.

Separate card verification, transaction approval, and customer identity

Mastercard 4871 involves a fraud context where the chip-processing record matters, but merchants should keep verification results precise. Preserve the entry mode, chip data available through the processor, cardholder-verification result, authorization, terminal capability, and any liability indicator. A PIN or other verification outcome is a payment-system event; it should not be rewritten as a claim that the person present was definitely the legitimate account holder.

Build the commercial sale record separately. Receipt, item, location, employee or service record, and any delivery or pickup event can identify what the merchant provided. If an alternate recipient collected goods, preserve the pickup authorization or customer request. That can explain the transaction story but does not necessarily resolve a lost/stolen-card allegation. Keep the payment evidence and commercial evidence in parallel so one does not overstate the other.

Check for exceptions and contradictory fields in the live case. If the processor shows a liability result, use that exact status. If the transaction was contactless, fallback, or manually entered after a chip failure, explain the sequence. Do not assume that every chip-related transaction has the same treatment. Current Mastercard rules and acquirer guidance should control the rule conclusion; the merchant record should establish the facts.

Use 4871 outcomes to review card-present risk beyond one dispute. Look at high-value merchandise, pickup practices, manual overrides, unusual terminal paths, employee concentrations, and verification failures. If certain stores or products repeatedly produce lost/stolen-card disputes, adjust authentication, pickup, or fraud-review controls instead of treating the pattern as an evidence-writing problem.

Review high-value pickup and alternate-recipient policies after 4871 losses

If lost/stolen-card fraud is concentrated in transactions where merchandise is collected by someone other than the purchaser, audit the pickup policy. Record authorization to collect, verification method, staff handoff, and item value. Do not collect excessive sensitive identity data merely for dispute purposes, but make the operational decision traceable.

Compare fraud outcomes for ordinary purchaser pickup versus alternate-recipient pickup. If one path is materially riskier, apply proportionate verification or review. The dispute category can reveal a fulfillment control issue even though the technical card-present transaction appears normal.

Review cardholder-verification exceptions on high-risk lost/stolen scenarios

Where the merchant's terminal or business model permits transactions without stronger cardholder verification, identify which high-risk products and amounts are most exposed to lost/stolen-card misuse. The internal review should compare verification path with fraud outcomes and customer friction. This does not create a new Mastercard rule; it helps the merchant decide whether its own risk controls should be stricter for certain transaction populations while keeping the external case grounded in the recorded payment facts.

Lost, stolen, and related chip-liability cases also call for a careful review of cardholder verification. Preserve the verification method recorded for the transaction, any fallback or exception, terminal settings, and the circumstances of high-value or unusual card-present sales. Do not assume a signature, PIN prompt, ID check, or employee recollection proves the authorized cardholder was present; describe only what the merchant's process recorded. If policy allowed a verification exception, document why and who approved it. This gives the case a defensible factual basis while helping the merchant identify stores or transaction types where verification exceptions are concentrated. The prevention lesson should be drawn from those operational patterns, not from an unsupported conclusion about who physically used the card.