Chargebacks

Chargebacks are an important aspect of the Ravelin system. The measure of success for Ravelin invariably includes attaining or maintaining a low chargeback rate. Chargebacks are used as signals in our machine learning pipeline, and as fraudulent indicators in Ravelin Connect; informing Ravelin’s recommendations to prevent an order from a customer.

Only fraud chargebacks should be given to Ravelin. Chargebacks due to goods not being as described, or being damaged, will be treated as indicators of fraud if uploaded. This should be avoided.

Required Data

Whether sharing chargebacks with Ravelin via our API or direct from your PSP, the data requirements are the same:

  1. Dispute Date
  2. Card Transaction Identifier

    In order to use chargeback data for machine learning, Ravelin must know which card transaction and customer the chargeback arose from. From this, we can identify the payment method, order, and customer that generated the chargeback. Ravelin can identify the transaction for a chargeback in three ways, in order of preference:

    1. A transaction ID;
    2. A gateway reference; or
    3. An order ID (from which we use the first successful auth/capture transaction)
  3. Chargeback ID

    So that we can keep track of the chargeback. If you do not store your chargebacks in a system that provides a chargeback ID, you can use the transaction ID, gateway reference, or order ID in its place. But be wary of the potential for collisions.

For reporting purposes it is also useful that we know:

  1. The chargeback status (e.g. open/won/lost)
  2. The chargeback amount (defaults to the transaction amount, if missing)
  3. The chargeback currency (defaults to the transaction currency, if missing)

Sharing: API

The best way to share chargebacks with Ravelin is through the API. If your PSPs and acquirers provide API or webhook access to your chargebacks, you can use the data they provide to send chargebacks to the relevant Ravelin API endpoint:

Adding chargebacks into Ravelin using the API guarantees the lowest actionable time for a chargeback, and hence provides you the best protection.

Sharing: Adyen Integration

Please reach out to us if you’d like to configure chargebacks from Adyen to be automatically ingested with webhooks.

TC-40s as Indicators of Fraud

If your business practices involve refunding notifications of fraud before they turn into chargebacks, you can upload these TC-40s as if they were chargebacks. Use the status “TC-40” to indicate it’s a TC-40 when sending by API.

  • chargeback ID: a unique identifier for the dispute
  • dispute date: the time the notification was received
  • transaction ID, gateway reference, or order ID
  • status: “TC-40”

As the TC-40 is not yet a chargeback, it is acceptable to use the order amount and currency as the chargeback amount, and so these do not need to be sent. If you subsequently receive a chargeback for the same dispute, send an update event for the same chargeback ID and set the chargeback status to “OPEN”.

Ethoca Alerts as Indicators of Fraud

Similarly to using TC-40s as chargebacks, it may be beneficial to have Ravelin treat Ethoca Alerts of fraud as chargebacks. You may need to do some pre-processing to identify the order and transaction the alert refers to.

The data requirements are the same as a regular chargeback, but please use the status “ETHOCA-ALERT” to identify the dispute as an Ethoca Alert.

  • chargeback ID: a unique identifier for the dispute
  • dispute date: time the alert was received
  • transaction ID, gateway reference, or order ID
  • status: “ETHOCA-ALERT”

With this data, the amount and currency will be copied from the referenced transaction. If you subsequently receive a chargeback for the same dispute, send an update event for the same chargeback ID and set the chargeback status to “OPEN”.

Non-Fraud Chargebacks

Not all chargebacks originate from card-not-present fraud. Impatient customers can file chargebacks instead of requesting a refund, and some payment method types or third-party acquirers can raise chargebacks when issuing refunds.

If you wish for Ravelin to treat a chargeback as non-fraudulent, you can inform us when submitting the chargeback through our API.

Liability Shifted Chargebacks

You are not always liable to pay the costs of a chargeback if a third-party has taken liability for the amount. This is most often true when a transaction has successfully passed a 3DS check; the card issuer will become liable for the chargeback amount.

Ravelin will automatically flag chargebacks as being subject to a liability shift if we have received record that the associated transaction successfully passed 3DS. If there are other scenarios for which liability of a chargeback has been shifted from you, please inform us through our API.