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.
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:
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:
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:
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.
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:
The gateway and gateway reference fields should mirror what is sent to the Ravelin API.
Please reach out to us about configuring Stripe or Adyen webhooks for us to automatically ingest chargebacks from these PSPs.
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.
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.
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.
With this data, the amount and currency will be copied from the referenced transaction.
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.
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.