Last update 20/04/2017

1. 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.

2. 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

3. 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.

3.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 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.

4. 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

5. Dispute Management process

5.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.


5.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.

5.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.

5.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.

It is therefore important to provide the response in the following format:

  • English
  • Legible
  • Professional look & feel
  • Structured & organized format

5.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

  • 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



5.3.2.2 Where do I find the retrieval reason code?

In the Retrieval Request email there is a ‘retrieval reason code’.


5.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.



5.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)
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)

 

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.

5.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

5.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.

5.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.

5.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.

5.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.

5.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

5.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: 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.

5.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.

5.6 Required information

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

5.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

 

6. Chargeback

This section will outline the chargeback process at Ingenico ePayments, starting with the definition of a chargeback, process flow and reporting methods.

6.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.

6.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

6.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.

6.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.

6.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.

6.5 Chargeback monitoring programs

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.

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

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

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

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

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

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

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

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

7.5.1 Auto-representment chargeback and refund

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.

7.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 :

8. Arbitration chargeback

A pre-arbitration chargeback occurs when the first chargeback and representment failed to resolve the case. It is in essence one Member[1] 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.

8.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.

8.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:

  • 250 USD or 270 EUR filing fee
  • 250 USD or 270 EUR review fee

To be paid by the member that loses the case.


9. (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.

9.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.

9.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.

10. 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.

11. 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.

11.1 3D Secure process flow

11.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 VISA

ECI for MasterCard

Description

5

2

The cardholder is fully authenticated, 3D Secure applied

6

1

The Merchant attempted to authenticate but the issuer or cardholder was non-participating, or an issuer access control server was not able to respond in time (Merchant-only-authentication).

7

0

The payment transaction was done on a secure channel (Example: secure socket layer) but authentication did not 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.

11.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 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

11.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.

11.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

11.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.

12. 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.

13. 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.

14. 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.

Term 

Description 

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
Card Not Present environment Environment where the physical credit card is not present

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
E-commerce Type of industry where buying and selling of product or service

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
Notification of Chargeback

A notification that a chargeback has been raised by the

issuing bank for a particular transaction

Pre-arbitration Chargeback A pre-arbitration case is in essence one 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 from them
Pre-compliance Chargeback A 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 
Representment A case objecting to the chargeback, official term for dispute
Retrieval request

A retrieval request about the transaction in question

Retrieval Request Official term for a Retrieval request
Supporting documentation The documentation that is used to support a dispute
Gateway The online web portal

This website uses cookies to be able to give you the best user experience. If you don't want to accept these cookies, we allow you to change the cookie settings. Click 'Accept' to allow all cookies from this website.

Cookie settings

Introduction

Functional

Functional cookies are required for the website to operate correctly. These cookies cannot be disabled.

Optimized

Optimization cookies allow us to analyze site usage so we can measure and improve our website.
This is the default level.

Personalized

Personalization cookies are used for social media and advanced personalization. They allow us to show you information related to your company.


Example functionality allowed

  • Store country preference
  • Store language preference

Example functionality not allowed

  • Saving personal data
  • Anonymous tracking via Google Analytics
  • Tracking for remarketing purposes

Example functionality allowed

  • Store country preference
  • Store language preference
  • Anonymous tracking via Google Analytics

Example functionality not allowed

  • Saving personal data
  • Tracking for remarketing purposes

Example functionality allowed

  • Store country preference
  • Store language preference
  • Anonymous tracking via Google Analytics
  • Serve content relevant to your interests
  • Serve ads relevant to your interests
  • Tracking for remarketing purposes

Example functionality not allowed

  • Saving personal data