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 balance ledger 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.

📘

Note

By default only posted transactions can be disputed. If you also want the ability to dispute pending authorizations, contact Galileo to enable that feature.

Dispute intake

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

• 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.

Remember that provisional credit should not be applied to pending authorizations.

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 messages 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.
• DSIC: dispute_investigation_completed — Sent when the investigation of a disputed transaction has been completed; contains the decision and the deny_reason, if any.
• 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.

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 card transaction has an acquirer reference number (ARN) that is used when disputing a transaction. The ARN is available in the CST, the Program API responses, and in the Posted Transactions RDF.

Tracking disputes

How you track a dispute across the Galileo system depends on the type of transaction being disputed.

Settled transactions

To track transactions that have already settled, use the SETL: setl event message as the starting point for tracking a disputed transaction. This table shows how to correlate the identifiers from different sources. Entries in the same row contain the same value.

SETL: setl

• settle_detail_id — The transaction's designator in the settlement batch file.
• settle_currency_amount — The transaction amount in the settlement currency. In most cases, this is the same currency as the account's currency, unless you have set up a different settlement currency. See Multicurrency BINs for more information. In the Posted Transactions RDFs this is SETTLE AMOUNT.
• auth_id — The authorization ID, which you can use to find the transaction in the RDFs under AUTHORIZATION CODE. Authorization IDs are not unique.

DSxx: dispute_

• dispute_id — The transaction's identifier in the dispute system.
• settle_detail_id — The same value as in the SETL: setl event.
• dispute_amount — The amount that is being disputed.
• dispute_pc_amount — The amount of provisional credit that has been awarded.

BADJ: adj

• amount — When otype: tc, this is the amount of provisional credit that has been posted to the customer account. When otype: fd, this is the amount that is actually refunded to the account, and it can be different from the amount of provisional credit.
  settle_dtl_id — The same value as in the SETL: setl event.
• source_id — For dispute-related adjustments, this field contains the dispute_id from the dispute-related event.
• adj_id — The identifier for the adjustment. This is SOURCE ID in the RDFs.

Posted Transactions RDFs

• SETTLE DTL ID — The same value as in the SETL: setl event.
• SETTLE AMOUNT — Amount of the posted transaction in the settlement currency
• TRANSACTION AMOUNT — When TRANSACTION CODE/TYPE: ADtc, this is the amount of provisional credit that has been posted to the customer account. When TRANSACTION CODE/TYPE: ADfd, this is the amount that is actually refunded to the account, and it can be different from the amount of provisional credit.
• SOURCE ID — The same as the adj_id in the BADJ:adj event, if any.
• AUTHORIZATION CODE — The auth_id.

Dispute-related RDFs

The dispute-related RDFs are the Dispute and Chargeback RDF and the Reg E RDF.

• SETTLE_DTL_ID — The same value as in the SETL: setl event.
• DISPUTE_ID — The transaction's identifier in the dispute system.
• DISPUTE_AMOUNT — The amount that is being disputed.
• PC_AMT / PROVISIONAL_CREDIT_AMOUNT — The amount of provisional credit that has been awarded.
• AUTHORIZATION_CODE — The auth_id

Pending authorizations

To track pending authorizations, use the BAUT: auth event message as the starting point for tracking a disputed pending authorization. This table shows how to correlate the identifiers from different sources. Entries in the same row contain the same value.

BAUT: auth

• pmt_ref_no — The PRN
• amount — Amount of the authorization request, in the currency of the account.
• auth_id — The authorization ID, which you can use to find the transaction in the RDFs under AUTHORIZATION CODE. Authorization IDs are not unique.

DSxx: dispute_

• auth_id — The authorization ID. This field is available by request for dispute-related events.
• dispute_id — The transaction's identifier in the dispute system.
• dispute_amount — The amount that is being disputed.

Authorized Transactions RDF

• PRN — Payment reference number
• TRANSACTION AMOUNT — Amount of the authorization request
• TRANSACTION DATE/TIME — Timestamp for the authorization approval.
• AUTHORIZATION CODE — The auth_id.

Dispute-related RDFs

The dispute-related RDFs are the Dispute and Chargeback RDF and the Reg E RDF.

• DISPUTE_ID — ID for the dispute as assigned by the dispute system.
• PRN — Payment reference number
• DISPUTE_AMOUNT — Amount of the authorization request that is being disputed
• AUTH_DATE — Timestamp for the authorization approval.
• AUTHORIZATION_CODE — The auth_id.

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. For a more detailed report, see the Reg E RDF.

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 and the BADJ: adj event message with otype: tc..
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.

Galileo setup

See the Disputes parameters table for details of the full list of product parameters to be configured at Galileo.