This guide is deprecated. Use our Sending Disputes guide and the Dispute Endpoint.
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 or direct from your PSP, the data requirements are the same:
Dispute Date
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:
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:
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.
Please reach out to us if you’d like to configure chargebacks from Adyen to be automatically ingested with webhooks.
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.
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”.
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.
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”.
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.
You are not always liable to pay the costs of a chargeback if the issuer has taken liability for the transaction. This is most often true when a transaction has successfully passed a 3D Secure (3DS) check.
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.
Was this page helpful?