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, direct from your PSP or forwarding your acquirer’s weekly chargeback email, 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: Chargeback Files

It’s very common that acquirers and PSPs provide chargeback notifications to merchants by periodically sharing Excel spreadsheets or CSVs via email.

Depending on whether those spreadsheets have enough data to identify the order or transaction from which the chargeback arose, you may have to do some pre-processing before sending the file to Ravelin.

It is critical that you send these files in a consistent format so that Ravelin can guarantee a quick turnaround time on ingesting the chargebacks to our system.

The preferred format of spreadsheet has the following columns:

  • Gateway
  • Gateway Reference
  • Dispute Date
  • Amount
  • Currency
  • Status

The gateway and gateway reference fields should mirror what is sent to the Ravelin API.

Email: chargebacks@ravelin.com

Sharing: PSP Direct Integrations

Please reach out to us about configuring Stripe or Adyen webhooks for us to automatically ingest chargebacks from these PSPs.

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. Add a custom attribute to the “chargeback” to indicate it’s a TC-40 if sending by API; or let us know that it’s a TC-40 in sharing by email.

  • chargeback ID: prefix with “tc40-” to avoid overlaps with real chargebacks
  • dispute date: the time the notification was received
  • transaction ID, gateway reference, or order ID
  • status: open
  • custom.source: tc40

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.

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 we must be careful to avoid overlap when choosing chargeback IDs. For example, if we use the order ID as the chargeback ID, then when order #123 gets an alert and subsequent chargeback, we need to make sure each gets a separate chargeback ID.

  • chargeback ID: prefix with “ethoca-” to avoid overlaps with real chargebacks.
  • dispute date: time the alert was received
  • transaction ID, gateway reference, or order ID
  • status: open
  • custom.source: ethoca alert

With this data, the amount and currency will be copied from the referenced transaction.

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 methods 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 play 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.