Network Compliance Requirements
Overview of card network and The Clearing House requirements that you are responsible for applying appropriately.
Follow network compliance rules to help safeguard your users from misinformation and help reduce the potential of future disputes and your company's financial loss.
Please read all sections for rules related to your company and use case (see list of use cases). You must ensure you meet obligations related to checkout flows, receipts, statement descriptors, and consumer protection practices.
Submission
Prior to certification to the TabaPay API, you will be asked to submit screenshots of:
- Checkout Flow: UX/UI sequence of webpages leading up to final checkout and confirmation page
- Transaction Receipt: template or sample of a receipt
- Proof of Authorization Record: template used to obtain and store transaction authorizations
You will be asked for screenshots relating to each transaction type you will be conducting, whether push, pull, or both. These screenshots should show that you meet the requirements as defined by payment network rules below.
Checkout Flow
All Transaction Types
| Requirement | Description |
|---|---|
| Customer Service Contact | Customer service number, Address for mailing correspondence, or email address |
| Country of Merchant Outlet | Clear and prominent display of the country where Merchant is located must be either: ☐ On the same screen view as the checkout screen used to present the final Transaction amount, or ☐ Within the sequence of webpages that the Cardholder accesses during the checkout process |
| Equal treatment of card brands | ☐ Show all logos ☐ Show no logos ☐ Show a single logo after a card is entered |
| Terms & Conditions | The Terms & Conditions or Terms of Use of the service associated with the purchase must be explicitly acknowledged by the cardholder prior to completing the checkout. Merchant must store proof of consent for at least 2 years. It must be displayed in one of the following ways: ☐ On the same screen view as the checkout screen used to present the total purchase amount, ☐ Within the sequence of website pages the Cardholder accesses during the checkout process ☐ On the checkout screen near the submit or click to accept button |
| Return, refund, or cancellation policies | Before completing a transaction, the policy for returns, refunds, or cancellations must be explicitly acknowledged by the cardholder: ☐ During the sequence of pages before final checkout, the Cardholder must actively acknowledge the Merchant’s refund policy via a “click to accept” button, checkbox, or another acknowledgment. ☐The disclosure may be a link to a separate page on the same domain if that link forms part of the “click to accept” acknowledgment and refers to the return, refund, or cancellation policy. Within the policy: ☐Merchants cannot prohibit cardholders from initiating chargebacks ☐Merchants can restrict refunds, but this policy must be disclosed to the cardholder at the time of the transaction. ☐ For Push transactions, Merchant states during the checkout flow that all sales are final and cannot be reversed. |
| Transaction information displayed to the Cardholder before purchase | Merchant should confirm transaction information with Cardholders, presenting: ☐ Card network to be used for Transactions (logo or text) ☐ Masked card number (the full Payment Credential must not be displayed to the Cardholder, last 4 digits only: **-**-****-XXXX) ☐ Description of the service ☐ Itemized prices for goods/services, fees, and total amount |
Partial Payments, Advance Payments, and Transactions Using Stored Credentials
Lenders, cash advance providers (governed by TILA and Credit CARD Act), or other types of merchants that store and periodically transact with a user’s card for a predefined service and predefined amount (or formulaic amount) must implement the following:
| Requirement | Description |
|---|---|
| Disclosure and Agreement | Before a Merchant either stores a Payment Credential for a future Transaction or completes an Advance Payment or Partial Payment, it must obtain the Cardholder’s express informed consent to an agreement that contains all the following: ☐ Information related to the Transaction, including: - Description of goods or services - Total purchase price - Cancellation and refund policies - Expiration of any cancellation privileges without Advance Payment forfeiture - Disclosures and acknowledgment of surcharges, where permitted ☐ Information about the Merchant, including: - Merchant Outlet location - Customer Service Contact information ☐ Terms & Conditions related to the Stored Credential and future Transactions (where applicable), including: - Last 4 digits of Account Number used, as it may be updated - How the Cardholder will be notified of any changes to the agreement - Transaction amount or a description of it will be determined - The Transaction Currency - How the Stored Credential will be used - Timing and frequency of Transactions (except if unscheduled)_ - The expiration date of the agreement, if applicable - The length of any trial period, introductory offer, or promotional period If the Stored Credential will be used for Unscheduled Credential-on-File Transactions, the event that will prompt the Transaction (for example: if the Cardholder’s balance falls below a certain amount) ☐ When entering into a Cardholder agreement, all requirements related to specific Transaction types must be displayed when the Cardholder gives their consent and displayed separately from the general purchase Terms & Conditions. ☐ The Merchant must retain this information for the duration of the agreement and provide it to the Cardholder or Issuer upon written request. |
| Amount | Recurring or Unscheduled Credential-on-File transactions must not include any finance charges, interest, or imputed interest |
| Refund | Merchants must refund the full amount paid if Merchant has not adhered to the Terms & Conditions of the sale or service |
| Recurring Transaction | Merchant must do one of the following: ☐ Use recurring indicator in TabaPay API ☐ 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 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. |
Person-to-Person or Account-to-Account transactions
Money remitters or Banking as a Service (BaaS) providers debiting debit card (governed by Regulation E)
| Requirement | Description |
|---|---|
| Disclosure and Agreement | Before a Merchant either stores a payment credential or initiates a money transfer transaction, it must obtain the Cardholder’s express informed consent to an agreement that contains all the following: ☐ Information related to the Transaction, including: - Description of goods or services - Total purchase price - Cancellation and refund policies - Expiration of any cancellation privileges without Advance Payment forfeiture - Disclosures and acknowledgment of surcharges, where permitted ☐ Information about the Merchant, including: - Merchant Outlet location - Customer Service Contact information ☐ Terms & Conditions related to the Stored Credential and future Transactions (where applicable), including: - Last 4 digits of Account Number used, as it may be updated - How the Cardholder will be notified of any changes to the agreement - Transaction amount or a description of it will be determined - The Transaction Currency - How the Stored Credential will be used - Timing and frequency of Transactions (except if unscheduled) - The expiration date of the agreement, if applicable - The length of any trial period, introductory offer, or promotional period If the Stored Credential will be used for Unscheduled Credential-on-File Transactions, the event that will prompt the Transaction (for example: if the Cardholder’s balance falls below a certain amount) ☐ 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 & Conditions. ☐ The Merchant must retain this information for the duration of the agreement and provide it to the Cardholder or Issuer upon written request. |
| Refund | ☐ Remittance Transfer Rule gives Senders 30 minutes to cancel a remittance transfer and receive a refund and 180 days to report errors. ☐Merchants must refund the full amount paid if Merchant has not adhered to the Terms & Conditions of the sale or service. |
Receipts
All Transaction Types
| Requirement | Description |
|---|---|
| Payment Credential | Except for the final 4 digits, the payment credential must be disguised or suppressed on the Cardholder’s copy of a Transaction Receipt (**-**-****-XXXX) |
| Authorization Code | Six-digit code returned by TabaPay. |
| Card Network Name | Visa, Mastercard, etc. |
| Description of goods and services | Provide accurate and complete description of merchandise or services |
| Merchant Name | Provide trade name (DBA) a customer uses to identify Merchant |
| Return & Refund Policy | ☐Merchants must include return, refund, cancellation policy (as described in the above section). ☐ If a Merchant restricts the return of funds or cancellation of services, it must clearly disclose to a Cardholder its return, refund, and cancellation policies. Merchants doing disbursement should make clear that disbursements transactions are final. |
| Amount | - Total currency amount of all goods and services sold to the Cardholder at the same time - Applicable taxes - Fees - Any adjustments or credits |
| Date | Date of the transaction |
| Transaction Type | One of the following: - Purchase (An Account Funding Transaction is a Purchase) - Money Transfer (person-to-person or account offload) - Cash-Back with no purchase - Credit - Manual Cash Disbursement - Load Transaction - ATM Cash Disbursement |
Specialized Receipt Requirements
| Requirement | Description |
|---|---|
| Electronic Commerce Transaction | ☐ Customer service contact (e-mail and/or phone number). ☐ Merchant country ☐ Merchant address ☐ Conditions of sale, including return and cancellation policy |
| Transaction on which a fee is assessed | ☐ Shown separately and clearly: - Convenience Fee o Allowed on all card types in most states (10 states do not allow fees applied to debit transactions) o Must be the same for all card networks o Cannot be applied to recurring debit transactions (e.g., subscriptions or installment payments) - Service Fee -Surcharges: o Cannot be applied to debit card transactions o Show amount separately on the front of the receipt in the same type and size of font as other wording on the Transaction Receipt. - Wire Transfer Money Order Fee - Any other fees - Fees and Surcharges must not be identified as card network-imposed charges |
| Disbursement | ☐ Sender name ☐ Recipient name ☐ Sender’s payment credential (masked and/or truncated) ☐ Date and time of transfer ☐ Amount of transfer in the sender’s currency and/or recipient’s currency ☐ Total amount paid (i.e., amount of transfer plus any fees) ☐ Fees associated with the transaction ☐ Foreign currency conversion rates for cross-border transactions ☐ Sender Reference Number ☐ Description (e.g., Money Transfer) |
| Person-to-Person | -Mobile remittance providers must provide receipts within 1 business day of payment (Remittance Transfer -CFPB shares examples of receipts for meeting Regulation E requirements: ☐ Domestic ☐ Cross Border |
| Debt Repayment | Type of repayment (for example: “loan,” “mortgage,” “credit card,” “goods,” “services”) |
| Transaction in which currency is not the local currency of the Transaction Country | The currency symbol denoting the Transaction Currency |
| Dynamic Currency Conversion Transaction | ☐ Transaction amount, with currency symbols, in Merchant’s local currency ☐ Transaction Currency ☐ Words “Transaction Currency,” “Transaction Amount,” “Transaction Charged,” or “Amount Charged” next to the Transaction amount ☐ Currency Conversion Rate: Currency conversion commission, fees, markup, or margin on the exchange rate over a wholesale rate or government-mandated rate ☐ Statement, easily visible to the Cardholder, that the Cardholder has been offered a choice of currencies for payment (including the local currency of the Merchant or the currency dispensed at the ATM) and expressly agrees to the Transaction ☐ Statement that Dynamic Currency Conversion is conducted by the Merchant or ATM Acquirer |
RTP Specific Items
The Clearing House’s related to RTP’s specific checkout requirements along with general Operating Rules can be found here. General Operating Rules also include guidance on OFAC and Customer Identification Program obligations.
All Transactions
| Requirements | Description |
|---|---|
| No Fee Netting | Merchant must not reduce the amount of an RTP Payment to collect fees. |
| EFT Agreement | ☐ Merchant must obtain and store a record of explicit consent of the consumer that their account may be debited or credited via an Electronic Funds Transfer Agreement (EFTA). Proof of authorization of a transaction should be stored for up to 2 years. ☐ Consent should be obtained prior to and separate from initiating the transaction. |
Best Practices
| Practice | Description |
|---|---|
| Customer Service Contact | Merchant should provide relevant customer service information, such as phone numbers, website URLs, and/or an email address to the user in the payment confirmation page |
| Terms & Conditions | ☐ Users actively accepts Merchants’ Terms & Conditions before adding account information and/or completing the transaction The Terms & Conditions address the following: ☐ Provide clear description and details of product/service functionality and features. ☐ Security of PINs and Passwords: users should protect PINs and passwords; clients should provide users with customer service contacts should the security of PINs/passwords be compromised. ☐ Limits: rights of merchant to apply maximum transaction and/or volume limits; details of limits ☐ Fees/charges ☐ Use: who can participate; how the sender will be informed if a funds transfer is not possible and what this means to the sender’s account ☐ The sender is wholly responsible for providing the correct account information as well as the correct amount. ☐ Liability: Merchant and sender liability associated with the transaction; Merchant policies in the case of sender error (i.e., sender initiated the transaction to the wrong account or sent the wrong amount) ☐ Dispute policies and procedures: Clear dispute policies and procedures including information to the sender in case of a dispute such as a customer service telephone number or an email address ☐ Funds Availability |
| Transaction information displayed to the account holder prior to completing transaction | ☐ Account number / routing number that will receive the payment ☐ Description of the service ☐ Itemized prices for goods/services, fees, taxes (if any) and total amount |
| Transaction receipt with relevant information | ☐ Masked Account Number ☐ Transaction ID ☐ Description of goods or services ☐ Client Name ☐ Return and Refund policy (i.e. all disbursements are final) ☐ Transaction Amount ☐ Transaction Date |
Proof of Authorization
Proof of Authorization (POA) refers to evidence that a payor or payee has agreed to have their account debited or credited in accordance with the terms of the transaction. It must be stored for a minimum of 2 years following a transaction. While POA is conventionally a NACHA term, card networks follow the same principle: for every transaction, a merchant should be able to prove it was authorized even 3 months after the fact. Authorization can be written or electronic and should include the following at a minimum:
- Indication of transaction type: credit or debit
- A statement that the signer of the form is a signer on the bank account to be debited or credited
- The customer’s full routing and account numbers
- An express statement authorizing the payment amount
- Date of authorization
- Terms by which the customer can revoke their authorization of the transaction
- Merchant information (name, address, contact information)
- Signature or electronic signature (including click-to-agree) of the account holder
You can find an example of an authorization on NACHA's website here
Statement Descriptors
Statement descriptors are the descriptions that appear on a cardholder or account holder's statement. They are truncated at 22-40 characters (depending on the issuing bank) and should reasonably identify the transaction to the account owner. TabaPay can hardcode this field for you, however some customers will need to dynamically populate and pass it through themselves in the Soft Descriptor field to meet network requirements. The table below shares the minimum requirements for statement descriptors.
To meet these requirements you may have to certify to pass the descriptor in dynamically. See our Soft Descriptors page for more details on formatting and passing through the soft descriptor
| Use Case | Statement Descriptor Format | Example of what the account owner would see in the cardholder statement |
|---|---|---|
| Person-to-Person | P2P Provider*Counterparty to the transaction (push or pull) Dynamically passed in Soft Descriptor | Bilbo Baggins sends money to Frodo Baggins using Middle Earth's remittance platform: Sender, Bilbo, sees ME*Frodo Baggins Recipient, Frodo, sees ME*Bilbo Baggins |
| Account-to-Account (excluding brokerages) | BaaS Provider*Account Owner Dynamically passed in Soft Descriptor | Frodo Baggins loads his One Ring account held at Shire Bank: Sender, Frodo, sees OneRing*Frodo Baggins Frodo Baggins needs to offload his One Ring account to pay Recipient, Frodo, sees 1RNG*Frodo Baggins |
| Employer-Driven Earned Wage Access Provider | Provider Name*MerchantA Dynamically passed in Soft Descriptor | Strider needs to ask his employer, the Grey Company, for an advance to pay the innkeeper for his drinks, using Prancing Pony payments Recipient, Strider, sees Pony*Grey Company |
| Direct to Consumer Early Wage Access Provider | Provider Name | Strider, too embarrassed to ask his employer, again uses Isildur Heirs Advance provider to settle his debts with the innkeeper (before he was reformed by his valient journey) Recipient, Strider, sees Isildur Advance |
| Corporate Funded Disbursements (e.g. Lenders) | Company Name | The Council of Elrond is sending money to Gimli to fight the Black Riders Recipient, Gimli, sees Council of Elrond |
| Marketplace company | Marketplace Company Name | Legolas sold 100 arrows on Etsy merchant and is receiving settlement for goods sold: Recipient, Legolas, sees Etsy |
| Business-to-Business | B2B Provider*Supplier Name Dynamically passed in Soft Descriptor | The Green Dragon Inn wants to pay Barliman’s Best Brewery, a supplier, for a shipment of hobbit beer using Breezy Payments: Sender, The Green Dragon, sees BRZY*Barliman's Best |
| Consumer Bill Payment | CBPS Name* Biller Dynamically passed in Soft Descriptor | Sauron uses One Ring Payments to pay Mordor-cast, the electric company, to keep the lights on in Barad-dûr, the Dark Tower: Sender, Sauron, sees ORP*Mordor-cast |
Updated 7 months ago