Card Network Rules

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

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. 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 Platform Setup 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.”

To implement the above recommendation, fetch the statement_description value from the associated merchant account to insert as the “description.” For instance, if you have a merchant where "statement_description": "Joe's fundraiser", then the description that you should show payers on the receipt would be “WPY*Joe’s fundraiser” (payments to US-based merchants) or “Joe’s fundraiser” (payments to Canada-based merchants).

_{Reference: Visa Core Rules and Visa Product and Service Rules, April-2016}

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

To implement the above recommendation, fetch the statement_description value from the associated merchant account to insert as the “description.” For instance, if you have a merchant where "statement_description": "Joe's fundraiser", then the description that you should show payers on the receipt would be “WPY*Joe’s fundraiser” (payments to US-based merchants) or “Joe’s fundraiser” (payments to Canada-based merchants).

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.

_{Reference: Card Acceptance Guidelines for Visa Merchants, Visa, 2015}

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.

_{Reference: Card Acceptance Guidelines for Visa Merchants, Visa, 2015}

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

Surcharge and Convenience Fees

When platforms are looking to add payment fees to payers/consumers, do so in compliance with state laws and card network rules.

Surcharge is a fee assessed to a cardholder that is added to the transaction amount for the acceptance of a credit card. Typically this is to cover the higher costs associated with accepting credit cards.

Surcharging is not common. Consumers/buyers do not like paying an additional fee to be able to pay with their credit card, and sometimes abandon the transaction. As a result, merchants typically don’t surcharge. Secondly, there are laws and card network rules governing surcharging, which makes it complex to implement from a legal and compliance point of view.

Consequently, WePay doesn’t recommend surcharging. That said, there might be cases where a platform chooses to support surcharging, especially where cardholders/payers prefer to have that choice. Examples are fundraising sites where donors choose to cover the cost of processing a credit card payment so that the beneficiary receives 100% of the donation amount; or building contractor who typically gets paid in checks with large dollar amounts, but may have clients who prefer to use a credit card and elect to do so and cover the card processing cost.

Geographic restrictions

Certain states have laws limiting or prohibiting surcharging. Merchants/payees located in these states may not be able to surcharge. Currently these states are ¹ :

• California
• Colorado
• Connecticut
• Florida
• Kansas
• Maine
• Massachusetts
• New York
• Oklahoma
• Texas
• Puerto Rico

(source: NCSL)

Partners should obtain their own legal counsel on this.

Card network rules prohibit surcharging in Canada. There are ongoing court cases challenging these rules but for now surcharging is not allowed in Canada.

¹ As of July 2019, three states’ laws (CA, FL, TX) were recently declared unconstitutional or deemed unenforceable.

Surcharging Rules

Similar Treatment
Visa and Mastercard require that surcharges not be applied selectively to certain card brands; surcharging must apply equally to all card brands. There are exceptions to this rule depending on special arrangements that a merchant may have with a card network. For exceptions to this rule, consult the Visa and Mastercard card network rules in detail.

Surcharges can be applied to all transactions or certain card products, but not both
Card products refer to certain types of premium cards.

Surcharging is only allowed on credit cards
Surcharges cannot be applied to debit or prepaid card transactions. A card’s BIN (the first 4 to 6 digits of the card number) can be used to determine the type of card. Tip: A successful response on a credit_card call will return the BIN. A platform would need to use a BIN lookup service to determine the card-type and whether surcharge fee can apply on that transaction.

Surcharge amount
The surcharge amount can be a fixed or variable amount and is capped by card networks. Visa states that surcharge fees cannot exceed the merchant’s credit card acceptance fees or 4%, whichever is lower. The 4% cap means that typically surcharges are a variable amount, such as 3%. A fixed amount, such as a flat fee of $3 for example, will exceed the 4% cap for transactions smaller than $75.

Disclosures
The surcharge amount must be shown as a separate line item on the receipt:

The merchant/platform must provide a disclosure on the checkout page that states: “a surcharge of x% will be assessed for paying with credit cards”.

Platforms must notify WePay of plans to surcharge by contacting your Relationship Executive or API Support (api@wepay.com). WePay is required to notify the card networks and our acquiring banks on behalf of the partner.

Implementing surcharging

Determine the surcharge percentage and then add that fee as a line item included in ‘amount’ on applicable transactions.

Alternatives to surcharging

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.

Convenience Fee
A Convenience Fee is a flat fee (such as $5) that can be charged for online (card-not-present) payments. For example, if the payer has multiple ways to pay (cash, check, online/in-app) a convenience fee can be applied to all online/in-app payments. Note that card network rules require that the same convenience fee must apply equally to all methods of payments; credit cards, debit cards, e-check, etc. and not just to credit cards.

Similar to surcharge, a convenience fee should be disclosed on the checkout page.

Also note that both surcharge and convenience fee cannot be applied on the same transaction according to card network rules.

Discounts and other incentives
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.

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 JS for tokenization.

In server-to-server integrations, your platform will not use the WePay JS for tokenization, so you’ll need to ensure that the credit_card.cvv parameter from POST /payment_methods calls does not get stored in your servers.

Visa CVV2

CVV2 is the same as standard CVV, but refers specifically to Visa cards. CVV2 is captured by the credit_card.cvv parameter on the /payment_methods resource in the WePay API.

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)

A simple rule of thumb to identify an exempted card is to check if the card has already processed a payment with CVV2 AND has recurring or card_on_file set to true. In other words, once a card on file or card for recurring payments has already successfully processed with CVV2, CVV2 collection is not required for subsequent payments. That said, WePay recommends collecting CVV2 for all new Visa credit card payment methods.

All API responses from the /payment_methods resource include a boolean cvv_provided parameter to indicate whether a CVV was provided at the time of credit card creation.

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

You must provide merchants on your platform a way to toggle accepting Canadian debit cards. If this is a requirement for your platform, send a POST to the /accounts/ endpoint, either when first creating an Account, or updating an Account after creation:

POST /accounts

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

The default is false, which means the Merchant Account can accept Canadian debit cards.

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.

  _{Last Updated: October 09, 2020}

Questions? Need help? Visit our support page!