Disputifier Founder on Winning Chargebacks

Mark Wagner believes the best chargeback recovery systems are automated and data-driven. He founded Disputifier, an Austin, Texas-based chargeback software company, on that premise in 2021.

He told me, “We’ve developed an intuitive system over the years. It combines data from the transaction with our testing and identifies an appropriate response.”

He and I recently discussed the state of ecommerce chargebacks and how merchants can recover false claims. The audio of our entire conversation is embedded below. The transcript is edited for length and clarity.

Eric Bandholz: Tell us what you do.

Mark Wagner: I run a software company called Disputifier. We’re an automated chargeback recovery agency. We see over 60% of chargebacks being fraud. These are not impossible to win. It’s more about separating the valid credit cards. Say a crook bought someone’s credit card info on the dark web. That’s a very different situation than a customer trying to get free stuff.

We help with duplicate chargebacks [where a cardholder wins a chargeback, then loses it, then refiles it], which are hard to prevent but easy to win. Duplicates are our highest win rate — around 90%. We attach screenshots of the checkout page and the purchase process for duplicate responses. We submit all the evidence to the card issuer after testing. We have a ton of data identifying the exact way to format a response, which can have a huge impact.

We present the evidence via PDFs. So, instead of using the Shopify Payment’s response, we built our own from scratch. We can highlight specific areas and make it almost like a lawsuit with different sections. We try to format it differently from Shopify.

Bandholz: Do real people at the issuing banks read the documents?

Wagner: Yes, the banks will print your chargeback response and throw it on someone’s desk. That person will manually flip through it and decide whether to side with the merchant when he or she has already agreed with the cardholder. So the formatting and images matter. We keep text to a minimum — two to three sentences. Folks are visual. It’s all in the format, the graphics, the images, and how it’s presented.

We’re software-based, meaning we programmatically ingest data from Shopify and other sources and then add those into our automated response. We manually review our responses to ensure they’re up to par and if we have any custom evidence, but typically over 90% of responses are unchanged from what our system generates.

Bandholz: Can’t you just use Shopify’s fraud analysis?

Wagner: Shopify’s fraud analysis is too basic and not always helpful. It might have 10 data points without explaining the reason for flagging a chargeback as low or high risk. For instance, Shopify might mark a chargeback as low risk even if the order was placed outside of North America and shipped to California. It doesn’t make sense. Conversely, many are flagged as high risk with no serious indicators. If you’re refunding those, then you’re losing money. We’ve run tests. Roughly 7% of Shopify’s medium-risk orders (and 35% of high-risk) turn into a chargeback. So the vast majority are legit buyers.

Bandholz: How much effort should merchants put into fighting chargebacks?

Wagner: It depends on your size, business model, and average order value. It becomes a necessary but labor-intensive process if we’re talking about higher average order values — hundreds to thousands of dollars. If your AOV is lower, you should not spend time on it.

When I ran ecommerce brands, we had an employee who would try to determine if an order was fraudulent. She’d call everyone in the office and say, “Guys, look at this.” End of the day, we still had a ton of chargebacks. It’s an imperfect process that is better not done by humans.

Bandholz: What’s Disputifier’s approach?

Wagner: We’ve developed an intuitive system over the years. It combines data from the transaction with our testing and identifies an appropriate response. It merges the two. It’s a customized response for every order but matches the template. That format has worked for us. It then goes through a manual review and gets submitted on a merchant’s behalf.

We make money by taking a percentage of orders we win.

When Shopify brands come to us, they’re winning around 25%. Our win rate is a bit over 50%, depending on the processor. Alternate payment methods seem to have a fair dispute process, whereas credit card issuers can be unpredictable.

Merchants should always require customers to agree to terms and conditions, including the refund policy, during the checkout. Customers cannot complete their order unless they click the box to agree. Sellers can then reference it if a customer falsely claims a refund. It significantly helps the win rate.

Again, this is for high AOV. I wouldn’t do it on low AOV. Plus, for very high orders — $5,000 or more — merchants should make an actual contract with the customer. This will help with a win, too. Never take a chance with a big purchase.

Merchants should test and determine what that winning response looks like. It’s tough for brands to figure out the entire chargeback process on their own. It’s murky. Every bank has slightly different rules.

Bandholz: Where can folks get your software?

Wagner: Our site is Disputifier.com. Follow me on Twitter at @themarkwagner or on Instagram and LinkedIn.

Charts: Global Cybersecurity Trends 2023

The World Economic Forum is a non-governmental lobbying organization for multinational businesses, best known for its annual meeting in Davos, Switzerland. The WEF’s “Global Cybersecurity Outlook 2023” report (PDF), in collaboration with Accenture, the consulting firm, highlights the top cyber issues and their impact on organizations worldwide.

The report includes insights from late 2022 and early 2023 from five key sources: a survey of global organizational leaders, workshops with cybersecurity experts, interviews, and data from reports and research.

The study revealed a significant gap in the perceptions of cyber issues.

The view that “cybersecurity is a key business enabler” is shared by 51% of business leaders and just 32% of security professionals. This discrepancy suggests that business leaders might be placing a higher emphasis on cybersecurity than their security counterparts.

Of the respondents in 2023, 29% of cyber leaders and 27% of business leaders are confident that their organization is cyber resilient.

According to the data, only 10% of business leaders and 13% of cyber leaders feel they have critical gaps in skilled personnel.

Geopolitical events in the past year have impacted global cyber strategy and operations. The data shows that organizations are proactively enhancing their internal policies and processes and implementing more effective cybersecurity controls when engaging with third parties.

How SPF, DKIM, DMARC Drive Email Delivery, Security

A trio of email authentication standards work together to improve email deliverability for the sender and email safety for the recipient.

Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) help to ensure that emails sent from your company are real and that malicious actors are not spoofing or otherwise tampering with them.

SPF, DKIM, DMARC

SPF, DKIM, and DMARC show the receiving email server that a given message was sent from an authorized IP address, that the sender is authentic, and that the sender is transparent about its identity.

Let’s take each one in turn.

Setting up SPF records for your domain involves adding a type of TXT record containing an authorized list of outgoing mail servers to the Domain Name System (DNS). SPF verifies that emails from your business’s domain come from an authenticated source, not an imposter.

DKIM keys consist of two parts: a public key stored in the DNS and a private key stored on the sending mail server. The DKIM signature attached to each outgoing email is used by recipients’ mail servers to verify its authenticity. DKIM can also indicate if a given email message has been altered.

DMARC is a policy mechanism that allows a company to control how incoming emails from its domain should be handled if they fail the SPF or DKIM authentication. The options are “reject,” “quarantine,” or “none.” This can be like an alarm bell if a wrong-doer is trying to use your domain.

SPF Records

Setting up an SPF record requires access to your domain’s DNS records at the registrar, such as GoDaddy or similar. If you have ever had to verify your domain or move it to a new server you likely updated its DNS record.

Screenshot of an SPF record in a DNS settings interfaceScreenshot of an SPF record in a DNS settings interface

An SPF record is simply a TXT record in your domain’s DNS.

The SPF record will be of the type “TXT.” And it will start with the version of SPF you are using.

v=spf1

The version is followed by a list of authorized IP4 or IP6 addresses, as in:

v=spf1 ip4:192.168.0.1

This SPF record would authorize emails from the 192.168.0.1 IP address. To allow a range of IP addresses, you could use Classless Inter-Domain Routing (CIDR) notation (sometimes called “slash” notation).

v=spf1 ip4:192.168.0.0/16

The above SPF record would authorize a range of IP addresses from 192.168.0.0 to 192.168.255.255 — this is what the “/16” indicates.

Using the prefix “a,” an SPF record can authorize a domain by name. The record below authorizes a server associated with the example.com domain.

v=spf1 a:example.com

Similarly, the prefix “mx” (“mail exchange”) authorizes specific mail servers.

v=spf1 mx:mail.example.com

To authorize a third-party sender, use the prefix “include.” The example below permits both an IP range and Google servers.

v=spf1 ip4:192.168.0.0/16 include:_spf.google.com

There are also two SPF qualifiers. The first is ~all with a tilde (~). The second is -all with a hyphen (-).

The tilde version (~all) is a soft-fail qualifier. In most cases, the receiving email server will accept messages from senders that aren’t in the associated SPF record but consider them to be suspicious.

The hyphen version (-all) is a hard-fail qualifier. The receiving email server will likely label messages sent from a server not authorized in the SPF record as spam and reject them.

Finally, all of these may be used together for relatively complex authorizations.

v=spf1 ip4:192.168.0.0/16 a:example.com include:_spf.google.com

Remember, SPF records help the receiving email servers identify authentic email messages from your company’s domain.

DKIM Keys

DKIM protects your domain and helps to prevent anyone from impersonating your company. The two DKiM keys allow the recipient’s email server to verify that your company sent the message and that it was not altered after you sent it.

The first step in setting up DKIM is generating the keys — one public and one private. The private key is secure on the server used for sending emails from your domain. The public key is added to the DNS as a TXT record.

The tricky part is generating the keys since the exact procedure for creating them varies from one email service provider to the next. And it is completely different if your company hosts its own mail server.

Email service providers offer instructions. Here are several examples in no particular order.

In each case, the DKIM is completed when you add — copy and paste — the email provider’s CNAME record to your domain’s DNS. This record(s) represents the public key to authenticate your company’s outbound email marketing messages.

DMARC

DMARC provides another layer of protection and also instructs email servers what to do with messages that fail SPF or DKIM authentication.

The foundation of DMARC is a TXT record placed in your domain’s DNS. This will contain the DMARC policy with at least two elements:

  • An email address to receive aggregate reports of email authentication, and
  • The action to take on emails that fail authentication (i.e., reject or quarantine).

Here’s an example DMARC TXT record in a DNS:

v=DMARC1; p=quarantine; rua=mailto:armando@example.com; ruf=mailto:armando@example.com.

The record begins with the DMARC version.

v=DMARC1;

The “p” element assigns the action for emails that fail authentication. In this case, it’s set to “quarantine,” which instructs the receiving server to move such messages to a holding area. Other options include “none” — which does not stop the email but monitors SPF or DKIM failures — or “reject.”

p=quarantine;

The prefixes “rua” and “ruf” tell the receiving server where to send aggregate reports (rua — Reporting URI for Aggregate data) and forensic reports (ruf — Reporting URI for Failure data). These reports can disclose a criminal attempting to impersonate your business.

Additional modifiers include:

  • pct — the percentage of email messages subjected to the DMARC policy.
  • sp — the DMARC policy for subdomains.
  • adkim — assigns strict (adkim:s) or relaxed (adkim:r) mode for DKIM.
  • aspf — assigns strict (adkim:s) or relaxed (adkim:r) mode for SPF.

Third-party services can help generate a DMARC record based on the official standard. These services include:

Protect Sender and Recipients

Setting up SPF, DKIM, and DMARC records for your domain ensures that email servers recognize messages from your company as authentic and reject imposters. The result protects your company’s reputation and shields customers from phishing attacks and other types of email fraud.