When we receive a chargeback alert from a network such as Ethoca or CDRN, our system attempts to match the alert to the corresponding transaction and order in your store.
​

A Can’t Find alert means that we received the alert, but we were unable to confidently match the information provided by the network to an order or transaction in your account.
​

It does not necessarily mean the alert is false or invalid.

In many cases, the underlying transaction is legitimate, but we are missing information or access needed to confidently identify it.

We intentionally mark these alerts as Can’t Find rather than incorrectly attaching an alert to the wrong order. Incorrectly matching an alert could result in the wrong transaction being refunded, which creates a much bigger problem for your business.

There are several reasons an alert may not be matched. The two most common causes we see are:

Other causes include missing Order IDs, unavailable ARN data, tokenized payments, refund timing, changes to your payment processing setup, and limitations in the information provided by the network.

Let's break these down.

Your billing descriptor is one of the most important pieces of information used to identify transactions associated with your business.

A billing descriptor that is extremely generic can create matching issues, particularly if another business or another store is using the same or a similar descriptor.

We recently worked with a merchant operating a store called Veloura.

The merchant had previously operated another store also using the name Veloura. That store was eventually shut down, and a new store was opened and enrolled with us.
​

However, both stores used the same billing descriptor.

The merchant subsequently received several Can't Find alerts and initially believed the alerts were incorrect.

After investigating, we discovered that the same descriptor was being used across both stores. Because the descriptor did not uniquely identify the new store, there was no reliable way for us to determine which transaction the network alert belonged to.

The alerts were not necessarily false. The information provided to us simply wasn't unique enough to confidently match them to the correct store.

We strongly recommend using a unique and recognizable billing descriptor.

Where appropriate, using your domain or another unique identifier associated with your business can be a good option because:

Best practice: Your billing descriptor should be unique, recognizable, and consistent with the business your customer believes they purchased from.

This is another very common reason for Can't Find alerts.

Some merchants process payments through multiple processors, gateways, MIDs, or payment accounts.

For example, a merchant might have:

The merchant may provide us with Shopify collaborator access and assume that this gives us everything we need.

It doesn't always.

For Ethoca and CDRN alerts in particular, the transaction information we receive may need to be cross-referenced against information held by your processor or gateway.

If we don't have access to the relevant processing environment, we may not be able to locate the transaction associated with the alert.

This can also prevent us from taking the appropriate action on the alert, such as processing an eligible refund.

Imagine you have 100 orders processed through Shopify Payments and another 20 processed through a separate gateway.

You provide Disputifier with Shopify access, but we don't have access to the second gateway.

An Ethoca alert arrives for one of those 20 transactions.

We can receive the alert from Ethoca, but when we attempt to locate the corresponding transaction using the information available to us, we can't find it.

The alert may be completely legitimate.

The issue is simply that the transaction exists in a system we cannot access.

If your business uses multiple payment processors or gateways, please let us know.

Depending on your setup, we may need access to the relevant:

Providing Shopify access alone may not be sufficient for every merchant configuration.

Ethoca and CDRN don't necessarily provide the same Shopify-specific information that Disputifier uses to identify an order.

We may receive other transaction or card-network identifiers without receiving a direct Shopify Order ID.

When that happens, our system has to use the available transaction information to locate the corresponding order.

If the information isn't sufficient to establish a confident match, the alert may be marked Can't Find.

This doesn't mean the transaction doesn't exist.

It means we don't have enough information to safely associate the alert with a specific order.

An ARN (Acquirer Reference Number) is an important transaction identifier that can help connect payment activity across the payment ecosystem.

However, ARN availability and timing can vary depending on the processor and payment flow.

Some processors provide merchants with ARN information directly in their dashboards. Others may provide different identifiers, such as BIN/CAID or other transaction references, or may not make certain information immediately available.

A transaction may exist, but the relevant reference information may not yet be available when Disputifier attempts to match the alert.

As additional transaction data becomes available, the transaction may become easier to identify.

For this reason, missing ARN information doesn't automatically mean that an alert is invalid.

Payments made through services such as:

can introduce additional matching complexity.

These payment methods can use tokenized payment credentials, meaning the card information presented to different parties in the payment ecosystem may not always look identical.

The network may provide information associated with a payment token while the merchant or processor exposes information associated with the underlying card transaction.

This can make it more difficult to establish a direct match between the alert and the Shopify order.

Again, this doesn't mean the alert is necessarily incorrect.

It means additional information may be required to confidently identify the transaction.

Timing can also cause confusion.

For example:

In this situation, the transaction can legitimately exist and the refund can legitimately be in progress, while the network information we're receiving doesn't yet reflect the completed refund.

This is one reason you may occasionally see alerts associated with transactions that you believe have already been refunded.

When our system identifies an alert as Already Refunded, it can be submitted for the appropriate credit review where applicable.

Your payment processing environment isn't necessarily static.

You may:

If the transaction is processed through a path that isn't included in the information or access available to Disputifier, we may not be able to match the alert.

You were previously processing transactions through Processor A.

You later add Processor B and some transactions begin routing through Processor B.

Disputifier continues to have access to Processor A, but not Processor B.

An Ethoca alert arrives for a transaction processed through Processor B.

The alert is legitimate, but we may not be able to locate the corresponding transaction because the transaction exists outside the processing environment we can access.

​If you add a processor, gateway, MID, or billing descriptor, please let our team know.

There are cases where all of the systems involved are functioning correctly, but the information provided to us isn't sufficient to confidently match the alert.

The data available to Disputifier may come from several different sources, including:

These systems don't always expose the same information in the same format.

If we cannot establish a sufficiently reliable match, we will mark the alert Can't Find rather than guessing.

Imagine receiving an alert and finding two transactions that look similar.

If we incorrectly associate the alert with Transaction A when it actually belongs to Transaction B, we could potentially refund the wrong customer or transaction.

That's unacceptable.

​Accuracy is more important than forcing a match.

No.

This is one of the most important things to understand.

A Can't Find alert means:

​We received an alert, but we were unable to confidently match the information provided by the network to an order or transaction in your account.

It does not automatically mean:

There can be legitimate reasons why an alert cannot be matched.

We understand that being billed for an alert you cannot immediately identify can be frustrating.
​

When an Ethoca alert is confirmed to be a Can't Find instance that qualifies for a credit, the applicable credit will be processed according to our credit procedures.

More importantly, our goal isn't simply to credit the alert after the fact.

​We want to reduce the number of Can't Find alerts you receive in the first place.

That's why identifying the underlying cause is important.

The best way to reduce these alerts is to make sure we have the information and access necessary to identify your transactions.

1. Use a unique billing descriptor

Avoid extremely generic descriptors or reusing the same descriptor across multiple stores.

2. Tell us about every processor and gateway you use

If you're processing transactions through multiple providers, let us know.

3. Provide the appropriate access

Depending on your setup, we may need access to relevant processors, gateways, CRMs, and payment platforms in addition to Shopify.

4. Tell us when your payment setup changes

If you add a processor, gateway, MID, billing descriptor, or change how transactions are routed, let us know.

5. Keep your payment information consistent

The more consistent your transaction information is across your payment ecosystem, the easier it is to match network alerts to your orders.

6. Use recognizable customer-facing descriptors

A recognizable descriptor doesn't just help Disputifier. It can also help your customers identify purchases and contact your business directly rather than immediately contacting their bank.

If you have a Can't Find alert and want us to investigate it, the following information can be particularly useful:

You don't necessarily need to provide all of these. Our team can tell you what information is most useful based on your specific setup.

Let's say a merchant receives six Can't Find alerts.

The merchant believes the alerts are false because they can't find the transactions in Shopify.

After investigating, we discover:

The alerts weren't necessarily false.

The issue was that the same billing descriptor was being used across multiple businesses, making it impossible to confidently determine which store the alerts belonged to.

Once the merchant separates the descriptors and ensures the appropriate payment environments are accessible, the number of Can't Find alerts can be significantly reduced.

We receive alerts through external alert networks such as Ethoca and Verifi.

When an eligible alert is generated and delivered to us, there can be a network cost associated with that alert regardless of whether we can ultimately match it to a specific Shopify order.

This is why an alert may initially appear as a billable alert even if it is subsequently classified as Can't Find.

Where an alert qualifies for a credit, the appropriate credit process applies.

Our objective is to provide full visibility and accountability around these situations rather than leaving merchants to determine months later why they were billed.

Can't Find does not mean false alert.

It means that we received an alert but could not confidently match it to a transaction using the information and access available at that time.

The most common causes we see are:

The first two are particularly common.

Our goal is not simply to identify Can't Find alerts and issue credits. Our goal is to understand why they're happening and reduce them to an absolute minimum.

If you're seeing a recurring number of Can't Find alerts, contact our support team.

We can review the pattern with you and determine whether the underlying issue is related to your billing descriptor, payment processor, gateway access, transaction data, or another part of your payment setup.