Overview

 

Using the Payeezy “Fee” feature for Convenience Fees or Service Fees requires the merchant to ensure that their use case is compliant with the Card Association Rules.  For example, for some Merchant Category Codes (MCCs) and Card brands, a Convenience Fee cannot be charged unless the payment is considered as an Alternative Payment Method such as Internet or Phone. The rules associated with each merchant’s use case, MCC, Card Brands accepted, and Payment Channel(s) are subject to change by the Card Associations.

• What is a Fee?
  • A levy for a cardholder’s use of a special service rendered at the time payment is made. Unlike a surcharge, a fee is not a charge for the payment service itself, but it is a fee linked with the transaction such as the use of a Voice Response Unit (VRU).
  • A merchant is permitted to charge a fee (such as a Bona Fide Commission, Postage, Expedited Service, Convenience Fee or similar) if the fee is imposed on all like transactions regardless of the form of payment used.

 

• What is a Surcharge?
  • A charge assessed by the merchant to the consumer for the payment service itself; for example, a fee charged for specific Alternative Payment Modes such as Internet and Telephone.

             Note: Surcharge is not supported by Payeezy Gateway

A merchant that charges a Convenience Fee must ensure that the fee is:

• Charged for a Bona Fide Convenience in the form of an Alternative Payment Channel outside the merchant's Customary Payment Channels.
• Disclosed to the Cardholder as a charge for the Alternative Payment Channel Convenience.
  • Note: The requirement for an Alternative Payment Channel means that MOTO and Electronic Commerce Merchants whose payment Channels are exclusively non face-to-face may NOT impose a Convenience Fee.
• Added only to a non face-to-face transaction
• A flat or fixed amount, regardless of the value of the payment due
• Applicable to all forms of payment accepted in the Alternative Payment Channel
• Disclosed prior to the completion of the transaction and the cardholder is given the opportunity to cancel out the transaction.
• Included as a part of the total amount of the transaction

The Fees are enabled in the following parts of the Payeezy Gateway: Real Time Payment Manager (RPM), Hosted Checkout Pages (HCO), Recurring Transactions, and the Web Service API.

 

How to start

 

Fees should first be provisioned by the First Data Support team (note that fees can only be enabled for MOTO and eComm terminal types, Retail device types are excluded). Once the Fees are provisioned, the merchant-admin can enable the Fees by going to terminal configuration and clicking on the Fees tab.

 

Important note

Dynamic Currency Conversion and Dynamic Pricing (DCC/DP) and Fee processing are mutually exclusive, if DCC/DP is provisioned for the client, Fees cannot be turned on and conversely if Fee processing is provisioned, DCC/DP cannot be turned on.

 

Fee types:

• No Fees (default)

• Fixed Amount per Transaction – e.g. $1.00 per Order

• A percentage of the Order Amount – e.g. %1.25 of the original Order amount

• A tiered Fee structure based upon a merchant defined tier and Fee amount for example:

- $1.00 Fee for Order amounts from $0.00 to $50.00

- $2.00 Fee for Order amounts from $50.01 to $100.00, etc.

Each Tier will ‘build’ upon the prior Tier, if Tier 1 ends at $50.00, Tier 2 will automatically start at $50.01, etc. Additionally Tier 1 will automatically start at $0.00 (a maximum of 4 tiers can be defined).

Note: If the Transaction amount falls outside of the defined tiers, the Fee input (via POS/Quick Key/Recurring) will default to the fee specified in the Fee Amount Above Maximum field.

Only one Fee type can be active at a given time (e.g. a merchant cannot have a fixed Fee plus a tiered Fee structure).

In addition to the Fee structure above, the merchant is able to define how Fees are to be processed (authorized and captured) by the Payeezy Gateway. The capability is selected by radio buttons with the following mutually-exclusive options:

• Fees included in Order Amount (Single Transaction – default value)

• Authorize/Capture Fees as a separate transaction and NOT included in the Order Amount.

 

Shown below is an example of the Fee Setup Screen:

 

 

 

Fees via the RPM

 

Point of Sale (POS)

Fees are enabled for an outlet by selecting the Fee tab for the desired outlet and selecting the fee features desired. If Fees are enabled, the Fee tag (defined in setup) will be displayed for POS transaction input. The field will:

• Be pre-populated based upon the Fee structure defined above.

• Be able to be modified from the pre-populated value (Over-ride).

 

Depending upon the transaction mode selected, the Fee will be treated in one of two of the following methods:

• Part of the Order Amount included in the authorization/completion of the ‘aggregated’ Order amount

• Separate from the Order Amount and following a separate and distinct authorization/completion path from the original Order amount (secondary transaction).

 

A sample screen for input / processing of Fees is shown below:

Note: The same choices will also apply Quick key input, Re-charge transaction in the Transaction tab and Recurring transactions.

Receipts will be modified as shown below to include the Fee Tag (and amount), if enabled as well as the new ‘aggregated’ total.

 

 

Transactions

The Preferences section of Transaction has a Fee tag. If the user has selected the option to include the Fee in the original amount (single transaction), then the Fee tag can be selected for inclusion on the transaction display as well as in the downloaded CSV or report file.

 

If the user has selected to submit the Fee as a separate transaction, both the original purchase transaction and the Fee transaction will be mutually tagged and both will be automatically displayed on any search.

 

 

Reports

Preferences will have a Fee Tag and its associated value. Fee Tag data is included in the downloaded CSV file if enabled.

If an admin with access to multiple MID’s is reviewing data, the default heading will be ‘FEE CHARGED” on all reports and displays.

 

Fees via Recurring

If Fees are enabled, the Fee tag (defined in setup/configuration) will be displayed for Recurring transaction input. The field will be pre-populated based upon the Fee structure and the user will be able to modify it from the pre-populated value (Over-ride).

 

Depending upon the transaction mode selected, the Fee will be treated as:

• Part of the Order Amount included in the authorization/completion of the ‘aggregated’ Order amount

• Separate from the Order Amount and following a separate and distinct authorization/completion path from the original Order amount (secondary transaction).

 

See the input screen sample in section POS, the input sequence will be the same.

Recurring CSV file format

 

Quick Key File Upload CSV Format

 

Fees via Hosted Checkout (HCO)

 

A field indicating “Fee Tag” is an optional field in the HCO. The logic to determine Fee processing will follow the following path:

• If the optional Fee field is populated by the merchant, the associated Fee will be displayed upon the consumer facing HCO payment page as defined by the merchant. This is a Fee override.

• If the optional Fee field is absent or not populated by the merchant, the defined Fee structure will be applied to the transaction and displayed on the consumer facing HCO payment page. This is the standard Fee model.

Depending upon the transaction mode selected, the Fee will be treated as:

• Part of the Order Amount following the authorization/completion of the aggregated Order amount

• Separate from the Order Amount and following a separate and distinct authorization/completion path from the original Order amount.

 

If the Fee is defined and present, the total Order amount displayed will be determined as the original order amount + the Fee + any other related charges (tax, shipping).

The Fee will be displayed to the consumer via a merchant defined field tag. This tag could represent a “Service Fee”, “Processing Fee”, “Transaction Fee”, etc…. It is up to the merchant to define what the intent of this field is.

 

The sample below reflects the HCO page Preview, the same update applies to the Mobile page preview if fees are enabled on the Fees tab.

Fees via the Web Service API

A field indicating “Fee” is an optional field in the Web Service API. The logic to determine Fee processing will follow the following logic path:

• If the optional Fee field is populated by the merchant, the associated Fee will be accepted by the system. This is a Fee override.

• If the optional Fee field is absent or not populated by the merchant, the Fee structure will be applied to the transaction. This is the standard Fee model.

 

Depending upon the transaction mode selected, the Fee will be treated as:

• Part of the Order Amount following the authorization/completion of the aggregated Order amount

• Separate from the Order Amount and following a separate and distinct authorization/completion path from the original Order amount.

 

Reporting API

A field “Fee Tag” is available to the reporting API interface.

 

Supported Transactions

Payeezy Gateway supports Fee processing through the following RPM, API and HCO interfaces:

 

 

Special considerations for Pre-Auth and Pre-Auth Completion transactions:

A fee will not be associated with a Pre-Authorization Transaction. The first Pre-Authorization Completion performed against the Pre-Authorization will trigger the fee and all other Pre-Authorization Completions performed against the original Pre-Authorization will not have an additional fee. If a Pre-Authorization Completion is refunded, the fee will only be included in the refund if all Pre-Authorization Completions against the original Pre-Authorization have been refunded (included in the final refund).

 

Special considerations for Void transactions

If a Pre-Authorization Completion is voided, the fee will only be included in the void if all Pre-Authorization Completions against the original Pre-Authorization have been voided (included in the final void).

Special Considerations for Authorization Reversal transactions:

Authorization reversals are system generated and will include the fee if a fee was included with the transaction being reversed. If the fee transaction itself triggers the Authorization reversal the transaction from which it was originated will also be reversed.

In general the fee, if charged, will not be voided or refunded until / unless all pre-authorizations against the Pre-Authorization have been processed.

Provision must be made in the event the Pre-Authorization Completion being Refunded/Voided is the one that triggered the Fee but not the only Completion against the Pre-Authorization, the fee may only be included in the Refund/Void if it is the last Completion against the Pre-Auth. There are no constraints on the sequence of voids/refunds on Pre-Authorization Completions today.

The example below reflects what would happen if transactions were voided/refunded in sequence.