Visa CE 3.0 for Recurring Billing: 10.4 Evidence Checklist (2026)

Visa Compelling Evidence 3.0 (CE 3.0) is a narrow evidence route for certain Visa disputes filed under condition 10.4, Other Fraud in a card-absent environment. A recurring payment is not automatically a 10.4 case: a cancellation claim may instead use condition 13.2 and its cancellation evidence. Start with the exact reason code, then check the transaction history, dates, matching fields, and what your acquirer can submit. CE 3.0 sets eligibility rules; it does not promise that an issuer will accept a case.

Visa 10.4 and a cancelled-recurring 13.2 complaint use different evidence paths.

Start with the dispute condition

CE 3.0 concerns Visa condition 10.4, not every subscription chargeback and not every card network. A cardholder saying a renewal continued after cancellation may be handled under Visa condition 13.2, Cancelled Recurring Transaction. That calls for evidence such as the cancellation request, the effective date, renewal notices, and whether a later payment was authorized under the terms. Do not send a purchase-history packet simply because the payment was recurring; ask the processor to confirm the network and condition shown on the case.

The reason code also determines who handles the next step. CE 3.0 information is assembled by the merchant and submitted through the processor or acquirer. For a general record packet across dispute types, see the chargeback evidence checklist. For the separate cancellation route, use the recurring-charge cancellation guide.

The date window has distinct submission and processing anchors; ask the acquirer which timestamps govern the case.

Check the two prior transactions and the current date window

For a qualifying 10.4 case, CE 3.0 requires two earlier transactions on the same card or a payment credential associated with it. The issuer must not have reported those prior transactions as fraud activity. For disputes processed through 23 October 2026, the prior history had to be with the same merchant. For disputes processed on or after 24 October 2026, Visa's April 2026 rules allow the two prior transactions to come from one or more merchants. In pre-arbitration, however, the acquirer may submit only transaction data that it accepted and processed itself. The expansion is not a network-wide search across every seller.

The age test has two date anchors. Each ordinary prior transaction must be processed more than 120 calendar days before the dispute is submitted and no more than 365 calendar days before the dispute's processing date. Do not treat this as the separate deadline for the issuer to initiate a dispute. Visa's rule has a limited exception to the 120-day minimum for qualifying Original Credit Transactions; an ordinary recurring payment is not automatically an Original Credit Transaction. Ask the acquirer which submitted and processing dates it applies to the case and whether it can retrieve qualifying history from another merchant in its own portfolio.

Why subscription timing can leave an evidence gap

A merchant-initiated renewal usually happens without the customer opening the checkout page again. That can leave the renewal with no new customer IP address or device event. A signup record may be useful only if the processor can associate its eligible fields with the later payment. Confirm that linkage with the processor instead of copying a signup IP into renewal records by hand.

Monthly renewals may create more candidate transactions than annual billing, but cadence alone does not establish eligibility. Under the post-24 October 2026 rule, a prior purchase from another merchant may help only where the relevant transaction data is available to the acquirer for the applicable submission route. An annual subscription with only one qualifying prior charge may still lack the two records this test requires. Record the billing date, payment credential reference, customer-initiated event, renewal relationship, and source for every field your processor says it can submit.

One public IP or device value anchors the match; add a different permitted field.

Match one anchor field plus another permitted field

The three records—the disputed transaction and both priors—must match on an anchor element plus at least one additional permitted element. The anchor is the cardholder's public IP address or a device identifier. Other permitted fields include the cardholder's account or login ID and full delivery address. From the October 2026 update, qualifying login data can also include an agentic payment provider's login ID. A device ID and a device fingerprint are similar data types; do not count them as two separate matching elements.

Do not infer a match because the name, email, or billing amount looks similar. Compare the actual values the processor will send, field by field. Keep the data only as long as your policies and applicable rules allow, and restrict access to payment and personal information.

The dates pass the example age arithmetic only; all other rule elements still need verification.

Save a case worksheet before a dispute arrives

For each potential case, store the condition, dispute submission date, dispute processing date, payment credential reference, and two candidate prior transactions. For each of the three purchases, keep the transaction date, item or service description, merchant/acquirer source, fraud-report check, and every matching field. Visa generally requires a detailed description of the disputed purchase and both prior purchases. A purchase-order number can substitute only under the specific listed Visa Secure, Visa Token Service, or Visa Intelligent Data Exchange conditions; ask the acquirer whether the case satisfies that route rather than assuming a purchase order is enough.

Here is an invented date example to show the arithmetic, not an eligibility decision: suppose a dispute is both submitted and processed on 31 October 2026. A prior charge on 1 June is 152 days earlier; a prior charge on 1 January is 303 days earlier. Both dates are more than 120 and no more than 365 days before that same example date. The merchant would still need two eligible prior transactions on the same card or associated credential, no disqualifying fraud report, a valid anchor plus another matching element across all three records, and the required descriptions or a permitted substitute. For disputes with different submitted and processing dates, recalculate each prior against both anchors. An arithmetic pass by itself does not establish a qualifying CE 3.0 case.

Prepare recurring-payment data at signup

At the customer-initiated checkout, ask the processor which CE 3.0 fields it captures and can associate with later merchant-initiated transactions. Depending on the supported flow, these may include a public IP address, a device identifier or fingerprint, the customer's login ID, and a full delivery address. Store the processor's transaction reference and the consent or order record that ties the later renewal to the original service. Never create or alter a field to make it appear that a customer was present at renewal.

Before the next billing cycle, verify that event logging has not stripped the checkout fields, the credential reference survives tokenization, and product descriptions remain understandable. A generic label such as “monthly plan” may not explain what the cardholder purchased; maintain a plain-language description of the service and the relevant plan. If the processor cannot carry the data into a renewal, ask it what records are actually available instead of assuming the original checkout data follows automatically.

What CE 3.0 does not cover

CE 3.0 is not a universal defense. It does not cover Mastercard or another network's dispute rules, and it does not replace the process for a different Visa condition. A cancelled subscription complaint often uses 13.2; delivery, service quality, duplicate billing, and refund claims use other conditions with their own requirements. Use the procedure for the case actually opened. If the reason code appears inconsistent with the cardholder's complaint, ask the acquirer to explain the classification before building the packet.

A qualifying record pattern is also not an automatic win. The acquirer must submit complete and accurate data through the right route, Visa validates the rule elements, and the issuer's review remains part of the outcome. Preserve the processor's normal evidence path as a fallback and meet the deadline shown in the case portal. Do not promise that a prior purchase or a match will shift liability in every case.

Ask the processor or acquirer these questions

The processor may collect some data or flag possible candidates, but its interface, format, and supported route can differ. Ask: Does the case show Visa 10.4? Which of the two date anchors are used for these candidate purchases? Does the issuer show any fraud activity on either prior transaction? Which anchor and second matching fields will be sent for all three transactions? Can you retrieve other-merchant history from your own acquiring portfolio for this pre-arbitration case? Does the product description meet Visa's rule, or does the case qualify for a purchase-order-number substitute? Which fields from signup are attached to each later renewal?

Write down the support answer, the case deadline, and the version of the processor's CE 3.0 workflow. If the dispute is being handled as a pre-dispute inquiry rather than pre-arbitration, ask whether the cross-merchant history path is available there; the published rule provisions and the data route may differ. Keep the processor's response with the case file, but do not send it sensitive values that the acquirer did not request.

From 24 October 2026 prior transactions may span merchants, while pre-arbitration data remains limited to what the acquirer processed.

Use this final review before routing the case

• Confirm the network and exact dispute condition.
• Confirm two earlier records use the same card or an associated credential.
• Check the fraud-report status and both date anchors for each prior.
• Confirm the October 2026 merchant-scope rule and acquirer limit for the route being used.
• Compare a public IP or device field and at least one different permitted field across all three transactions.
• Treat device ID and fingerprint as similar data, not two matches.
• Include descriptions for all three purchases, or verify the narrow purchase-order-number substitute.
• Save the source, format, support answer, and submission deadline in the case file.

For a wider response workflow, see the chargeback response overview. The goal is a reproducible, privacy-conscious packet that makes each requirement easy to verify—not a conclusion about what an issuer must decide.