Mastercard First-Party Trust: How Three Data Points Defeat 4837 Friendly-Fraud Disputes

A cardholder buys from you, receives the order, and three weeks later tells their bank they never authorized the charge. The issuer files a Mastercard chargeback under reason code 4837, No Cardholder Authorization, and unless something intervenes the money moves. Mastercard's answer to this is the First-Party Trust program: a rule set and a data channel that lets a merchant put device, delivery and identity evidence in front of the issuer, either at the moment of the sale or the moment the dispute is raised, so that a genuine purchase is recognised as one before it becomes a chargeback. It went live for US domestic transactions in October 2024, and in June 2025 Mastercard extended it to Canada, Latin America, the Caribbean and Asia Pacific. This guide covers what Mastercard has actually published, the two ways in, where the public sources disagree, how it compares with Visa's Compelling Evidence 3.0, and what to capture now.

What First-Party Trust is, and what it is not

First-party fraud, which most merchants call friendly fraud, is a dispute filed by the person who actually made the purchase. Mastercard's own description is that it occurs when a cardholder makes a legitimate purchase, receives the goods or services, and then claims it was fraud, whether out of confusion because they do not recognise the charge or deliberately, to get something for free. Mastercard puts it at 75% of the fraud experienced by online businesses, and its 2025 State of Chargebacks report forecasts the global cost of chargebacks to merchants rising to $42 billion by 2028, with nearly half reported as fraudulent.

The premise is that issuers file these disputes because they cannot tell a first-party claim from a stolen-card one: the cardholder says it was not them, and the bank has nothing to test that against. Mastercard describes two components: enhanced signals for issuers covering the cardholder's purchase history, device details, delivery information, identity elements and geographic location, and new rules defining compelling evidence to identify genuine purchases, including merchant chargeback protection for disputes that adhere to the program's data-sharing requirements.

Three boundaries matter before anything else. First, it is an opt-in program: nothing happens unless you, or your processor on your behalf, are enrolled and sending the data. Second, it addresses the fraud reason code, 4837. A cardholder who says the goods never arrived or were not as described has filed a different dispute, and First-Party Trust does nothing for it. Third, it is a Mastercard program. The Visa counterpart is Compelling Evidence 3.0, which this site covers separately, and the two are not interchangeable: they ask for different evidence through different channels.

The three data factors, as Mastercard lists them

Mastercard's product page is specific about what qualifies a transaction for liability protection. You must send one data element from each of the first two categories, and a third element that is either from the additional identity list or an unused element from the first two:

• Device factor: IP address, device ID, or device fingerprint.
• Delivery factor: shipping address, email address, or telephone number.
• Additional identity factor: account ID or login, phone number, device location, device name, or billing address.

A checkout that captures the customer's IP address, the shipping address and the account they logged in with has met the test. So has one that captures a device fingerprint, an email address and a telephone number, since the third element can come from a category already used. Two elements from one category and nothing from the other does not qualify: a device fingerprint plus an IP address, with no delivery element, fails.

Most card-not-present merchants already collect all of this. The work is in passing it to Mastercard through a channel the program recognises. An IP address your gateway strips before authorization, or a shipping address stored only in your order system and never transmitted, is evidence you have and cannot use.

Two ways in: at authorization or at the dispute

Mastercard's press material describes two methods for sharing the enhanced data, and a merchant may use one or both.

Before the dispute: sending the data with the transaction

The first route sends the qualifying elements to Mastercard at the time of the sale, through its Identity Check Insights interface, which a merchant reaches through its own 3-D Secure server or Mastercard's 3DS Smart Interface API. Mastercard stores the data on the merchant's behalf and, according to the specialist coverage, uses it in real time in its risk models as well as holding it as a timestamped record for any later dispute. Mastercard's own FAQ says that making the data available at the pre-authorization stage can lead to better approval rates, which is the part most easily overlooked: the signals that defeat a friendly-fraud claim also reassure an issuer deciding a borderline authorization.

At the dispute: answering the issuer's request

The second route waits until a cardholder raises a dispute. Mastercard then requests the evidence through the Ethoca Consumer Clarity Merchant Transactions API, the same Mastercard-owned channel issuers already use to show cardholders merchant details for a charge they do not recognise. The merchant, or its processor, returns the qualifying data for the disputed transaction and the issuer evaluates it before a chargeback is filed. This is the reactive path, and Merchant Cost Consulting's analysis calls it the less ideal of the two because it needs an extra step at dispute time, but it still qualifies for the program's protection when the data meets the requirements.

What chargeback protection means in practice

The program's main effect happens before a chargeback exists. When qualifying data is on file and a cardholder disputes the charge, the issuer is expected to review that data first. In the specialist accounts of the program, the issuer can put the merchant's evidence in front of the cardholder and give them the chance to recognise the purchase and withdraw the claim. If they do, no chargeback is filed and no fraud report is generated.

That matters for a high-risk merchant because Mastercard's monitoring programs count what is filed. A dispute withdrawn at inquiry never enters the Excessive Chargeback Program count, and a fraud claim that never becomes a 4837 chargeback never feeds the Excessive Fraud Merchant calculation. First-Party Trust is not on its own a way out of monitoring, but it removes the disputes that should never have been filed before they reach the ratio.

Where the cardholder persists, Mastercard's press release describes merchant chargeback protection for disputes that adhere to the data-sharing requirements, and Chargebacks911's pre-launch analysis of the rule change put it more bluntly: a 4837 chargeback is disallowed if the merchant meets the transaction data requirements. The governing text sits in Mastercard's Chargeback Guide rather than on its marketing pages, so treat the exact mechanics, and the exceptions, as something to confirm with your acquirer rather than something a blog post can guarantee.

Does it need purchase history? The public sources disagree

This is the point on which the published accounts conflict, and it is better stated than papered over. Chargebacks911's May 2024 write-up, published before the US launch, said a merchant would need at least two earlier transactions on the same card that were not reported as fraudulent, made between 121 and 365 days before the disputed one, and Justt's September 2025 analysis likewise describes Mastercard matching the disputed transaction against two historical ones. Merchant Cost Consulting's March 2026 explainer says the opposite: that First-Party Trust does not require prior history with the cardholder, so a first-time customer can qualify on the three data points alone. Mastercard's own product page lists only the three data factors and says nothing about prior transactions either way.

The likeliest reconciliation is that the two routes behave differently: the pre-authorization route evaluates the transaction on its own real-time signals, while the dispute-stage route, which runs through the same Consumer Clarity channel Mastercard uses to surface purchase history, draws on earlier matching transactions when they exist. That reading fits all four sources, but it is an inference, not a rule citation. If your disputes come mostly from first-time buyers, ask your acquirer whether a single qualifying transaction is enough under the current rules before you build a business case on it.

First-Party Trust and Visa CE3.0 side by side

Merchants who have already built for Visa's Compelling Evidence 3.0 will find the shape familiar and the details different. Both programs exist to defeat first-party fraud claims, both work from data the merchant captured at checkout, and both can operate before a dispute is filed or in response to one. The differences are in what qualifies and where it goes:

• Dispute scope: CE3.0 applies to Visa condition 10.4, Other Fraud, Card-Absent Environment. First-Party Trust addresses Mastercard reason code 4837, No Cardholder Authorization.
• The evidence test: CE3.0 requires two prior undisputed transactions on the same credential, 120 to 365 days old, matching the disputed one on two data elements of which one must be the device ID, fingerprint or IP address. First-Party Trust requires three data elements across its device, delivery and identity categories; whether prior history is also required is the open question above.
• The channel: CE3.0 evidence travels through Verifi's Order Insight and Visa Resolve Online. First-Party Trust data travels through Identity Check Insights at authorization or Ethoca Consumer Clarity at the dispute.
• Enrollment: CE3.0 is a rule any acquirer can invoke in a dispute response. First-Party Trust is opt-in: the merchant, or its processor, registers and makes the data available to Mastercard in advance.
• Cost: Visa attached a fee to successful CE3.0 qualifications in April 2026. Neither Mastercard's public pages nor the specialist coverage we reviewed publishes a fee schedule for First-Party Trust itself, so ask your processor what, if anything, it charges for the data services that carry it.

The data elements overlap almost entirely, so a checkout that reliably captures IP address or device fingerprint, a login identifier, a shipping address, an email and a phone number has what both programs want. But the transport is separate, and a processor that presents CE3.0 evidence well is not automatically enrolled in First-Party Trust, or the reverse.

Why this matters more for high-risk merchants

For a mainstream retailer a friendly-fraud chargeback is an annoyance. For a merchant in subscription billing, nutraceuticals, digital goods, adult, travel or any other vertical mainstream processors decline, it is a threat to the account. High-risk merchants run closer to Mastercard's monitoring thresholds to begin with, and their acquirers enforce internal limits tighter than the network's own. A program that intercepts first-party claims at the issuer, before they are filed, is worth more to that merchant than to almost anyone else.

What to capture now

Whatever your processor currently supports, the data side is within your control, and it is the same data the Visa program wants:

1. Capture a clear-text IP address or a real device fingerprint on every order, and make sure your gateway passes it through rather than replacing it with its own.
2. Require an account or a recognisable login identifier for repeat purchases, and store it against the transaction, not just the customer record.
3. Collect a full shipping address, an email address and a telephone number at checkout, and keep them attached to the transaction record so they can be returned for that specific order.
4. Confirm with your processor or gateway whether it supports First-Party Trust at all, and if so through which route: authorization-time through Identity Check Insights, dispute-time through Consumer Clarity, or both. Support is not universal, and a gateway that supports 3-D Secure does not necessarily submit the program's data fields.
5. Ask what the enrollment involves and what, if anything, it costs, and get the answer in writing.
6. Watch your 4837 disputes after enrollment. The measure of the program is how many are withdrawn at inquiry, not how many you win at representment.

The bottom line

First-Party Trust is Mastercard's clearest statement yet that a friendly-fraud claim should be tested against evidence before it becomes a chargeback, and the test is one most card-not-present merchants can meet with data they already collect: three elements, one each from device and delivery and one more, sent with the authorization or in answer to the issuer's request. What is not settled in public is whether the dispute-stage route also needs prior purchase history, and whether it costs anything to be in. Both are questions for your processor, and both are worth asking now, because a merchant enrolled today has months of qualifying transactions on file by the time the next 4837 arrives.