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, Canada, and the UK in embedded/hosted and Tokenization integrations:

MoP US Canada
American Express ✓ *
JCB and Diners Club
Bank Account/eCheck (ACH) Not Supported
ApplePay ✓ ** Not Supported


Tokenization must be enabled before payments from any MoP can be processed.

* 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.
* * Check with your Account Manager or with API Support ( before starting development work for ApplePay.

Displaying card payment marks

Below are examples of display marks: Example Card Brand Marks

Displaying wallet payment marks

Follow the ApplePay guidelines for ApplePay buttons and 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.

By default, WePay delivers electronic receipts and the platform/merchant must:

  1. Inform the payer of transaction receipt delivery method (i.e. email, text message, etc) and when it will be sent. WePay transaction receipts will be sent immediately via email.
  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

  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 likelihood of cardholder dispute/chargeback:
    • For merchants in the US and UK: “This charge will appear on your credit card statement as WPY*description.”
    • For merchants in Canada: “This charge will appear on your credit card statement as description.”

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

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

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 cancelled, 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 ( for further information.
  • For declined transactions, merchants should contact the cardholder for updated card information.

Reference: Card Acceptance Guidelines for Visa Merchants, Visa, 2015

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

  • 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 surcharging is not allowed in Canada for now.

In the UK, with implementation of the new EU Payment Services Directive (PSD2) in Jan 2018, surcharging is not allowed.

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

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

receipt disclosure

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

WePay doesn’t recommend using the WePay API fee structure where ‘fee_payer’ is set to ‘payer’ for this purpose. This configuration charges both the app fee (if any) and WePay fees to the payer, whereas the intent of surcharging is to charge only the credit card processing fees to the payer.

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



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 the embedded checkout, or the WePay tokenization library with custom checkout.

In server-to-server integrations, your platform will not use the WePay tokenization library with custom checkout, so you’ll need to ensure that the cvv parameter from /credit_card/create calls does not get stored in your servers.

Canada FCAC


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.

With regards to Canada and card network rules, please specifically note that WePay will default country_options.debit_opt_in to false. This means that Canadian merchants will need to explicitly opt-in to accepting debit cards, whether as part of your platform terms of service or as its own acknowledgment during sign-up. For more information on debit opt-in, please see our Canadian Merchants article.

Visa CVV2


CVV2 is the same as standard CVV, but refers specifically to Visa cards. CVV2 is captured by the cvv parameter on the /credit_card 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
  • Card on File transactions
  • Credit Card transfers
  • Digital Wallets (Apple Pay, Google Pay)

A simple rule of thumb to identify an exempted card is to check:

  • If there is an initial transaction on the card where CVV2 was collected
  • If the card has recurring or card_on_file set to true
  • If the card’s input value is any of the following:
    • card_transfer
    • google_pay
    • android_pay
    • google_wallet

That said, WePay recommends collecting CVV2 for all new Visa credit card payment methods.

All /credit_card responses will now include an additional boolean field cvv_provided to indicate whether a CVV was provided at the time of credit card creation.

WePay will deny this transaction if:

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

The API will return the following response:

    "error": "invalid_request",
    "error_description": "CVV required for this transaction.",
    "error_code": 1004,
    "details": [

    "documentation_url": ""

Last Updated: October 31, 2019