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 theWePay Helper JS tokenization:

MoPUSCanada
Visa
Mastercard
American Express *
Discover
JCB and Diners Club
Bank Account/eCheck (ACH)Not supported
Remember:

The payments capability on an account 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.

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:

Below is an example of display marks:

An example display of card brands which must be included on checkout pages
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

RequirementDescription
Disclosure and AgreementBefore a Merchant or DWO either stores a Payment Credential for a future Transaction or completes and Advance Payment or Partial Payment, it must obtain the Cardholder's express informed consent to an agreement that contains all of the following:
  • Information related to the Transaction, including:
    • Description of goods and services
    • Total purchase price
    • Cancellation and refund policies, including the date that any cancellation privileges expire without Advance Payment forfeiture
    • Where surcharging is permitted, acknowledgment of any surcharge assessed and the associated disclosures
  • Information about the Merchant, including:
    • The location of the Merchant Outlet
    • Address, email address, and phone number to use to contact the Merchant in relation to the Transactions
  • Terms and conditions related to the Stored Credential and future Transactions (where applicable), including:
    • The Account Number that will be used to make payment (last four digits only), as it may be updated from time to time
    • How the Cardholder will be notified of any changes to the agreement
    • Transaction amount or a description of how the Transaction amount will be determined
    • The Transaction Currency
    • How the Stored Credential will be used
    • Timing and frequency of Transactions (does not apply if the Stored Credential will be used for Unscheduled Credential-on-File Transactions).
    • If the Stored Credential will be used for Unscheduled Credential-on-File Transactions, the event that will prompt the Transaction (e.g. if the Cardholder's balance falls below a certain amount)
    • The expiration date of the agreement, if applicable
    • The length of any trial period, introductory offer, or promotional period

When entering into a Cardholder agreement, all requirements related to specific Transaction types must be clearly displayed at the time that the Cardholder gives their consent and must be displayed separately from the general purchase terms and conditions.

The Merchant must retain this information for the duration of the agreement and provide it to the Cardholder or Issuer upon written request.
AmountA Recurring Transaction or an Unscheduled Credential-on-File, Transaction must not include any finance charges, interest, or imputed interest.
RefundThe Merchant must refund the full amount paid if the Merchant has not adhered to the terms and conditions of the sale or service.

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

Transaction TypeRequirement
Partial PaymentAn Acquirer must ensure that for a Partial Payment, the Merchant does not charge any interest, or imputed interest, to the Cardholder. If the Merchant applies a late payment fee, it must be a flat fee and must be applied only as a late payment penalty.

Additionally, for a Partial Payment where the Merchant is not the seller of the goods or services being purchased, the Merchant (or its affiliate) must have a direct contract with the seller and comply with all of the following:
  • Be located in the same country as the seller of the goods or services
  • For each new Partial Payment agreement, disclose to the Cardholder that:
    • It is not the seller of the goods or services and disclose the name of the actual seller
    • Disputes for non-delivery and quality of goods or services will not be available in relation to the foods or services purchased
    • The Cardholder's Issuer may charge interest, or other charges, in line with the terms and conditions of the agreement between the Cardholder and the issuer
  • Not state or imply that interest will not be charged by the Issuer for the Partial Payment
  • Make the following information available to Cardholder about each Transaction in the Installment Transaction Series, at minimum, through a website:
    • Description of each individual purchase, including the name of the seller
    • Amount and date of each individual purchase
    • Amount of each Installment Transaction
    • Number of installments paid and number of installments remaining
  • Use MCC 5999 (Miscellaneous and Specialty Retail Stores)
Advance PaymentOnly the following Merchant categories may process and Advance Payment representing the entire purchase amount before the goods or services are delivered:
  • T&E
  • Custom goods or services
  • Face-to-Face Environment, where not all items purchased in the Transaction are immediately available but will be shipped or provided at a later date
  • Recreational services or activities related to tourism and travel

The terms and conditions must specify the date of shipping of the goods or services to the Cardholder.
Recurring TransactionThe Merchant must do the following:
  • Provide a simple cancellation procedure, and, if the Cardholder's order was initially accepted online, at least an online cancellation procedure.
  • Include the fixed dates or intervals on which the Transactions will be processed.
  • At least 7 days before a Recurring Transaction, notify the cardholder via email or other agreed method of Communication if any of the following:
    • A trial period, introductory offer, or promotional period is going to end. The Merchant must include in the communication the Transaction amount and Transaction Date of subsequent Recurring Transactions and a link or other simple mechanism to enable the Cardholder to easily cancel Transactions online or via SMS/text message.
Installment TransactionExcept as specified in the *Visa International Certificate of Incorporation and By-Laws*, Visa assumes no liability for an Installment Transaction processed more than 30 calendar days from the Authorization date.

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

RequirementDescription
Before Storing the CredentialAfter a Cardholder agreement has been completed in writing, and before the first Transaction occurs, a Merchant must either:
  • Submit an Authorization Request for the Transaction amount
  • If payment is not required, submit an Account Verification

If the initial Authorization Request or Account Verification is not approved, the Merchant must not store the credential.
General Processing Requirements
  • Before processing a Cardholder-intiated Transaction, the MErchant must also validate the Cardholder's identity (e.g. with a login ID and password.)
  • The Authorization amount must not exceed the individual Transaction amount or Partial Payment amount, as applicable.
  • A Transaction with a Stored Credential must both:
    • Use POS Entry Mode code 10
    • For Recurring Transaction, Installment Transaction, or Unscheduled Credential-on-File Transaction, use the appropriate indicator in the POS environment field.
Authorization Request DeclinesIf an Authorization Request for a MErchant-initiated Transaction with a Stored Credential is declined, the Merchant must notify the Cardholder in writing and allow the Cardholder at least 7 calendar days to pay by other means.

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."
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
  1. Transaction Type (abbreviation allowed)
  • Purchase or Sale; Credit, Refund or Return; Prior Sale or Voice Authorization; Void; Reversal; Incremental Authorization; etc.
  1. Local date and time
  2. Entry Mode
  • Swipe, chip, NFC, etc.
  1. 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
  1. Card Type
  • Always print "CREDIT"
  1. Masked PAN
  2. Truncated Expiration Date
  • Must be omitted or fully truncated (XXXX or **)
  1. 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
  1. Approval or Authorization Code
  2. Application ID
  • Required on EMV only
  1. 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

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.


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.

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:

Copy
Copied
{
    "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:
Copy
Copied
"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:

Copy
Copied
"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.