Card Network Rules Certification

As a partner platform to WePay, you must ensure compliance with card network rules using this guide.

Methods of Payment

Ensure that all methods of payment are supported according to payment provider rules.

By default, WePay supports the following methods of payment (MoP) for merchants in the US and Canada through credit card iFrames and the WePay Helper JS tokenization:

* In compliance with American Express rules, WePay does not allow certain travel and telecom merchants to accept Amex cards. In those specific cases, platforms may be required to disable Amex acceptance for that merchant.

Card Present Methods of Payment

Note that China Union Pay is a supported method of payment for Card Present transactions, and will be bundled with Discover transactions in any reporting.

Displaying card payment marks

• Payment marks for all supported card brands (Visa, MasterCard, American Express, Discover) must be displayed at the point where a consumer/payer is asked to select a method of payment during checkout.
  • For checkout flows using credit card iFrames, display the card brand marks in your checkout UI just prior to calling creditCard.tokenize.
  • For checkout flows using the WePay Helper JS or server to server calls to tokenize, display the card brand marks in your checkout UI just prior to sending the POST /payment_methods request.
• Displaying the card acceptance marks on the merchant's home page is recommended.
• All marks must be displayed at parity; all card network marks must be displayed with equal prominence, frequency, size and color treatment.
• Refer to the official brand guidelines for each card network for any further requirements:
  • AMEX Electronic Logo Usage Guidelines (guidelines are included with each download)
  • Discover Network Acceptance Mark Guidelines
  • MasterCard - How to Use Our Brands
  • Visa - POS Guide

Below is an example of display marks:

An example display of card brands which must be included on checkout pages

Card on File Requirements

A merchant or Digital Wallet Operator (DWO) that processes Partial Payments, Advance Payments, and Transactions using a Stored Credential must comply with Table 1, General Requirements for Partial Payments, Advance Payments, and Transactions using Stored Credentials and as applicable, Table 2, Transaction-Specific Requirements for Partial Payments, Advance Payments, and Transactions Using Stored Credentials.

These requirements do not apply to the following when the Merchant or DWO uses the Stored Credential for a single Transaction or a single purchase:

• A No-Show Transaction
• A Transaction involving an amended amount or a delayed charge
• A Transaction involving and Incremental Authorization
• A Transaction where the Merchant or DWO is allowed to submit a new Authorization Request for the same Transaction

Table 1: General Requirements for Partial Payments, Advance Payments, and Transactions Using Stored Credentials

Table 2: Transaction-Specific Requirements for Partial Payments, Advance Payments, and Transactions Using Stored Credentials

Additionally, a Merchant that processes Transactions using a Stored credential (except a Stored Credential used in a Pass-Through Digital Wallet in a Card-Present Environment) must comply with Table 3, Processing Requirements for Transactions Using Stored Credentials.

Table 3: Processing Requirements for Transactions Using Stored Credentials

Transaction Receipts

Merchants/platforms must provide transaction receipts in either electronic or paper format at the time of transaction. Card network rules require that:

• Merchants must provide receipt if requested by customer (in other words cardholders should be presented with the option to get a receipt).
• Receipt must be provided if merchant has return, refund or exchange policy, or requires receipt for return or refund.
• Receipt can be paper or electronic. However merchant must provide paper receipt if paper receipt requested by customer unless transaction is ecommerce or at contactless-only POS device.
• A merchant must retain a transaction receipt for 13 months.

For Link, WePay delivers electronic receipts.

Clear partners must adhere to the following receipt protocols:

1. If WePay is not sending end user emails on your behlaf, inform the payer of transaction receipt delivery method (i.e. email, text message, etc) and when it will be sent. Read more about required notifications that you, the platform, must deliver in our Send End User Emails article.
2. Provide the receipt in a static format that cannot easily be manipulated after it has been created.
3. If a link to the receipt is provided, outline clear instructions for accessing the receipt, as appropriate.
4. Make the receipt available to the cardholder for at least 24 hours after the transaction.
5. Not store or use personal information provided by the cardholder to receive a receipt (such as email address or phone number) without the express consent of the cardholder.
6. Include the following in the title of the email or first line of the text message:

• the merchant name
• language indicating that the email or text message contains the transaction receipt or a link to the transaction receipt.

A merchant/platform must retain a transaction receipt for 13 months.

Transaction Receipt Data Requirements

For Card Not Present transactions (i.e. eCommerce), the following data points must be included on receipts:

1. Merchant name or DBA (or merchant website)
2. Merchant location: address, city, country, phone number
3. Transaction type (retail sale, cash disbursement, refund)
4. Descriptions (and price) of goods and services
5. Total amount
6. Transaction date (and time if possible)
7. For recurring transactions: the words “Recurring Transactions”, frequency of recurring transactions, duration of recurring transaction period
8. Card network name
9. PAN (in truncated form)
10. Transaction authorization approval code returned by issuer
11. Refund and return policies
12. Customer service contact information such as email address or phone number

• Recommended to reduce the likelihood of cardholder dispute/chargeback:
  • For merchants located in the US: “This charge will appear on your credit card statement as WPY*description.”
  • For merchants located in Canada: "This charge will appear on your credit card statement as description."

Card Present Receipts

In addition to the above receipt protocols (not to be confused with data requirements), card present receipts also require that:

• Merchants must provide receipt if requested by the customer (in other words cardholders should be presented with the option to get a receipt)
• A receipt must be provided if merchant has return, refund or exchange policy, or requires receipt for return or refund.
• Receipts can be paper or electronic
• Merchants must provide paper receipt if paper receipt requested by customer unless transaction is ecommerce or at contactless-only POS device.

See our article for Card Present receipts for technical implementation guidance.

The following data points must be included on Card present receipts:

1. Merchant name
2. Merchant Location (city & state/province)
3. Merchant Number (must NOT be on Debit Receipts)

• Omitting the merchant number from the receipt for US merchants is optional

4. Transaction Type (abbreviation allowed)

• Purchase or Sale; Credit, Refund or Return; Prior Sale or Voice Authorization; Void; Reversal; Incremental Authorization; etc.

5. Local date and time
6. Entry Mode

• Swipe, chip, NFC, etc.

7. Card Issuer Name / Card Brand Name OR Payment method (debit vs. credit)

• Discover and Visa must appear in full on the receipt; all other payment brand names may be abbreviated

8. Card Type

• Always print "CREDIT"

9. Masked PAN
10. Truncated Expiration Date

• Must be omitted or fully truncated (XXXX or **)

11. Total Amount

• If the transaction was partially-approved, the partially-approved amount must be presented on the receipt as the total transaction amount
• It may be helpful to print the request amount on the receipt if it differs from the total transaction amount

12. Approval or Authorization Code
13. Application ID

• Required on EMV only

14. Application Preferred Name

• Required on EMV only

To find out how to get these values from the Card Present SDK, see the Card Present Receipt article.

• Recommended to reduce the likelihood of cardholder dispute/chargeback:
  • For merchants located in the US: “This charge will appear on your credit card statement as WPY*description.”
  • For merchants located in Canada: "This charge will appear on your credit card statement as description."

Returns and Refunds

A merchant is responsible for establishing their merchandise return and refund or cancellation policies. Clear disclosure of these policies help in reducing cardholder disputes and chargebacks. Card networks require clear disclosure of these policies for them to be considered in cases of chargeback.

Examples of clear disclosure statements are:

• No refunds or returns or exchanges
• Exchange only
• In-store credit only

Special terms must be spelled out.

For internet or app purchases, merchant must communicate their refund and return policies on the transaction receipt. Additionally, the merchant website must communicate the refund policy to the cardholder either in the checkout flow with a “click to accept” or other acknowledgment, or on the checkout screen near the “submit” button.

For phone order, the merchant may send the disclosure by mail, email or text message after the transaction.

For face-to-face transactions, the cardholder must receive the disclosure at the time of purchase. For card-present transactions, disclosure statements should be legibly printed on the transaction receipt near the cardholder signature area or in an area easily seen by the cardholder.

Recurring Transactions

A recurring transaction can be set up for automatic periodic payments for subscriptions, memberships, bill payment, etc. Because recurring transactions are processed automatically and without direct participation of the cardholder, they are particularly liable to potential disputes by cardholders.

Card networks have specific requirements and recommendations to minimize disputes and to contest chargebacks in case of disputes:

• The merchant/platform must obtain consent of the cardholder of the following
  • Transaction amount (does not apply where transactions will be of varying amounts)
  • Frequency
  • Duration of billing arrangement
  • Acknowledgment of merchant's cancellation and refund policies
• The merchant/platform must retain the cardholder's consent in either written or electronic format in case of potential disputes of subsequent charges
• The merchant/platform must provide an online cancellation procedure for the cardholder
• The merchant/platform must not charge a recurring transaction beyond the duration expressly authorized by the cardholder
• Cancellation requests should be processed promptly (recommended at least on a daily basis) and the cardholder should be notified that the recurring transaction has been canceled, along with a confirmation number for the cancellation
• If a cancellation request is received too late to prevent the most recent recurring charge from being posted to the cardholder's account, submit a credit and notify the cardholder
• Transaction receipts should include the following information:
  • The phrase “recurring transaction”
  • The frequency of the charges
  • The period of time the cardholder has agreed to for the charges
• Notify the customer at least ten days in advance before each recurring payment. The advance notification should include the amount. If the amount exceeds a pre-authorized range, expressly include this information, as well.
• It is recommended that the card is enrolled in Account Updater to reduce declines due to updates to card numbers and card expiration date. Contact your Relationship Executive or API Support (api@wepay.com) for further information.
• For declined transactions, merchants should contact the cardholder for updated card information.

Opt Out of ACH and eCheck Payments

The NACHA rules mandate that payers who sign up for recurring or one-time bank debits must also have a way to opt out of them. For recurring debits, payers must be given 10 calendar day notice of change in amount or 7 calendar day notice of change in debit scheduling (for additional reference, see Subsection 2.3.2.6 Notices of Variable Debits to Consumer Accounts of the NACHA Operating Rules and Guidelines). For one-time debits scheduled in advance, payers must provide a reasonable amount of time for the originator to act (for additional reference, see Subsection 2.3.2.3 Form of Authorization of the NACHA Operating Rules and Guidelines). WePay recommends applications provide payers with notification and a 10 calendar day opt-out window for recurring and scheduled one-time payments. There are two ways to satisfy this requirement:

Payer Accounts

WePay strongly recommends that your application create an account for the payer if she or he wish to sign up for recurring payments. This is recommended because it provides payers with the easiest method of securely and repeatedly accessing your application to manage or opt out of recurring payments at her or his own discretion. Payers must be able to opt out of any scheduled payment 10 calendar days prior to debit payment.

Notifications

WePay permits your application to manage the payer opt out requirement via notifications instead of creating payer accounts. If your application intends to implement a subscription model (automatic recurring debits to payer bank accounts), your application must send a notice 10 calendar days in advance of the debit that includes:

• The date that the impending debit will occur
• The amount of the debit
• A link to your application so the payer can opt out of or manage the recurring payment

If your application intends to implement a bank-on-file model (your application stores the payment bank credentials, but the payer must approve each payment), your application still must include a way for the payer to opt out or manage the recurring payment. However, 10 days advanced notice is not required since the bank debit will not occur without the payer's consent.

Revoking Authorization and Recurring Debits

Revoking Authorization

2.3.2.3 Form of Authorization (c) provide that the Receiver may revoke the authorization only by notifying the Originator in the time and manner stated in the authorization.

For a Single Entry scheduled in advance, any such revocation right shall afford the Originator a reasonable opportunity to act on such revocation prior to the initiation of the Entry.

*Does not distinguish between single and recurring transactions.

Recurring Debits

Subsection 2.3.2.6 Notices of Variable Debits to Consumer Accounts

• 10 day notice required if change in the amount, unless within previously agreed range
• 7 day notice required if change in date of debit

Website Recommendations

It is recommended that following is included on merchant website (or platform website, if appropriate) to reduce cardholder disputes and potential chargebacks:

• Complete description of goods and services.
• Customer service contact information including email address or phone number
• Return, refund, and cancellation policy
• Delivery policies for goods or services, if applicable, including order fulfillment information such as time frames for order processing so that customers do not dispute a transaction on grounds of not receiving goods or services.
• If applicable, information on when credit cards are charged. For example, if cards are charged at a later date after merchandise is shipped.
• Merchant location, as well as country and export restrictions (if known or applicable)
• How the charge will appear on their card statement such as wpy*MerchantName. (Merchants should use a merchant name on their platform/WePay account that their customers will recognize.)
• A statement encouraging cardholders to retain a copy of the transaction receipt

Convenience Fees

When platforms are looking to charge payers/consumers fees, it must be done in compliance with state laws and card network rules.

WePay currently supports convenience fees, which are fees charged by platform for a bona fide convenience in the form of an alternative payment channel (such as online) that is outside the merchant's customary payment channels (i.e. mailing a check or paying in person). Convenience fees must not be charged solely for the acceptance of a card. Convenience fees are deducted from the merchant's portion of the transaction and collected by you, the platform.

Who can charge convenience fees?

Any platform using WePay's Link or Clear offering may implement convenience fees.

Merchants must meet the following eligibility requirements:

• Based in the United States
• Blended pricing (not on Merchant IC+)
• Processes both Card Present and Card not Present (must not process 100% Card Present transactions)
• MCC must indicate that the merchant provides goods or services
• Must not be registered with a Utility program (as defined by Visa rules)

Which transactions can convenience fees be applied to?

Convenience fees must be applied equally across all forms of payment in the payment channel (i.e. web checkout).

Transactions must meet the following criteria:

• Must not be a recurring or installment charge
• Must be a Card not Present transaction

How much should convenience fees be?

• Must be a flat or fixed amount regardless of the card brand (e.g Visa, MasterCard)
• No maximum fee amount is specified by card network rules, though the fee must be 'reasonable'. WePay recommends limiting fees to 1.5% of the final transaction amount for Debit, and 2.5% of the final transaction amount for Credit.

Are there other rules about how to charge a convenience fee?

• Card holders must be notified of the fee amount before the transaction takes place
• Card holders must be able to cancel the transaction after notice of fees
• Convenience fees must not be combined with surcharge fees (which WePay does not support)
• Convenience fees must not be charged by third parties

Discounts and other incentives

A platform should carefully evaluate any decision that disincentivizes paying with a credit card. Consumers/buyers faced with an additional fee or any other disincentive to use their credit card sometimes abandon the transaction altogether. Merchants wishing to avoid credit card processing fees can offer discounts to payers for using alternate methods of payment. Merchants can also offer non-monetary incentive to use alternate payment methods.

Find out how to implement convenience fees here.

Property Rental Surcharge Fees

Merchant requirements:

• Merchant must be on blended pricing
• Merchant must be based in the United States (rent surcharge is not supported in Canada)
• Merchant must have MCC 6513
• Merchant must be registered with Visa

Transaction requirements:

• Method of payment must be one of credit or debit
• Transaction must be card not present (i.e. web transaction)

Fee Requirements:

• The surcharge fees must be disclosed to the payer at time of payment
• Payer must be able to opt out of the transaction
• Rent amount and surcharge fees must be processed as a single transaction and completed as a purchase
• Maximum fee amount for credit cards must not exceed 4%
• Maximum fee amount for debit cards must not exceed $10.00 USD

Transaction requirements:

• Method of payment must be credit
• Transaction must be card not present (i.e. web transaction)

Fee Requirements:

• The surcharge fees must be disclosed to the payer at time of payment
• Payer must be able to opt out of the transaction
• Rent amount and surcharge fees must be processed as a single transaction and completed as a purchase
• Maximum fee amount for credit cards must not exceed 4%

AVS

AVS (address verification service) is a service offered by card networks to verify card holder address. Along with other cardholder information, this is used to authorize a transaction. In AVS, when cardholder address is included in the authorization request message, the issuer provides a 'match' or 'no match' response in the authorization response using the cardholder address in their records.

WePay requires AVS because there are a number of uses for it:

• AVS is a useful fraud protection tool in case of lost or stolen cards.
• AVS-match gives issuer greater confidence and authorization declines are reduced.
• AVS helps merchants to win chargebacks. For card-not-present/ecommerce transactions, when goods are delivered to the same address for which an AVS match was received, it is considered a compelling evidence to reverse a chargeback.
• Certain transactions without AVS are downgraded by card networks, which increases the processing cost on those transactions.

WePay automatically handles AVS checks on your behalf, which is part of why we require address information for card/account holders.

CVV

CVV (card verification value) is the three-digit security code on the card. CVV is used during authorization in ecommerce transactions to verify that the payer is in possession of the card. CVV is a catch-all term for CVV2 (Visa and Mastercard) and CID (Amex and Discover). When CVV is included in the authorization request message, the issuer provides a 'match' or 'no match' response in the authorization response.

Unlike AVS, CVV cannot be stored by the merchant or any payment processor, per card network rules.

In Canada, CVV is mandatory for ecommerce transactions, except for transactions using stored credentials.

WePay requires CVV when a card is used for the first time because:

• CVV is a useful fraud protection tool in case of lost or stolen cards.
• CVV-match gives issuer greater confidence and authorization declines are reduced.

In order to avoid storing CVV, WePay highly recommends either using credit card iFrames or the WePay Helper JS for tokenization.

Visa CVV2

Visa requires Canadian merchants to capture and pass Card Verification Value 2 (CVV2) in all card-not-present (CNP) transactions. There are a few exemptions to this mandate:

• Recurring transactions (after the card has already been used for a payment with CVV2)
• Card on File transactions (after the card has already been used for a payment with CVV2)
• Credit Card transfers
• Digital Wallets (Apple Pay, Google Pay)

WePay will deny a transaction if:

• cvv_provided is false AND
• this a Canadian Merchant AND
• the transaction does not fall under one of the exemptions listed above

The API will return the following response:

{
    "error_code": "TRANSACTION_DECLINED",
    "error_message": "The transaction was declined by the issuing bank.",
    "details": [
      {
      "message": "CVV is required for this transaction.",
      "reason_code": "CVV_REQUIRED",
      "target": ["payment method"],
      "target_type": "HTTP_REQUEST_BODY"
    }
    ]
}

Canadian Payment Processing

If you process payments in Canada, be sure to consult the section below to handle specific scenarios.

Handle Canadian Debit Cards

"incoming_payments": {
	"opted_out_methods": {
		"countries": {
		  "CA": {
			  "debit_cards":true
		  }
		}
	}
}

If this call is successful, you will observe the following in the response:

"opted_out_methods": {
	"countries" : {
		"CA" : {
			"debit_cards": true
		}
	}
}

Canadian FCAC Requirements

The Canadian regulator FCAC requires card networks to ensure that acquirers (such as Chase) and their agents (such as WePay and our platform partners) who provide payment services to merchants, comply with the Code of Conduct.

Please find specifics on compliance in our Platform Legal Obligations article, under the Canada Fee Disclosure section.