Dispute Management - ePayments
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Dispute Management Copyright © 2019 Ingenico ePayments
Dispute Management Table of contents 1. Introduction 2. Credit card process flow 2.1 Payment process 3. Key benefits 4. Dispute Management process 4.1 Acquirers 4.2 Overall process 4.3 Retrieval request 4.3.1 Retrieval request process flow 4.3.2 Example retrieval request 4.3.3 Time-frame retrieval request 4.3.4 Required information 4.3.5 How should the information be presented 4.3.6 Refunding the transaction 4.3.7 How to refund via the Ingenico Back-Office 4.3.8 What is the Acquiring Reference Number 4.4 Chargeback notification 4.4.1 Chargeback notification process flow 4.4.2 Example notification of chargeback 4.5 Time-frame notification of chargeback 4.6 Required information 4.7 How should the information be presented 5. Chargeback Page 1 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 5.1 Chargeback definition 5.2 Chargeback process flow 5.3 Chargeback reporting 5.3.1 How to retrieve the chargeback reason code 5.4 Chargeback reversal 5.5 Chargeback monitoring programs 6. Dispute 6.1 Process flow representment 6.2 How to initiate a representment 6.2.1 Time-frame for representments 6.3 Required information 6.4 How should the information be presented 6.5 Auto-representment 6.5.1 Auto-representment chargeback and refund 6.6 Dispute reporting 7. Arbitration chargeback 7.1 Representing a pre-arbitration chargeback 7.2 Applicable fees for an arbitration case 8. (Pre)-compliance chargeback 8.1 Initiating a pre-compliance case 8.2 Applicable fees for a compliance case 9. Good faith request Page 2 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 10. 3D Secure 10.1 3D Secure process flow 10.2 Liability shift conditions 10.2.1 Chargeback reason codes covered by 3D Secure 10.2.2 3D Secure recurring order model 10.2.3 Key benefits 10.2.4 Limitations 11. Contact details and merchant questions 12. Fraud detection module 13. Glossary 14. Disclaimer and Document Administration Page 3 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 1. Introduction This document will outline the Ingenico ePayments Dispute Management process and aims to provide clarity with regards to the terminology, procedures and several important Dispute Management features. Accepting credit card transactions in any environment carries inherent risks such as the risk of chargebacks. Especially when processing in a Card Not Present (CNP) environment, the risk of chargebacks are ever present. Merchants of Ingenico ePayments process in a CNP environment and are confronted with chargebacks and retrieval requests on a regular basis. Due to the nature of the CNP environment the cardholder is well protected by the Card Scheme[1] regulations and the burden of proof is always placed on the Merchant. Ingenico ePayments, as a Payment Service Provider is obliged to follow the rules and regulations of the banks and Card Schemes and always acts accordingly. This means that if a chargeback is reported it is always the Merchant that must prove that the chargeback is not valid. In order to best help Merchants accomplish this, this guide has been created. Should this document raise any questions please address them to: dispute.management@ecom.ingenico.com [1] A Card Scheme is a credit card company Page 4 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 2. Credit card process flow In order to better understand the entire Dispute Management process it is important to have a thorough understanding of the credit card processing flow. This chapter will explain the key points and steps during an E-commerce transaction. Should any questions arise about the credit card process flow, please contact your designated Account Manager. 2.1 Payment process Figure 1: Flowchart of the credit card process at Ingenico ePayments, which includes the optional Fraud Detection Module The grey arrows represent the real-time online process while the blue arrows represent the off-line process. 1. Consumer decides to pay for a purchase on the website and presses the pay button. The consumer chooses which card type he would like to use. 2. The Consumer enters the card details and the payment request is sent to Ingenico ePayments. The Fraud Detection Module: At this point the transaction is sent for fraud screening and if it is accepted it will continue to step 3. If not, the transactions will be denied because it has hit at least one of the fraud rulesDepending on the configuration of the fraud rules and the level of risk, a manual review will need to be performed by one of the Ingenico Fraud Experts or the merchant himself. This means that one will have to manually accept or deny the transaction in the back office. If the transaction is high risk (red scoring), it will automatically be blocked. 3. The transaction details are sent to the acquiring Bank. 4. The transaction details are sent from the acquiring Bank to the card issuing Bank for authorization of the transaction. 5. The transaction authorization response is sent from the card issuing Bank to the acquiring Bank. 6. The card and transaction authorization response is sent from the acquiring Bank to Ingenico ePayments. 7. Ingenico ePayments provides the authorization response in real-time back to the Merchant and Consumer. As from this point the transaction is considered successfully authorized, therefore you could decide to release the product or service to the Page 5 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management customer. If transaction is approved, it continues through the remaining process: From 8 to 11, the transaction settlement information is transmitted through Ingenico ePayments, acquiring Bank, issuing Bank and back to Ingenico ePayments. 12. Ingenico ePayments provides reporting and remits the funds to the Merchant. Page 6 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management
3. Key benefits
The Dispute Management Department at Ingenico ePayments is able to combine all the resources and expertise when it comes to
chargebacks, Card Scheme rules & regulations and representments into one department. This department has only one goal: to help you win
more representments!
Key benefits of the Dispute Management Department:
In-house dispute management process
- One single point of contact for all your dispute management related questions : dispute.management@ecom.ingenico.com
- Available for training & presentations
We take care of all the work ‘behind the scenes’ on your behalf;
- Process incoming requests for information
- Process incoming notifications of chargeback
- Process outgoing requests for information
- Process outgoing notifications of chargeback
- Gather data from the databases
- Gather all supporting documentation required
- Gather all information required by the acquiring bank
- Present the dispute to the acquiring bank
- Follow up with acquiring banks
- Quality Assurance
- PCI-DSS Compliancy
Increase chance of success rate of representments
Auto-Represent several chargeback reason codes
Reporting
Extensive knowledge on Dispute Management processes
In-depth knowledge of Card Scheme regulations
In-depth knowledge of chargeback reasons
Page 7 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 4. Dispute Management process 4.1 Acquirers The acquiring banks work with retrieval requests and chargebacks; sometimes a prior notification (notification of chargeback) is sent before a chargeback is debited from Ingenico ePayments and subsequently passed on to your account. 4.2 Overall process These are the main four processes and although they are closely related, they are not necessarily connected. For example, it’s possible that you will not receive a retrieval request but rather a direct chargeback. For the vast majority of the chargeback reason codes the issuing bank is not obligated to raise a retrieval request. The upcoming chapters will explain the processes in further detail. 4.3 Retrieval request A retrieval request is initiated by the issuing bank, for example when their cardholder doesn’t recognize the transaction on their credit card statement or they want more information about the transaction. A retrieval request can also be initiated by the issuing bank as part of a fraud investigation. An issuing bank is not obligated to raise a retrieval request, for the majority of chargeback reason codes the issuing bank is allowed to raise a direct chargeback. For example, if the issuing bank is convinced that the transaction is fraudulent, you will not receive a retrieval request but you will rather receive an immediate chargeback. It is ultimately the cardholder/issuing bank who decides if the provided information is sufficient or not. If the cardholder/issuing bank decides that the information provided is not sufficient, a chargeback may still be initiated. Ingenico ePayments sends all the retrieval requests via email. The email address used is the email address provided during your Full Service on-boarding (administrative/technical contact person) and can be changed at any time. You can add as many email addresses as you want; however, the email addresses are configured per entity (TMID) and not per PSPID (if you have several PSPIDs, you cannot add different email addresses depending on the PSPID). It is crucial to always reply to the retrieval request on time as failure to respond will result in the loss of representment rights. In other words, a Merchant will have no rights to represent a possible chargeback if no response to the retrieval request has been received from your side. 4.3.1 Retrieval request process flow As depicted in the below process flow, a retrieval request will complete a full circle. It is initiated by the cardholder/issuing bank and ultimately, the response provided by the Merchant will be presented to the cardholder/issuing bank. Page 8 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management
It is therefore important to provide the response in the following format:
English
Legible
Professional look & feel
Structured & organized format
4.3.2 Example retrieval request
Below is an example of a Retrieval Request that is provided by Ingenico ePayments via email:
Ingenico Fin. Sol.
Dispute.management@ecom.ingenico.com
Reason code Retrieval request Code 6321
Reason description MasterCard Retrieval Request – Transaction not recognized
Department Dispute Management
Dear Sir, Madam,
Ingenico E-Payments Services has received a Retrieval Request from a credit card issuing bank concerning a transaction that was
processed on behalf of your company.
We kindly request your company to provide us a copy of the electronic transaction receipt and relevant order information as soon
as possible by replying via email to dispute.management@ecom.ingenico.com.
As agreed upon in your merchant agreement with the Acquiring Bank, your company is eligible for disputes made by the
cardholder and/or the issuing bank of the cardholder. In case our acquirer does not receive the copy of the receipt within 14 days
of this letter, a potential chargeback may apply and this amount may be debited from your merchant account.
Please return all relevant documentation to support this charge and the transaction details together with this e-mail.
May we kindly request for the next supporting documents:
Company description (brief)
Copy of the invoice (with unaltered TID) and copy of the order
Customer details (shipping-/billing-/email-/IP- address included)
If applicable, refund details
If applicable, airline flight information
Page 9 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsDispute Management
Any documentation that can make the transaction identifiable
It concerns the following transaction:
Merchant ID
Credit Card Number
Transaction Amount
Transaction Date
Acquirer Reference Number
PayId
Retrieval Request Reason code Mastercard code 6342
PSPID
If a refund was processed for this charge, or when you decide to refund this charge, please also let us know and forward us the
details of this refund so we can inform the Issuing Bank accordingly and prevent a possible chargeback. If you decide not to
respond, please note that you will have no more representment rights if a chargeback occurs.
Remember to store all documentation for this purpose for at least 18 months as per your merchant agreement.
In case you might have any questions, please contact Ingenico ePayments by e-mail:
Dispute.Management@ecom.ingenico.com
With kind regards,
5.3.2.1 How do I locate the transaction in the Ingenico Back Office ?
In the Retrieval Request email you will find the PayID –the payment reference. With that PayID, you will be able to find the transaction back
in your Back-Office, under Operations > View transactions.
Retrieval request Ingenico Back Office
PayID -ex. 3342783111/0 PayID -ex. 3342783111/0
Page 10 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsDispute Management 5.3.2.2 Where do I find the retrieval reason code? In the Retrieval Request email there is a ‘retrieval reason code’. 4.3.3 Time-frame retrieval request When a Retrieval Request has been received, the Merchant has 14 calendar days in which a response must be given. If after 7 calendar days no response has been received by Ingenico ePayments a reminder will be sent out. If no response is received after 14 calendar days, Ingenico ePayments will automatically close the case. In order to ensure that Ingenico ePayments is able to produce a timely fulfilment of the Retrieval Request, please respond within 14 calendar days. If a response is received after the initial 14 calendar day deadline, Ingenico ePayments cannot guarantee that the fulfilment will be processed on time to the issuing bank. The deadline is there to ensure the response is processed and provided back to the issuing bank on time, failure to respond on time may result in a chargeback. Ingenico ePayments will have no further representment rights against such a chargeback. 4.3.4 Required information When responding to a Retrieval Request you must present several different types of information, depending on the claim of the cardholder and of course if the information is available. Ingenico ePayments has developed the below template that can be used as a standard. Merchant name Merchant trading name (if different) Page 11 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management Merchant clearing name (descriptor) Refund If YES please provide date, currency and amount of the refund If YES, no further information is required Transaction date Transaction amount and currency Truncated card number Expiry date Authorization code AVS / CAVV 3D Secure authentication If YES please provide the ECI code Brief description of the goods or services Cardholder name Cardholder address and billing address Cardholder phone number Cardholder email-address Cardholder date of birth Cardholder IP-address Cardholder history (mention previous successful transactions: date, amount and currency only) Page 12 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management
KYC information/documentation
drivers licence /passport number
At this stage this is the only information that is required and it is often better to stick to the minimum requirements in order to
give the Issuing bank the least chances of raising a chargeback afterwards.
4.3.5 How should the information be presented
In order to ensure that the information can be processed efficiently and the quality of the documentation is as high as it can
be, the recommendation is to provide the information in the following format:
Arial 11 bold, spacing 2.0
Avoid colorful pictures and print screens as much as possible
Black & White
English
Legible
On time
Structured & organized format
The best quality possible
Word document
3 page limit
4.3.6 Refunding the transaction
If you receive a Retrieval Request and you decide to refund the cardholder please always make sure to respond to the Retrieval
Request stating that you will or already have refunded the cardholder (include refund details).
If you decide to refund the transaction after receiving a Retrieval Request and you do not notify Ingenico ePayments of this,
you do not only lose the representment rights but you also run the risk of not being able to recover the refund if a chargeback is
reported in the future. The acquiring and issuing bank are strict regarding this and therefore you must always reply to any
Retrieval Request and provide details of the refund.
A refund always needs to be initiated on the same transaction as the original sale for the refund to be visible for the issuing
bank. If a refund is initiated on a different transaction or credit card number, the issuing bank cannot locate the refund and will
thus assume no refund took place and proceed with the chargeback procedure. Therefore, it is vital to always initiate the refund
on the same transaction and credit card number.
Important:
Under no circumstances should you refund via a different payment method; for example bank transfer or cash. The
issuing bank will not be able to see this refund on the cardholders account and will proceed with the chargeback. The
issuing bank will not accept any representment if a refund is not processed on the credit card.
4.3.7 How to refund via the Ingenico Back-Office
The Retrieval Request will contain all the details needed to locate the transaction in the Ingenico Back-Office:
1. Look up the transaction you want to refund via the "Operation > View transactions" and enter in the transaction details
2. Click on the “Refund” button which is displayed at the bottom of the " View transactions" tab. You can also log a reason for
the refund.
More information about Refunds can be found on our Ingenico Support page : https://payment-services.ingenico.com/int/en/ogone/support
/guides/user%20guides/collect/refunds.
Page 13 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsDispute Management 4.3.8 What is the Acquiring Reference Number An acquiring reference number, known simply as ARN, is a unique tracking number that is included in the transaction details of a refund on a credit card transaction. Unfortunately it can sometimes occur that a refund is not processed correctly by the acquiring or issuing bank or is not credited to the cardholders account for another reason. If this occurs the ARN can be used by the issuing bank to locate the refund. An ARN can also be used to represent a chargeback to prove that a transaction has previously been refunded; for example when the issuing bank states they cannot see the refund in their internal systems. The ARN number will always be mentioned in the RFI email. 4.4 Chargeback notification A notification of chargeback is already a chargeback; however there is no financial impact on your account yet. The debit is withheld by the acquiring bank and they first offer the opportunity to represent the chargeback by responding to the notification of chargeback. If no response is given to the notification of chargeback or the response and supporting documents are found to be insufficient the debit is applied to your account. Ingenico ePayments sends all the notifications of chargeback via email. The email address used is the email address provided during your Collect on-boarding (administrative/technical contact person) and can be changed at any time. You can add as many email addresses as you want; however, the email addresses are configured at entity level (TMID) and not at PSPID level (consequently if you have several PSPIDs, you cannot add different email addresses per PSPID). It is important to realize that a notification of chargeback is the only opportunity to represent the chargeback. Once a debit has been reported in your Ingenico Back-Office and a notification of chargeback has previously been sent there are no representment rights from that point; the issuing bank will not accept any representment. It is crucial not to initiate a refund on the notification of chargeback as you will run the risk of losing the funds twice; the refund & chargeback. If you do initiate a refund Ingenico ePayments has no representment rights to recover the funds. 4.4.1 Chargeback notification process flow As depicted in the below process flow, a notification of chargeback will complete a full circle. It is initiated by the issuing bank and ultimately, the response provided by the Merchant will be presented to the cardholder and/or issuing bank. It is therefore important to provide the response in the following format: English Legible Professional look & feel Structured & organized format Page 14 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management
4.4.2 Example notification of chargeback
Below is an example of a Notification of Chargeback that is provided by Ingenico ePayments via email:
Ingenico Fin. Sol.
Dispute.Management@ecom.ingenico.com
Reason code Visa Reason Code 53
Reason description Not as Described or Defective Merchandise
Department Dispute Management
Dear Sir, Madam,
Ingenico ePayments has received a Chargeback from the credit card issuing bank concerning a transaction that was
processed on behalf of your company. The issuing bank has certified that the requested services were not provided or
received.
The cardholder contacted their issuer to dispute a transaction where the merchandise or services received did not match what
was described on the transaction receipt or through other documentation presented by the merchant at the time of purchase.
We kindly request your company to provide us a copy of the order information within 14 days of receiving this letter,
preferably by email or a proof that cardholder has tried to contact you to return the merchandise or solve the dispute directly
with you.
It concerns the following transaction:
Merchant Id
Credit Card Number
Transaction Amount
Transaction Date
Acquirer Reference Number
PayID
Chargeback code Visa code 53
If a refund was processed for this charge, please let us know and forward us the details of this refund so we can inform the
Issuing Bank accordingly and reverse the chargeback. Be aware that the refund has to be processed on the same credit card
number to be eligible for a Chargeback reversal.
Under no circumstances process a refund once this chargeback has been received.
In case you might have any questions, please contact Ingenico ePayments by e-mail:
Page 15 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsDispute Management dispute.Management@ecom.ingenico.com. With Kind regards, 5.4.2.1 How do I locate the transaction in the Ingenico Back-Office In the notification of chargeback email you will find the PayID –the payment reference. With that PayID, you will be able to find the transaction back in your Back-Office, under Operations > View transactions. 5.4.2.1 Where do I find the chargeback reason code? In the notification of chargeback email there is a ‘chargeback reason code’ and/or description of the reason code. In the chargeback reason code Guide there is an overview of all the different chargeback reason codes. 4.5 Time-frame notification of chargeback When a notification of chargeback has been received, the Merchant has 14 calendar days in which a response must be given. The deadline is there to ensure the response is processed and provided back to the issuing bank on time, failure to respond on time will result in a debit to your account. Ingenico ePayments will have no further representment rights against the chargeback. Please note that there can be as much as 60 calendar days or more between the moment you receive a notification of chargeback and the reporting of the chargeback in the reconciliation module of Ingenico Back Office when the case has been lost. Ingenico ePayments recommends to monitor the transaction in question for up to two to three months after the notification of chargeback has been received, to determine if the chargeback is debited or not. 4.6 Required information Page 16 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management When responding to a notification of chargeback you must present several different types of information, depending on the claim of the cardholder. Ingenico ePayments has developed the below template that can be used as a standard response. Section 1: basic details Merchant name Merchant trading name (if different) Merchant clearing name (descriptor) Refund If YES please provide date, currency and amount of the refund If YES, no further information is required Transaction date Transaction amount and currency Truncated card number Expiry date Authorization code AVS / CAVV 3D Secure authentication If YES please provide the ECI code Brief description of the goods or services Cardholder name Cardholder address and billing address Cardholder phone number Cardholder email-address Cardholder date of birth Cardholder IP-address Page 17 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management Cardholder history (mention previous successful transactions: date, amount and currency only) KYC information/documentation drivers licence /passport number Section 2: supporting details (examples): Airline itinerary Evidence the passenger (cardholder) checked in at the gate and presented a valid passport Terms & Conditions: only include the relevant sections and leave out the rest. The T&C only need to be included for service related complaints such as reason code ‘service not provided’ or ‘credit not processed’. Proof that the cardholder accepted the Terms & Conditions Evidence that the cardholder used the goods or services Log files (online gaming) Log files (online FX trading) Signed proof of delivery (retail) Signature on receipt (hotel) Business relationship with the cardholder: previous successful transactions that have not been chargebacked (for fraud chargeback reason codes only If prior to the notification of chargeback you have received a retrieval request, you must present new evidence for the notification of chargeback otherwise the case can never be successful. After all, the issuing bank has already seen the old evidence during the retrieval request stage and determined that it was not sufficient. 4.7 How should the information be presented In order to ensure that the information can be processed efficiently and the quality of the documentation is as high as it can be, the recommendation is to provide the information in the following format: Arial 11 bold, spacing 2.0 Avoid colorful pictures and print screens as much as possible Black & White English Legible On time Structured & organized format The best quality possible Word document 10 page limit Page 18 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 5. Chargeback This section will outline the chargeback process at Ingenico ePayments, starting with the definition of a chargeback, process flow and reporting methods. 5.1 Chargeback definition Credit cards and debit cards do not offer a guaranteed form of payment for goods or services. Each transaction undertaken is subject to return by a card issuer even when authorization has been obtained. The process of returning a transaction unpaid is known as the chargeback process. The Card Schemes define the chargeback process, rules and regulations. Liability for a chargeback must be accepted unless it can be proven that the chargeback is invalid in accordance with Card Scheme rules, this process is known as a representment or dispute. The most common reasons for chargebacks include: Customer Disputes Fraud Processing Errors A cardholder always has the right to initiate a chargeback; the timeframe in which the cardholder has the opportunity to initiate a chargeback is dependent on the chargeback reason code. A separate guide is available with chargeback reason codes from the various Card Schemes. 5.2 Chargeback process flow As depicted in the below process flow, a chargeback will complete a full circle. It is initiated by the cardholder and/or issuing bank and ultimately, the response provided by the Merchant will be presented to the cardholder and/or issuing bank. It is therefore important to provide the response in the following format: English Legible Professional look & feel Structured & organized format Page 19 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 5.3 Chargeback reporting A chargeback is processed by Ingenico ePayments and will be reported to you by email. Every debit or credit is reported in the reconciliation module of your Ingenico Back-Office. If you have configured a push report, chargebacks will appear in the report once your account is debited for the chargeback. Page 20 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 5.3.1 How to retrieve the chargeback reason code The chargeback reason code will always be mentioned in the dispute letter we send you by e-mail. 5.4 Chargeback reversal If a representment has been successful, a chargeback reversal will be reported accordingly in the Reconciliation module of your Ingenico Back-Office as well as in the push reports. Go to Reconciliation > Dispute : Please note: cardholders have the right, in accordance to Card Scheme regulations, to come back on the chargeback if he/she upholds the claim; a second chargeback will be reported or sometimes a chargeback with reason code ‘pre-arbitration’. In case the Merchant also upholds their claim that the chargeback is invalid the Card Scheme will provide a final ruling (arbitration). The concept of (pre) arbitration will be discussed in further detail in chapter 8. 5.5 Chargeback monitoring programs Page 21 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management The Card Schemes monitor the performance of merchants in terms of the sales volume and the number of chargebacks generated. If the volume of chargebacks generated exceeds certain thresholds the merchants can potentially be penalized. For more information on this please contact your designated account and/or the dispute management team. Page 22 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 6. Dispute A dispute is an objection against the validity of a chargeback. A dispute can also be referred to as a representment. Once a representment has been received by Ingenico ePayments, the evidence will be gathered, reviewed and forwarded accordingly to the acquiring bank, who in turn will review and represent it to the issuing bank, provided the supporting documentation is sufficient. It is the issuing bank who decides if the evidence provided is sufficient to withdraw the chargeback or not; this entire process is governed by the Card Scheme rules and regulations. 6.1 Process flow representment As illustrated in the below process flow, a representment will complete a full circle. It is initiated by the Merchant and ultimately feedback on the outcome of a representment is provided back to the Merchant. Please note that Ingenico ePayments will not receive feedback from the issuing and acquiring banks on the outcome of all cases, therefore it can occur that a representment is lost but that no specific reason is given. 6.2 How to initiate a representment Once you receive a Dispute Letter, you will have the possibility to dispute the chargeback by providing requested evidences to the dispute management team via email: Dispute.management@ecom.ingenico.com. The evidences you will have to provide depend on the chargeback code, and will be mentioned in the dispute letter we send you. 6.2.1 Time-frame for representments From the moment a chargeback has been reported you have 14 calendar days to initiate a representment. If you fail to respond to a chargeback on time, the representment rights will be lost and Ingenico ePayments cannot defend the chargeback on your behalf. From the moment a representment has been processed by Ingenico it can take up to 45 days before a resolution is known. If after 45 days Ingenico ePayments did not receive any feedback from the issuing and acquiring bank the case will automatically expire. This means the representment has been lost. 6.3 Required information When responding to a chargeback you must present several different types of information, depending on the claim of the cardholder. Ingenico ePayments has developed the below template that can be used as a standard response. Section 1: basic details Page 23 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management Merchant name Merchant trading name (if different) Merchant clearing name (descriptor) Refund If YES please provide date, currency and amount of the refund If YES, no further information is required Transaction date Transaction amount and currency Truncated card number Expiry date Authorization code AVS / CAVV 3D Secure authentication If YES please provide the ECI code Brief description of the goods or services Cardholder name Cardholder address and billing address Cardholder phone number Cardholder email-address Cardholder date of birth Cardholder IP-address Page 24 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management Cardholder history (mention previous successful transactions: date, amount and currency only) KYC information/documentation drivers licence /passport number Section 2: supporting details (examples): Airline itinerary Evidence the passenger (cardholder) checked in at the gate and presented a valid passport Terms & Conditions: only include the relevant sections and leave out the rest. The T&C only need to be included for service related complaints such as reason code ‘service not provided’ or ‘credit not processed’. Proof that the cardholder accepted the Terms & Conditions Evidence that the cardholder used the goods or services Log files (online gaming) Log files (online FX trading) Signed proof of delivery (retail) Signature on receipt (hotel) Business relationship with the cardholder: previous successful transactions that have not been chargebacked (for fraud chargeback reason codes only) If prior to the chargeback you have received a retrieval request, you must present new evidence for the chargeback otherwise the case can never be successful. After all, the issuing bank has already seen the old evidence during the retrieval request stage and determined that it was not sufficient. 6.4 How should the information be presented In order to ensure that the information can be processed efficiently and the quality of the documentation is as high as it can be, the recommendation is to provide the information in the following format: Arial 11 bold, spacing 2.0 Avoid colorful pictures and print screens as much as possible Black & White English Legible On time Structured & organized format The best quality possible Word document 10 page limit It is important to avoid colorful pictures and print screens as much as possible because information is often faxed to and from the various banks. This means that by the time the information reaches the issuing bank it is no longer legible, see below a fictive example. 6.5 Auto-representment As part of the Dispute Management service package Ingenico ePayments Represents several chargebacks on behalf of the Merchants. The chargebacks Ingenico ePayments is able to automatically represent, are chargebacks that can be represented based on information in the Ingenico Back-Office : Ingenico ePayments automatically represents a chargeback if a refund has been previously applied on the same transaction. Important: Even though Ingenico ePayments has an auto-representment functionality in place, it is important to continue to monitor and respond to all reported chargebacks. 6.5.1 Auto-representment chargeback and refund Page 25 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management Ingenico ePayments automatically represents any chargeback for the full amount that has been reported if a refund for the full amount has previously been applied as well. The refund must be applied to the same credit card number and for the full paid amount. The refund must also be initiated prior to the chargeback being initiated by the cardholder in order for Ingenico ePayments to be able to automatically represent the chargeback. It is possible that the cardholder initiates a chargeback today while for example you have initiated a refund three days ago. Therefore, it is essential to communicate with your customer and manage their expectations accordingly as processing a refund may take anywhere from 3-8 business days. Important: Cases whereby a partial refund has been processed and a chargeback is received, will not be covered by the auto-representment service. In some cases you can receive a partial chargeback, perhaps due to a difference in exchange rates between the time of sale and the time the refund was initiated. A partial chargeback is not included in the auto-representment. 6.6 Dispute reporting You can have an overview of you chargebacks under the Dispute tab in the reconciliation module of your Ingenico Back-Office (month by month), via Reconciliation > Dispute : Page 26 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management
7. Arbitration chargeback
A pre-arbitration chargeback occurs when the first chargeback and representment failed to resolve the case. It is in essence one
[1]
Member saying to the opposite Member; please accept liability for this chargeback or we will go on arbitration with the Card
Schemes to get a final ruling on this case. If the issuing bank (on behalf of the cardholder) and acquiring bank (on behalf of
Ingenico ePayments /Merchant) cannot agree on the liability of a chargeback, an arbitration case can be filed with the Card
Scheme.
In case of an arbitration case both the acquiring and issuing bank present their supporting documents to the Card Scheme for a
definite ruling, which both parties are obligated to accept. However, the Card Schemes do not want to encourage arbitration
cases and they want the acquiring and issuing bank to resolve cases between themselves as much as possible. Therefore, high
fees are being charged by the Card Schemes if a case is brought to arbitration.
An issuing bank is typically only likely to initiate a (pre) arbitration case if they are very confident of the evidence at hand and
confident of a positive outcome. Filing for arbitration will never be successful if the provided supporting documents are the
same as for the first chargeback. Your representment will not be accepted unless you are able to provide new additional
evidence.
[1] A Member is the term used by the Card Schemes to indicate a bank that has obtained the license from the Card Schemes.
7.1 Representing a pre-arbitration chargeback
If a (pre) arbitration case is initiated by the issuing bank you can represent the case by sending an email to
dispute.management@ecom.ingenico.com.
It is important to realize that with the possibility of high fines, the issuing bank is unlikely to raise a (pre) arbitration case unless
they are confident they have a strong case and a very good chance of winning. Therefore, representing a (pre) arbitration case
with the same supporting documents as provided in the original Representment will not be attempted.
You will need to contact the Dispute Management team before attempting to represent a pre-arbitration chargeback, in order to
determine beforehand if the representment should be attempted or not.
7.2 Applicable fees for an arbitration case
The Card Schemes apply several fees for an arbitration case as outlined below.
MasterCard:
150 USD/EUR filing fee
250 USD/EUR administration
To be paid by the member that loses the case.
100 USD/EUR technical fee per violation against any Member found to have been in violation of the dispute processing
rules
Examples of violations of the dispute processing rules are:
Persisting with an invalid chargeback
Submitting an invalid second presentment
VISA:
Page 27 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsDispute Management 250 USD or 270 EUR filing fee 250 USD or 270 EUR review fee To be paid by the member that loses the case. Page 28 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 8. (Pre)-compliance chargeback Compliance chargebacks allow a Member that has no chargeback right to file a complaint against a Member for a violation of the Card Scheme regulations. The Card Schemes want the acquiring and issuing bank to resolve cases amongst themselves as much as possible before attempting a compliancy case. Before filing for compliancy the Member must attempt a pre-compliancy with the opposing Member. 8.1 Initiating a pre-compliance case If any of the Card Scheme regulations are broken the acquiring bank could raise a pre-compliancy against the issuing bank on behalf of Ingenico ePayments. 8.2 Applicable fees for a compliance case The Card Schemes apply several fees for a compliance case as outlined below. MasterCard 150 USD/EUR filing fee 250 USD/EUR administration fee To be paid by the Member that loses the case. VISA 250 USD or 270 EUR filing fee 250 USD or 270 EUR review fee To be paid by the Member that loses the case. Page 29 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 9. Good faith request A good faith request is an extra service that is being offered by Ingenico ePayments in case of extraordinary circumstances and as a manner of last resort. It is important to realize that it is not an official procedure and it is not part of the official channels. A good faith request is in essence nothing more than Ingenico ePayments using our well established contacts with the acquirer to request them to fight the chargeback again, outside the official procedure. It is important to realize that neither the acquiring nor issuing bank has any obligation to even reply to the request. If they do decide to accept the good faith request they are not obliged to neither inform us of this nor inform us of the outcome. The acquirer will forward the good faith request and after one month they will sent a reminder but if they do not receive a response they consider the case as lost. Therefore, as a general rule with good faith requests: ‘it is best to consider the case lost unless a credit is reported’. The acquiring banks reserve the right to charge a small fee for this good faith service, it will depend on the reason if this fee is applied or not. Generally good faith requests for small amounts will not be attempted by the acquiring bank because it will bring with it more costs than benefits and the chance of the issuing bank accepting the good faith request is very small. Page 30 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management
10. 3D Secure
3D Secure is an abbreviation for Three Domain Secure; which is the payment industry’s internet authentication standard
developed by two of the main Card Schemes. VISA has called it ‘Verified by VISA’ and MasterCard called their equivalent
‘MasterCard SecureCode’ . Both are often referred to as 3D Secure.
A successfully 3D Secure authenticated transaction will protect against fraud related chargeback reason codes.
An issuing bank is still authorized to raise a chargeback even if 3D Secure has been applied; it is the responsibility of the
merchant to representment the chargeback accordingly and provide the 3D Secure result.
Please note: this chapter covers and describes the basic conditions of the 3D Secure liability shift: there are exceptions,
limitations and specific conditions that determine which Member must assume the liability.
For more specific and detailed information about 3D Secure and its workings please contact your designated account manager.
10.1 3D Secure process flow
10.2 Liability shift conditions
The Electronic Commerce Indicator (ECI) indicates the level of security, in other words the result of the attempted 3D Secure
authorization.
ECI for ECI for
Description
VISA MasterCard
5 2 The cardholder is fully authenticated, 3D Secure applied
The Merchant attempted to authenticate but the issuer or
cardholder was non-participating, or an issuer access control
6 1
server was not able to respond in time (Merchant-
only-authentication).
The payment transaction was done on a secure channel
(Example: secure socket layer) but authentication did not
7 0 succeed. Or, the issuer responded that authentication could not
be performed for some reason. The transaction did not use 3D
Secure.
When the ECI results reflects 1 or 6 plus CAVV/AVV match or an ECI result of 2 or 5, you are protected against fraud related
chargebacks and the liability shifts to the issuing bank.
10.2.1 Chargeback reason codes covered by 3D Secure
A successfully 3D Secure authenticated transaction does not protect against all the chargeback reason codes, rather it only
Page 31 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsDispute Management
protects against the fraud related chargeback reason codes. The chargeback reason codes that are protected with 3D Secure
are:
Credit card Reason code Reason
VISA 75 Transaction not recognized
83 Fraud card absent environment
MasterCard 37 No cardholder authorization
63 Cardholder does not recognize
10.2.2 3D Secure recurring order model
When using a recurring order model in combination with 3D Secure only the first payment attempt is 3D Secure authenticated
and the subsequent payment attempts (recurring charges) are not. Therefore, no liability shift applies for the recurring
transactions.
For more specifics on this, please contact your designated account or implementation manager.
10.2.3 Key benefits
In case of a fraud chargeback reason code the liability shifts to the card issuing bank (if the required ECI result is obtained at
authentication).
Enhance trust and confidence for your customer’s online shopping experience
Additional layer of protection against fraud
Especially valuable for high transaction amounts
10.2.4 Limitations
US issuing banks do no participate in 3D Secure
A chargeback reason other than fraud can still be raised by the card issuing bank.
Does not apply for recurring transactions
Does not apply for non-European business/corporate cards[1]
[1] As of April 2014 MasterCard will allow business/corporate cards to fall under the protection of 3D Secure.
Page 32 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsDispute Management 11. Contact details and merchant questions For any questions related to the dispute management process itself or the outcome of a case, please contact the dispute management team via: : Dispute.management@ecom.ingenico.com. Page 33 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management 12. Fraud detection module Ingenico ePayments offers Merchants the opportunity to use Ingenico ePayments Fraud Detection Module to assist in preventing fraud in the card not present environment. Fraud Detection Module offers various tools that are designed to detect possible fraudulent transactions and stop fraud before it happens. Some of the key benefits: Leveraging the power of proven rules-based alarms (semi-automated). Empowering and accomplishing your internal controls. Offering an additional layer of protection to detect and prevent fraud. Offering real-time blacklisting/white-listing functionality. Benefiting from extensive negative database screening. Opportunity to create and modify ‘fraud rules’. Benefiting from extensive in-depth knowledge and best practices and Specific industry expertise. Benefiting from longstanding relationships with schemes and strategic fraud management partners. Equipped to deal with regional fraud trends For any questions please contact your dedicated account manager. Page 34 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePayments
Dispute Management
13. Glossary
This chapter aims to provide clarity to frequently used terms in this guide, if there are any terms that are not covered, please reach out to
Dispute Management via the contact details in Chapter 12.
Description
Term
Acquiring bank The bank that has processed the payment to the issuing bank
Cardholder The person who’s credit card account is registered at the issuing bank
Card Scheme The Credit Card Company
Environment where the physical credit card is not present
Card Not Present environment
during the time of sale
Chargeback The reversal of a sale
Customer The person who has made a purchase at the Merchants website
Dispute A representment of a chargeback case back to the issuing bank
Type of industry where buying and selling of product or service
E-commerce is conducted over electronic systems such as
the Internet and other computer networks
Issuing bank The bank that issued the Credit Card to the cardholder
Merchant You, a Merchant of Ingenico ePayments
A notification that a chargeback has been raised by the
Notification of Chargeback
issuing bank for a particular transaction
A pre-arbitration case is in essence one Member saying
to the opposite Member; please accept liability for this
Pre-arbitration Chargeback
chargeback or we will go on arbitration with the
Card Schemes to get a final ruling from them
A compliance chargebacks allow a Member that
Pre-compliance Chargeback has no chargeback right to file a complaint against
a Member for a violation of the Card Scheme regulations
Page 35 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsDispute Management
Representment A case objecting to the chargeback, official term for dispute
A retrieval request about the transaction in question
Retrieval request
Retrieval Request Official term for a Retrieval request
Supporting documentation The documentation that is used to support a dispute
Gateway The online web portal
Page 36 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsDispute Management
14. Disclaimer and Document Administration
Disclaimer
The content of this document is mostly based on the procedures of third parties and is provided by Ingenico ePayments as a courtesy for
general informational purposes only. This guide does not give any guarantee on the outcome of the representment process. This document is
subject to change at any time and is not intended to be the leading source for all rules, policies and procedures applicable to the subject
matter hereof. Ingenico ePayments shall under no circumstances be responsible or liable to a Merchant for any inaccurate, incomplete and/or
outdated information contained in this document, not for any costs, losses and/or damages arising out of a representment.
Document Administration
Document History
Release Date Name Change ID Changes
V.01 2016 Dispute Management 1 First edition
PCI-DSS Compliancy
Ingenico ePayments is fully PCI DSS 3.2 compliant as a Level 1 Service Provider, which is the key security standard within the payments
industry. The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for all organizations that accept
credit cards, that Ingenico ePayments must adhere to at all times.
Ingenico ePayments is strongly committed to helping you protect your sensitive data and the data of your customers. Sending complete
credit card details in clear text is dangerous and could jeopardize Ingenico ePaymentss’ PCI-DSS compliance and the card number(s) could be
intercepted and compromised.
We gently remind you that card details should be sent truncated, with only the first 6 and last 4 digits of the card number
legible (e.g. 375300xxxxxx0569). Other information like CVV should never be sent via e-mail. Ingenico ePayments will never
request the card number in full or the CVV.
For more information about PCI-DSS Compliancy please contact your designated Account Manager.
Page 37 of 37 - 11/03/2019 Copyright © 2019 Ingenico ePaymentsYou can also read
