%201.svg)
Mastercard First-Party Trust: Merchant Readiness Guide
Chargebacks?
Não é mais problema seu.
Recupere 4 vezes mais chargebacks e PREVENÇÃO — até 90% dos e-mails recebidos —, com tecnologia de IA e uma rede global Rede de 20.000 Lojistas.
Mais de 600 avaliações
Resumo:
- Mastercard First-Party Trust gives merchants chargeback protection when they send one device, one delivery and one extra identity data point that meet the rules.
- Disputes under reason code 4837 go through a First-Party Trust engine that also asks for data on the cardholder's past sales.
- Data can travel with the authorization or later in the dispute; the dispute route runs through Mastercard's Consumer Clarity for Merchants API.
- The program took effect in the US in October 2024; expansion to Canada, Latin America and the Caribbean, and Asia Pacific has no set dates.
- Mastercard publishes no fee, so confirm enrollment, cost and reporting with your acquirer before launch.
Mastercard First-Party Trust is a Mastercard program that lets merchants share device, delivery and identity data with card issuers to expose first-party fraud. Merchants whose data meets the program rules get chargeback protection on qualifying disputes.
This guide is about readiness. It covers the data to collect, the two ways to send it and the tests to run before you count on protection.
{{cta}}
What Mastercard First-Party Trust is designed to solve
First-party fraud happens when a cardholder makes a real purchase, gets the goods and then calls it fraud. Some people forget the purchase. Others want the goods for free. Most merchants call this friendly fraud.
Issuers often cannot tell this apart from stolen-card fraud, so the merchant takes the loss. Mastercard announced First-Party Trust on 23 October 2023, built with the Merchant Advisory Group and the Merchant Risk Council. The program sets rules that define compelling evidence for a genuine purchase.
Sources: Mastercard First-Party Trust FAQ (75%, October 2024, categories) and Mastercard's chargeback cost research with Datos Insights (updated 8 June 2026: $36.9B in 2026 and $46.1B by 2029, with 286 million chargebacks expected in 2026). Mastercard's June 2025 release says nearly half of chargebacks are reported as fraud.
A score from a fraud tool is not the same thing. A score guesses risk. A First-Party Trust case has set data rules and set outcomes.
First-Party Trust is also not Ethoca Alerts. An alert warns you about a dispute so you can refund it before it becomes a chargeback. First-Party Trust uses your data to decide who carries the loss. See CDRN vs Ethoca alerts for how alerts work.
Know which product is live before you credit a result to either one. For the full sequence from recognition to a formal reply, see chargeback deflection.
How a First-Party Trust case works at dispute time
Mastercard developer documentation describes the dispute flow. It starts when a cardholder files a claim under reason code 4837, No Cardholder Authorization.
| The First-Party Trust dispute flow From a 4837 claim to a liability decision | |
|---|---|
| 1 | The cardholder disputes a charge with their issuer under reason code 4837 (no cardholder authorization). |
| 2 | The claim goes through the First-Party Trust engine, which finds the cardholder's past transactions. |
| 3 | You get a request for compelling evidence on the disputed sale and on the past sales that support it. |
| 4 | The engine reads your data and decides if liability shifts to the issuer or stays with you. |
| 5 | The issuer receives the result and can review it with the cardholder. |
Source: Mastercard Developers, Consumer Clarity for Merchants documentation.
Step 3 is the one most guides skip. The request covers older sales, not only the disputed one. Your systems must find data for past orders by the same cardholder, so keep that history long enough to answer. For what a 4837 claim means outside this program, see our Mastercard chargeback reason codes guide.
A win here is not always final. Mastercard's program blog says a cardholder can appeal a declined chargeback. Once the cardholder gives a signed affidavit, the issuer can send the chargeback again. You can then ask for more proof, so keep your case file ready.
Two routes to share First-Party Trust data
Sharing data is optional. Mastercard's 25 June 2025 announcement says merchants can share it during authorization or later, in the dispute process. You can use one route or both.
| Route | When the data travels | What to prepare |
|---|---|---|
| At authorization | With the payment itself, before a dispute exists | Gateway and processor support for the extra fields in the authorization message |
| During the dispute | After the sale, when Mastercard asks for evidence | A fast lookup that returns data for the disputed sale and past sales |
Mastercard's developer documentation places the dispute route inside its Consumer Clarity for Merchants API. That API also shares order details with issuers and cardholders. Read our Ethoca Consumer Clarity guide for the order data side. If you also sell on Visa, Order Insight vs Consumer Clarity shows how the two lookup services line up.
Your records may hold far more than the program needs. Confirm the allowed fields, the transport path, retention rules and access controls with your provider. A raw export of support history is not a correctly built submission.
Mastercard First-Party Trust data readiness
To qualify for liability protection, you must send one data point from each of three categories. Mastercard's US First-Party Trust page lists the accepted elements:
| Categoria | Accepted elements | Readiness check |
|---|---|---|
| Device factor | IP address, device ID or device fingerprint | Is the value from the checkout session, with a capture time? |
| Delivery factor | Shipping address, email or telephone number | Does it belong to this order, not today's profile? |
| Additional identity factor | Account login ID, phone number, device location, device name or billing address | Is it a different data point from the first two? |
The third element must differ from the first two. Mastercard's US page also lets it be an unused element from the device or delivery list. The global FAQ lists email under delivery but leaves telephone number out. Ask your acquirer which list your processor follows.
Three filled fields do not prove a qualifying case. You must know what each value means, where it came from and how it ties to the payment. Ask how your provider checks that elements are distinct, accurate for the time of sale and in the right format.
Preserve the value that existed at the transaction
An account profile can change after a purchase. Keep the value and the capture time from the sale, where you are allowed to. Do not replace it with the latest profile. A delivery address entered after a dispute is not the address recorded for the order.
Keep your event history easy to read. A reviewer should see what was collected at checkout, what the customer changed later and what your team added. Never build a past signal from an unrelated, newer record.
Distinguish account control from cardholder authorization
Proof that someone logged in is not proof that the real cardholder approved the payment. Shared accounts, stolen passwords and changed admins need a closer look. Use your data in context and state its limits.
Where the program is available
| Data | Marco |
|---|---|
| 23 October 2023 | Mastercard announces First-Party Trust as a global program, with the US first |
| October 2024 | Program takes effect in the United States, per the Mastercard FAQ |
| 25 June 2025 | Expansion announced to Canada, Latin America and the Caribbean, and Asia Pacific, with no dates given |
An announced expansion does not prove that your merchant account, acquirer or sale type is live today. Mastercard's program blog says issuers on its network take part automatically, and any merchant can join where the program runs. Ask for a written answer for your own account, with the start date and the data route. Keep it with your project files.
A merchant readiness worksheet
Use this worksheet before you set an integration deadline. It shows the gap between data that exists somewhere and data you can deliver for a real case.
| Readiness question | Evidence to collect | What a failed check means |
|---|---|---|
| Which accounts are enrolled? | Merchant IDs, provider confirmation and start dates | Coverage is unconfirmed, even if the integration exists elsewhere |
| Can the sale be found? | Payment reference linked to the original order or invoice | The data cannot support the intended payment |
| Can past sales be found? | Order history for the same cardholder, kept long enough | You cannot answer the request for supporting sales |
| Are the elements distinct? | Field map with source and definition | Three fields may not meet the accepted combination |
| Are values from the time of sale? | Capture times and permitted change history | Current profile values may misstate the purchase |
| Can delivery be explained? | Physical or digital fulfillment record | An identifier alone may not show the service was delivered |
| Are failures visible? | Missing data, rejection and timeout reports | A success count can hide unusable submissions |
| Is the outcome clear? | Provider result codes with written definitions | You cannot tell submitted cases from protected ones |
Give each open row an owner and a next step. "Engineering has the data" is not an answer if payments operations cannot say which data, from which event, under which definition.
Suggested roles, not a network rule.
Test qualifying and non-qualifying scenarios
Start with a small set of redacted or test transactions. Ask your provider which result means accepted, rejected, no match or not covered.
First-Party Trust test cases
- A complete record with one element from each category
- A record with one category missing
- A customer profile that changed after the sale
- The same value sent twice as two different elements
- A payment that cannot be matched to an order
- A cardholder with no past sales on file
Test a real service complaint on its own. Proof of identity does not show that you delivered what you promised or handled a cancellation. Your support and dispute teams still need a path for valid complaints. Strong chargeback evidence for those cases comes from fulfillment and support records.
Also test a case with a stolen account login. Do not tell the issuer that all account activity proves the cardholder took part when your security logs say otherwise. The case must match the known facts.
Questions to ask your acquirer or provider
Before you sign
- Which program documents apply, and who handles enrollment?
- Does data travel at authorization, during the dispute or both?
- Which data combinations are accepted, and what does a rejected submission look like?
- What does protection mean for our flow, and what happens if the issuer keeps the case going?
- What triggers a fee, and are failed or duplicate submissions billed?
- Which report fields show enrolled, submitted, accepted and protected cases?
Mastercard does not publish a First-Party Trust fee. Do not guess the price from what an alert service costs.
Get the commercial terms apart from the technical spec. A single total labeled "protected" needs a precise definition.
First-Party Trust versus Visa CE3.0
Visa Compelling Evidence 3.0 and First-Party Trust are separate network rules with separate tests. One shared data store can serve both. Keep the eligibility checks apart. Do not use a Visa checklist to decide a Mastercard case, and do not assume a Mastercard result carries over to Visa.
For a rule-by-rule view, see Visa CE3.0 vs Mastercard First-Party Trust. Our Verifi Order Insight guide covers Visa's purchase data service.
Measure outcomes without claiming universal protection
Report four numbers: sales in scope, complete data records, accepted submissions and confirmed protected outcomes. Keep missing-data and unsupported cases in view. If your provider has no reliable protected-outcome field, say so in the report.
Compare the same merchant accounts over the same periods before you read a change in disputes. Sales mix, fraud screening, support and refund policy can all shift at once. A drop is useful, but proving the cause needs a sound test design. Track each case against the chargeback time limit so a slow lookup does not cost you the reply.
Mastercard First-Party Trust FAQs
What is Mastercard First-Party Trust?
Mastercard First-Party Trust is a program that lets merchants share device, delivery and identity data with issuers. The data helps separate first-party fraud from stolen-card fraud. Merchants that meet the data rules get chargeback protection on qualifying disputes.
When did Mastercard First-Party Trust launch?
Mastercard announced First-Party Trust on 23 October 2023. It took effect in the United States in October 2024. In June 2025, Mastercard announced expansion to Canada, Latin America and the Caribbean, and Asia Pacific, without set dates.
What data does Mastercard First-Party Trust require?
Mastercard First-Party Trust requires one data point from each of three categories: device (such as IP address or device ID), delivery (such as shipping address or email) and an additional identity factor (such as account login ID or billing address). The third point must differ from the first two.
Which disputes does First-Party Trust cover?
Mastercard's developer documentation says First-Party Trust handles disputes filed under reason code 4837, No Cardholder Authorization. The engine finds the cardholder's past transactions and asks the merchant for evidence on the disputed sale and those past sales.
How does a merchant join Mastercard First-Party Trust?
Any merchant can join Mastercard First-Party Trust where the program is live, and issuers on the Mastercard network take part automatically. Ask your acquirer, processor or dispute provider how enrollment works and to confirm your account and data route in writing.
Can a cardholder still win after First-Party Trust data is shared?
Yes. Under First-Party Trust, a cardholder can appeal a declined chargeback. Once the cardholder gives a signed affidavit, the issuer can send the chargeback again, and the merchant can ask for more proof.
Turn First-Party Trust readiness into fewer lost 4837 disputes
First-Party Trust can stop some fraud claims, but not every dispute qualifies. Service complaints, missing data and claims outside reason code 4837 still end up as chargebacks. Chargeflow Alerts, powered by Visa and Mastercard, can flag disputes early. Chargeflow Automation builds and submits evidence for the chargebacks that still arrive.
Confirm any First-Party Trust coverage for your account directly with your provider.
Recover Chargebacks Without the Paperwork
Chargeflow Automation builds and submits evidence for the chargebacks that still arrive.
Chargebacks?
Não é mais problema seu.
Recupere 4 vezes mais chargebacks e PREVENÇÃO — até 90% dos e-mails recebidos —, com tecnologia de IA e uma rede global Rede de 20.000 Lojistas.
.png)
