The outline below provides a framework for structuring the Merchant’s evidence.
- Summarize the purpose of the transaction and provide relevant background information on the Merchant’s use case and industry.
- Demonstrate that the merchant conducted KYC properly on the Cardholder.
a. Collect the Cardholder’s full name exactly as it appears on the card (do NOT allow users to add a different name at the time of the transaction)
b. Collect the Cardholder’s date of birth
c. Collect the Cardholder’s full social security number (do not include the full social security number in the merchant evidence document)
i. Use a third-party service to verify the status of the SSN provided (do NOT allow users to open multiple accounts with the same KYC/KYB information). An account should not be opened if the SSN check results in any of the below outcomes:
- SSN invalid
- SSN belongs to deceased person
- SSN missing or incomplete
- SSN issued prior to date of birth
- SSN is on Alert List
- SSN associated with a name and address other than those of the customer
- SSN not primary SSN for entered identity
- Multiple SSNs reported on the same customer
- SSN was used by different customers in Merchant’s system
d. Collect the Cardholder’s phone number
i. Do not allow users to open multiple accounts with the same phone number
ii. Do not allow VoIP phone numbers
iii. Use a one-time passcode sent via text message to verify that the customer is in possession of the phone number provided.
iv. Use a third-party service to verify the following:
- The phone account is postpaid (not prepaid).
- The phone number is long-lived.
- The phone number is registered in the cardholder’s name.
- The phone number is registered to the cardholder’s address.
e. Collect the Cardholder’s email address
i. Do not allow users to open multiple accounts with the same email address
ii. Use a unique click-through link to verify that the customer has control of the email address provided.
iii. Use a third-party service to verify the following:
- The email account is long-lived.
- The email address corresponds to the customer’s name and identity in a third-party database.
f. Collect the Cardholder’s billing address
i. Use a third-party service to verify that the customer’s name relates to the customer’s billing address in a third-party database.
g. Authenticate cardholders using incremental data about the consumer and transaction environment. A user whose billing address corresponds to his or her physical location (established via geolocation) can be considered lower risk.
i. IP address at the time of transaction
ii. Device geographical location at the time of the transaction
iii. Device ID number and name of device (if applicable)
h. Device fingerprinting: use a combination of data points to identify unique devices
i. Look for location and device spoofing
i. Fraud scoring systems/third-party generated risk scores:
i. Limit instant transfers capability to users with low-risk profiles
- Demonstrate that the Merchant verified that their customer owned the card used to fund the account.
a. EMV 3-D Secure (3DS)
i. The Three-Domain Secure (3-D Secure or 3DS) Protocol helps to ensure that an e-commerce purchase is initiated by the rightful owner of a card.
ii. Merchants are not liable for fraud chargebacks when cardholders are authenticated through 3DS.
- In the US, the following MCCs are excluded from the chargeback liability shift: 4829, 5967, 6051, 7995, 6540, 7801, 7802
iii. 3DS cannot be used in conjunction with network tokens (Apple Pay)
b. Address Verification Service (AVS)
i. Address Verification Service (AVS) allows card-not-present (CNP) merchants to validate the cardholder’s address with the card issuer at the time of authorization. This information can be helpful in determining if the person using the card is actually the cardholder.
ii. If AVS is enabled TabaPay will return a response code from the issuer during the authorization process, indicating how closely the provided address matches with the billing address the issuer has on file for the cardholder.
iii. PULL transactions should not be completed without a full or partial billing address match.
iv. This AVS check should be run against the address provided by the user during the KYC/KYB stage—users should NOT be allowed to add a different billing address at the time of the transaction.
v. AVS currently works in English-speaking countries only.
i. CNP merchants use CVV2 to verify that the customer has a legitimate card in hand at the time of the transaction.
ii. If enabled, TabaPay will send the CVV provided to the issuer, and the issuer’s response code will indicate whether the CVV matches the information on file with the cardholder's bank.
d. Network Tokens (Apple Pay and Google Pay 3DS)
i. Merchants can opt to limit funding flows to only allow Apple Pay and Google Pay 3DS.
ii. Apple Pay and Google Pay for ecommerce operate as a speed bump in preventing fraud, but do not provide risk shift on chargebacks.
iii. The typical card registration process requires that the cardholder speak to his or her bank when adding the card to Apple Pay or Google Pay. The bank typically requests identifying information before the card can be added.
iv. Note: Google Pay provides both card number (PAN) and network token payments. Google Pay PAN offers no additional protection as the customer can type in one or more cards to an Android phone.
e. Allow cardholder to enter bank account credentials through a trusted third-party service (example: Plaid); use micro-deposits or similar method to verify that the customer is the owner of the bank account from which funds are transferred.
- Demonstrate that the Merchant implemented proper security tools for its program.
a. Duplicate card check
i. TabaPay’s Duplicate Card Check feature validates whether a card number is already in use across a merchant’s platform
ii. This feature prevents bad actors attempting to connect the same card to multiple accounts under different names from circumventing funding limits and velocity controls.
iii. Duplicate Card Check cannot be used in conjunction with network tokens (Apple/Google Pay)
b. Negative/positive databases
i. Negative databases: flag stolen card numbers to prevent future use; maintain a database of customers who have opened chargebacks inappropriately (friendly fraud).
ii. Positive database: maintain database of trusted, low-risk customers
c. Velocity checks (data element, quantity, time frame)
i. Look for the number of times a specific data element occurs within a given interval to identify patterns of suspicious activity
d. Implement account funding limits to mitigate potential damage
- Demonstrate that the Cardholder actively agreed to the Merchant’s terms of service/use prior to the transaction, including any applicable refund/cancellation policies.
a. Document the process by which the customer actively agreed to the terms of service.
b. Maintain a record of the text and any subsequent updates to the terms of service.
c. Maintain a publicly accessible link to the terms of service.
- Demonstrate that the merchant’s checkout process was not misleading, and that the cardholder clearly authorized the disputed transaction(s).
a. Summarize the steps the customer actively took to authorize the correct transaction amount, which may include all or a subset of the following (include screenshots of the process, if possible):
i. Cardholder’s choice of transaction amount
ii. Cardholder’s confirmation of transaction amount
iii. Immediate funds transfer confirmed
- Demonstrate account fulfillment/that the cardholder benefited from the service provided by the Merchant.
a. Record date and time customer’s account was credited
b. Email the customer a receipt that includes:
i. Cardholder name
ii. Dollar amount transferred
iii. Card scheme of the card used (Visa, MasterCard, etc.)
iv. Last four digits of the card used
v. Date the transaction was completed
vi. Refund policy
c. Record dates and times cardholder accessed Merchant’s website or application
- Document history of non-disputed payments with the cardholder.
a. Evidence that the same device and card used in the disputed transaction were used in any previous transaction that was not disputed
i. Purchaser’s IP address and the device geographical location at the date and time of the Transaction
ii. Device ID number and name of device
iii. Purchaser’s name and email address linked to the customer profile held by the Merchant
Updated about 2 months ago
Did this page help you?