Disputes at Galileo

This guide explains Galileo's dispute process and what you can expect when using Galileo's dispute process. This document assumes that you are familiar with the concepts in About Disputes.

As a Galileo client, you have these options for handling disputes:

  • Let Galileo take care of it — Galileo offers a full end-to-end dispute process for both card transactions and ACH returns. Continue to the next section for more information.
  • Provide your own solution — If you devise your own dispute process, you will still need to integrate your solution with Galileo to some degree. For example, if Galileo holds your balances and you need to grant provisional credit, you or your disputes provider would have to call the Create Adjustment endpoint. You would also need Galileo to advise you of the dispute-related money movement that the networks report to Galileo. Consult with Galileo to work out the integration details, and work with your bank to ensure compliance.

Galileo's dispute process

Galileo can handle all aspects of card disputes and ACH disputes.

Dispute intake

Galileo can provide dispute intake for you in one of these ways:

  • Coming in 2025: A Dispute API that you can integrate into your web page, mobile app or customer-service tool. This API handles both card disputes and ACH disputes.
  • If you are using Galileo's CST, your customer service representatives can use the CST's dispute-intake tool.
  • Your customers can call Galileo's customer service line to report errors and dispute transactions.
  • If Galileo holds your balances, Galileo regularly reviews your accounts for transactions that drive accounts negative and then disputes those transactions. If you hold your balances, you can notify Galileo of the transactions that you want to dispute.

Post-intake processing

After intake, Galileo handles the rest of the dispute process:

  • Galileo gathers all necessary information to successfully process the dispute. This includes any information from the customer that was provided during intake (questionnaire, written statement, sales receipt or other supporting documentation). Galileo also reviews cardholder transactions and account access history as well as any information provided by the merchant.
  • Galileo offers a de minimis threshold to process disputes, which is the minimum dollar amount that triggers an investigation. For example, if you indicate a 15.00 de minimis, all disputes above 15.00 will be investigated by a Galileo agent. All disputes below this threshold are credited to the customer's account, a write-off occurs and a final resolution notification is sent to the customer.

Provisional credit

You can arrange with Galileo to provide provisional credit or you can perform the money movement yourself using the Program API. If you are performing the money movement, use the Create Adjustment endpoint with type: tc.

See Provisional credit in the About Disputes guide for information on when to award provisional credit.

Notifications

Galileo provides cardholders with the applicable notifications at each point of the investigation. By default, Galileo sends these notifications electronically but can send paper letters if the cardholder hasn’t authorized email communications.

Events API webhooks

You can arrange with Galileo to receive Events API webhook messages during various stages of the dispute process. If you are providing notifications to your cardholders, you can pass these webhooks to the cardholder:

  • CSCT: case_created — Sent when a card or ACH dispute case is initiated on the Galileo system, whether in the CST, the Dispute API, or a customer-service call. The case represents one or more disputes, which are individual transactions.
  • DSCT: dispute_created — Sent once for each time that a transaction is added to a case.
  • CSUP: case_updated — Sent when a case is updated, such as when a new document is attached.
  • DSPC: dispute_pc — Sent when provisional credit is awarded to an account, either by you or Galileo. A BADJ: adj event is sent at the same time.
  • DSFN: dispute_final_no_pc — The dispute has been finalized, and provisional credit had not been awarded to the account holder. The outcome of the dispute is in the dispute_resolution field.
  • DSFP: dispute_final_pc — The dispute has been finalized, and provisional credit had been awarded to the account holder. The outcome of the dispute is in the dispute_resolution field.

These are the possible values in the dispute_resolution field:

  • MERCHANT_CREDIT — The merchant sent credit to the account holder's account. If provisional credit was awarded, it should be withdrawn.
  • CUSTOMER_LOSS — The dispute was not resolved in the account holder's favor. If provisional credit was awarded, it should be withdrawn.
  • CHARGEBACK — The dispute was settled in the account holder's favor. If provisional credit was awarded, it should be made permanent.
  • PRTL_CHARGEBACK — Part of the dispute was settled in the account holder's favor. If provisional credit was awarded, the partial amount should be made permanent and the remainder should be withdrawn.
  • WRITE_OFF — The amount is awarded to the account holder and the issuer writes off the amount, usually because the amount is below the de minimis.
  • CH_CANCELED — The account holder canceled the dispute. If provisional credit was awarded, it should be withdrawn.

Transaction codes for disputes

The otypes (transaction types) for dispute-related funds movement vary according to the network. All dispute-related transactions are adjustments (act_type: AD). See the Disputes table in the Transaction Types enumeration. The labels for the dispute-related otypes are:

  • Chargeback — Funds moving from the merchant to the issuer.
  • Temporary credit — Provisional credit awarded to the cardholder.
  • Second presentment — Funds moving from the issuer to the merchant.
  • Exception — An exception to the process has occurred, such as the time for raising a chargeback has expired, but the chargeback was raised anyway.
  • Final dispute — Funds movement representing the final state of the dispute, such as provisional credit being made permanent or withdrawn.

See Disputes in Card Transaction Examples to see how a dispute looks in the ledger. Notice that the chargeback and second presentment are posted at the same time, because Galileo waits until the dispute is final before posting dispute-related adjustments to the account.

Consult Finding Transaction Data to see where else dispute transactions are visible.

Every settled transaction has an acquirer reference number (ARN) that can be used when disputing a transaction. The ARN is available in the CST, the Program API responses, and in the Posted Transactions RDF.

Disputes and reconciliation

In Galileo Analytics (gAnalytics) you can refer to two reports that are in Standard Reports > Chargebacks & Disputes:

  • Dispute Tracker Log — A list of all disputes made, the status of the dispute, and whether a chargeback was raised
  • Dispute Summary — Total amounts charged back, second presentments, and arbitration and pre-arbitration

You can also request a daily Dispute and Chargeback RDF (raw data file) from Galileo to get detailed information on disputes. The information is similar to the Dispute Tracker Log report.

📘

Note

Dispute-related transactions in the Posted Transactions RDF and event messages do not have an identifier to tie them back to the transaction under dispute. Use the AUTHORIZATION_CODE field in the Dispute and Chargeback RDF to link disputes to their original transactions.

Example dispute sequence

For this example, the intake method is the CST. You subscribe to the events messages that are mentioned in this scenario. Galileo holds the balances for your accounts, and the network is Mastercard.

  1. The cardholder contacts a customer service agent to dispute a $50 transaction.
  2. The agent collects all required information and submits the dispute.
  3. Galileo sends the DSCT: dispute_created message, which you pass to the cardholder as an acknowledgment of the dispute.
  4. Because the amount is above your dispute threshold, a Galileo agent investigates the dispute. The agent determines that it is a valid dispute but more information from the merchant is needed, so the agent raises a chargeback with Mastercard.
  5. In this case the dispute falls under Regulation E, so Galileo awards provisional credit to the cardholder and sends the DSPC: dispute_pc event message.
  6. In your Posted Transactions RDF the next day, the provisional credit is included, with transaction code ADtc.
  7. The merchant receives the chargeback notice from Mastercard but does not respond.
  8. Because the merchant does not respond, Galileo rules in favor of the cardholder.
  9. Galileo sends the DSFP: dispute_final_pc event message with dispute_resolution: CHARGEBACK, which you pass to the cardholder as a notification of the verdict.
  10. Galileo posts these transactions to the ledger, which are visible in your Posted Transactions RDF the next day:
    • Chargeback — Transaction code ADH, which adds 50.00 to the issuer account.
    • Provisional credit backout — Transaction code ADtc for –50.00 from the cardholder account
    • Permanent credit added — Transaction code ADfd for 50.00 to the cardholder account
  11. Galileo sends you a BADJ: adj event message for each of the three adjustments.