A surcharge is a fee assessed to credit card transactions by Merchants to their customers as an additional charge to cover specific costs associated with credit card processing.
Surcharges can cause legal complications if each requirement for compliance and registration is not met or if the surcharge is not properly configured. The information provided in this guide outlines the steps to properly register and configure a surcharge (where allowed by law).
Getting Started
To begin surcharging, you must follow the steps below:
Notify your Partner Experience Manager that you would like to start a surcharge program to begin setup of the Merchant Group.
Your Payrix Pro representative will enable the
surcharge
parameter for you to send the surcharge amount (required by Visa) with transactions.Note that the
surcharge
parameter is for reporting purposes only, so it does not have any effect on how the fees should be calculated.
Meet each Surcharge Program Setup Requirement.
After the surcharge function and parameter are enabled, set the surcharge collection workflow that works best with your business type. See Potential Surcharge Workflows below to view diagrams outlining other optional setups:
Potential Surcharge Workflows
The following image depicts a fee configuration where Surcharge = Merchant Fees with Fee Scheduler:
The following image depicts a fee configuration where Surcharge = Merchant Fees with Fee Listener:
The following image depicts a fee configuration where Merchant Fees > Surcharge with Fee Listener:
The following image depicts a fee configuration where Merchant Fees > Surcharge with Fee Scheduler:
The following image depicts a fee configuration where Merchant Fees > Surcharge with Interchange Plus:
Tip
If you do not find a scenario that meets your needs, contact your Partner Experience Manager to further scope your request.
Responsibilities by Platform
Partner Platform | Payrix Pro Platform |
---|---|
| Collect the surcharge fee paid by the credit card customer to the Merchant, from the Merchant transaction amount, on behalf of the Partner using our Fees system. |
Surcharge Program Setup Requirements
The use of a surcharge program can result in legal complications. As a result, it’s imperative to follow each of the compliance requirements below to adhere to card brand and state/local regulations.
Compliance Requirements
Surcharges are only permitted on credit cards; they cannot be assessed on debit cards.
Surcharges cannot be assessed in states where surcharges are prohibited by law.
The maximum recommended surcharge amount is 3% to adhere to Visa and Mastercard restrictions.
There must be a separate line item for the surcharge on the checkout page and receipt.
Merchants must disclose their full surcharge policy on their checkout page before transaction completion.
Card Brand and Acquirer Registration Requirements
Visa: The
surcharge
parameter must be used to notify Visa of a transaction surcharge through Payrix Pro (via backend Field 28). For values populated in authorization and clearing (Field 28), Visa considers this to be a notification of the surcharge.Mastercard: Registration and notification to Mastercard at least 30 days before surcharging.
Discover: No registration required.
American Express: No registration required.
Acquirer Registration: The Payrix Pro platform will enable the
surcharge
parameter, sending surcharging Merchants in a given group to the acquirer.
Note
The amount of the surcharge fee assessed on the cardholder does not have to match the amount of the fee assessed on the Merchant. This means that the cardholder could be assessed a 3% fee and the Merchant could be assessed a 3.50% fee.
Create a Surcharge in the Portal
Complete the following steps to enable a Surcharge in the Portal and apply it to a Group:
Click GROUPS in the left navigation panel to open the Groups page.
Locate the group in the table and select any information in the table row to open the Group Profile page.
Click FEES in the list of tabs on the left side of the page.
Click the ADD FEE button in the upper-right corner of the page to open the Add Fee lightbox on the page.
Click the When to Trigger the Fee? dropdown menu and select Capture.
Click How Much is the Fee? down and select Surcharge.
Set the Amount field to 3.00 (for 3%) or less.
Set the Fee Start Date as today’s date.
Name the Fee using an easy-to-find naming convention. Then, click Advanced Options.
Enable the surcharge as a transaction fee by selecting Transaction Fee.
Under the Conditional Rules dropdown, select Payment Card Type is, and then select Credit from the available options.
Create a Surcharge via API
Complete the following steps to enable a Surcharge with the API and apply it to a Group:
Create the Surcharge
POST /fees HTTP/1.1
Accept: application/json
Content-Type: application/json
Host: api-test.payrix.com
APIKEY:{{private_api_key}}
Example Request Body:
{
"entity": "t1_ent_xxxxxxxxxxxxxxxxxxxxxxx",
"forentity": "t1_ent_xxxxxxxxxxxxxxxxxxxxxxx",
"org": "t1_org_xxxxxxxxxxxxxxxxxxxxxxx",
"type": 1,
"name": "3% Surcharge",
"schedule": 7,
"scheduleFactor": 1,
"start": "{{CurrentDateTime}}",
"um": 3,
"amount": "300",
"currency": "USD",
"txnFee": 1
}
Add Fee Parameter | Required Value | Note |
---|---|---|
|
| Fee. A Standard Fee. |
|
| Capture. The Fee is triggered at the time of credit card capture for a transaction. |
|
| No schedule factor is needed ( |
|
| Surcharge. The Fee is a percentage, specified in the |
|
| The numerical fee amount, written in basis points to represent a percentage. (Example: Warning: When setting up a surcharge, do not exceed 3% to adhere with all credit card brand regulations. |
| {yourStartDate} |
It is recommended to use today’s date as the Fee Start Date to make the Fee effective immediately. |
|
| US Dollars. |
|
| Enabled Transaction Fee |
|
| Txn-Merchant. The total amount of all transactions per entity. |
|
| No Collection Factor |
|
| No Collection Offset |
|
| Active |
|
| Not Frozen |
Example Response Body:
{
"id": "t1_fee_xxxxxxxxxxxxxxxxxxxxxxx",
"created": "2024-01-24T17:50:38.717Z",
"modified": "2024-01-24T17:50:38.717Z",
"creator": "t1_log_xxxxxxxxxxxxxxxxxxxxxxx",
"modifier": "t1_log_xxxxxxxxxxxxxxxxxxxxxxx",
"entity": "t1_ent_xxxxxxxxxxxxxxxxxxxxxxx",
"forentity": "t1_ent_xxxxxxxxxxxxxxxxxxxxxxx",
"org": "t1_org_xxxxxxxxxxxxxxxxxxxxxxx",
"type": "1",
"name": "3% Credit Card Surcharge",
"schedule": "7",
"scheduleFactor": 1,
"start": "{{CurrentDateTime}}",
"collection": "1",
"collectionFactor": "1",
"collectionOffset": "1",
"um": "3",
"amount": "300",
"currency": "USD",
"txnFee": "1",
"inactive": "0",
"frozen": "0"
}
Parameter | Type | Description | Expected Values |
---|---|---|---|
| string | The ID of the newly created Fee. | Format: |
| string | The Date and Time that the Fee was created. | Format: |
| string | The Date and Time that the Fee was last modified. | Format: |
| string | The Login ID for the user that created the Fee. | Format: |
| string | The Login ID for the user that last modified the Fee. | Format: |
| string | The entity ID for the entity the Fee is being applied to. | Format: |
| string | The Org ID for the group the Fee is being applied to. | Format: |
| integer | The type of Fee being charged to the entity. |
|
| string | Custom name for the Fee. | Recommended name: |
| integer | The Fee trigger. |
|
| string | A multiplier that you can use to adjust the schedule set in the | 0 |
| string | The date that the Fee will take effect. | Today’s date. Format: |
| integer | Applies the fee based on the volume of a resource. |
|
| integer | A multiplier that you can use to adjust the set of data to be used in the collection calculation. |
Format: |
| Whether to include the current period for the collection calculation. |
| |
| integer | The unit of measure for this Fee. |
|
| string | The amount of the fee by unit of measurement ( |
|
| string | The three-digit symbol for the currency that the Fee will be charged and collected in. |
|
| integer | Indicator to extract fee from txn supplied fee. When set, amount will correspond to the fee amount in the txn and only that amount will be extractable, anything over that amount will not be extracted. |
|
| integer | Whether this fee is active. |
|
| integer | Whether this fee is temporarily frozen. |
|
Add the Credit-Only Fee Rule
POST /feeRules HTTP/1.1
Accept: application/json
Content-Type: application/json
Host: api-test.payrix.com
APIKEY:{{private_api_key}}
Example Request Body:
{
"fee": "t1_fee_xxxxxxxxxxxxxxxxxxxxxxx",
"name": "Credit-Only Surcharge Rule",
"description": "Only allows surcharging on credit cards.",
"type": "methodType",
"application": "both",
"value": "credit",
"inactive": "0",
"frozen": "0"
}
Parameter | Type | Required | Descriptions | Required Value |
---|---|---|---|---|
| string | Required | The Fee ID for the Fee you want to apply the Fee Rule to. | Fee ID from Step 1 response body. Format: |
| string | Optional | Custom name for the Fee Rule for easy identification. | Recommended name:
|
| string | Optional | Custom description for the Fee Rule for clarification. | Recommended description:
|
| string | Required | The type of rule you’ll be applying to the specified Fee. |
|
| string | Required | When this Fee Rule will be applied. |
|
value | string | Required | credit | |
| integer | Required | Whether this Fee Rule is inactive. |
|
| integer | Required | Whether this Fee Rule has been frozen. |
|
Example Response Body:
{
"id": "t1_frl_xxxxxxxxxxxxxxxxxxxxxxx",
"created": "2024-01-24T17:50:38.717Z",
"modified": "2024-01-24T17:50:38.717Z",
"creator": "t1_log_xxxxxxxxxxxxxxxxxxxxxxx",
"modifier": "t1_log_xxxxxxxxxxxxxxxxxxxxxxx",
"fee": "t1_fee_xxxxxxxxxxxxxxxxxxxxxxx",
"name": "Credit-Only Surcharge Rule",
"description": "Only allows surcharging on credit cards.",
"type": "methodType",
"application": "both",
"value": "credit",
"inactive": "0",
"frozen": "0",
}
Parameter | Type | Description | Expected Values |
---|---|---|---|
| string | The ID of the newly created Fee Rule. | Format: |
| string | The Date and Time that the Fee Rule was created. | Format: |
| string | The Date and Time that the Fee Rule was last modified. | Format: |
| string | The Login ID for the user that created the Fee Rule. | Format: |
| string | The Login ID for the user that last modified the Fee Rule. | Format: |
| string | Custom name for the Fee Rule for easy identification. | |
| string | Custom description for the Fee Rule for clarification. | |
| string | The type of rule you’ll be applying to the specified Fee. |
Method type. The Fee applies based on the given payment method. |
| string | When this Fee Rule will be applied. |
Both. The rule should apply to the fee and to the calculation of collections. |
| string | This field refers to the numerical amount for |
Credit Card. The fee rule will only apply when the payment |
| integer | Whether this Fee Rule is inactive. |
|
| integer | Whether this Fee Rule has been frozen. |
|
Applying a Surcharge through a Transaction
After your fee and fee rule have been enabled using the Portal or API, you can apply the Surcharge using one of the following methods:
Separate Transaction and Surcharge Calculation: POST /txns
This process directly calculates the fee amount, ensuring the amount is 100% of the value provided in the fee
parameter.
In the
fee
parameter, enter the calculated surcharge amount (3% of the transaction total).In the
total
parameter, enter the original transaction total, plus the surcharge total.Example: 3% Surcharge for $100 original transaction total = $103.00 total amount.
Using the Portal, create a fee or adjust the existing surcharge fee with the following values:
Add Fee Parameter | Required Value | Note |
---|---|---|
When to trigger the fee? | Capture | The Fee triggers at the capture time of a Transaction. |
How much is the fee? | Percentage | |
Amount | 100% | 100% of the amount of the value sent using the Formatted as |
Fee Start Date | {yourStartDate} | It is recommended to use today’s date as the Fee Start Date to make the Fee effective immediately. |
Transaction Fee | Enabled | Checkbox available under the Advanced Options section of the lightbox. |
Example Transaction:
{
"allowPartial": "0",
"debtRepayment": "0",
"origin": "1",
"platform": "VCORE",
"type": "1",
"currency": "USD",
"fundingCurrency": "USD",
"unattended": "0",
"payment": {
"method": 0
}
"fee": "300",
"total": "10300"
}
Combined Transaction and Surcharge Calculation: POST /txns
This process reverse-calculates the fee amount, ensuring that the 3% is calculated from the transaction amount alone, rather than the transaction amount + surcharge amount together.
In the
fee
parameter, enter the calculated surcharge amount (3% of the transaction total).In the
surcharge
parameter, enter the calculated surcharge amount (3% of the transaction total).In the
total
parameter, enter the original transaction total, plus the surcharge total.Using the Portal, create a fee with the following values:
Add Fee Parameter | Required Value | Note |
---|---|---|
When to trigger the fee? | Capture | The Fee triggers at the capture time of a Transaction. |
How much is the fee? | Surcharge | |
Amount | 3% | 3% of the pre-caluclated transaction amount as shown of the value sent using the Formatted as |
Fee Start Date | {yourStartDate} | It is recommended to use today’s date as the Fee Start Date to make the Fee effective immediately. |
Transaction Fee | Enabled | Checkbox available under the Advanced Options section of the lightbox. |
Example Transaction:
{
"allowPartial": "0",
"debtRepayment": "0",
"origin": "1",
"platform": "VCORE",
"type": "1",
"currency": "USD",
"fundingCurrency": "USD",
"unattended": "0",
"payment": {
"method": 0
}
"fee": "300",
"surcharge": "300",
"total": "10300"
}
Apply a Surcharge through a PayFields Token
Because PayFields does not currently offer a direct connection to the surcharge
parameter available through the /txns
endpoint, a workaround is to tokenize the payment method only using PayFields, then create a subsequent POST /txns
API request using the new token as the payment method with the Surcharge applied.
Apply a Surcharge to PayFields Transactions
In the following scenario, we are applying a 3% surcharge for credit card payments.
Step 1: Create your payment page through PayFields like normal, using the following parameters to create a new payment token from payment methods submitted by customers:
PayFields.config.amount = '0'
PayFields.config.mode ='token'
PayFields.config.txnType = 'capture'
Tip
Be sure to include your Surcharge policy clearly for customers to see before completing their transactions.
Step 2: When a transaction is created, PayFields are configured to automatically tokenize the payment method (see the code snippet example below) when a transaction is submitted. Locate the token
value in the response data for the transaction.
For this example, we’ll use $100 as the amount for the initial transaction total.
Example Token:
123abc456defxxxxxxxxxxxxxxxxx
Example PayFields Tokenization:
Step 3: Make a request to the following endpoint:
GET /tokens&expand[payment][bin][]?token[equals]={Your Payfields Response Token} HTTP/1.1
Accept: application/json
Host: api-test.payrix.com
Content-Type: application/json
APIKEY:{{private_api_key}}
Example Request URL:
GET https://api-test.payrix.com/tokens&expand[payment][bin][]?token[equals]=123abc456defxxxxxxxxxxxxxxxxx
Step 4: In the response body, locate the payment method type via the method
and type
parameter.
The
method
parameter must be1
,2
,3
,4
, or5
.The
type
parameter should display ascredit
.
If the method and type indicate Credit as the payment type, continue to Step 5. If the method and type indicate debit, go to Debit Card Handling for instructions for routing the potential fee.
Example Response:
{
"payment": {
"bin": {
"bin": "123456",
"method": 2,
"type": "credit",
"name": "BIG BANK USA",
"country": null,
"website": null,
"phone": null,
"address": null,
"city": null,
"state": null,
"zip": null,
"locationType": null,
"newBin": null,
"category": null,
"transferEnabled": 0,
"numberLength": null,
"debitOverCreditEnabled": 0,
"billPayEnabled": 0,
"pinlessSupport": null
},
"id": "abc123def456hij78",
"method": 2,
"number": "1234567891011213",
"routing": "0",
"payment": null,
"lastChecked": null,
"last4": 1213,
"mask": null
},
"id": "t1_tok_xxxxxxxxxxxxxxxxxx",
"created": "2024-01-25 12:11:32.8155",
"modified": "2024-01-25 12:11:32.8155",
"creator": "t1_log_xxxxxxxxxxxxxxxxxx",
"modifier": "t1_log_xxxxxxxxxxxxxxxxxx",
"customer": "t1_cus_xxxxxxxxxxxxxxxxxx",
"token": "123abc456defxxxxxxxxxxxxxxxxx",
"expiration": "0123",
"inactive": 0,
"frozen": 0,
"name": null,
"description": null,
"custom": null,
"authTokenCustomer": null,
"status": "ready",
"type": "internal",
"internalToken": null
},
Step 5: After the method
and type
have been verified as a credit card payment, make a request to the following endpoint to create the credit card capture transaction and apply the 3% surcharge to the original transaction amount:
POST /txns HTTP/1.1
Accept: application/json
Host: api-test.payrix.com
Content-Type: application/json
APIKEY:{{private_api_key}}
Example Request Body:
{
"merchant": "{{Merchant_id}}",
"type": 1,
"origin" : "2",
"token": "{{tokenFromPayFieldsResponse}}",
"fee": "300",
"surcharge": "300",
"total" : 10300
}
Result: Your PayFields payment page credit card transaction has now been properly assessed the surcharge from the tokenized credit card, and the Merchant has been assessed the surcharge through their Partner.
Debit Card Handling
You can handle this compliance rule by querying our /tokens
endpoint to determine if the card is credit or debit. If it is debit, then you can handle this in a few ways:
If during your review of the customer’s payment token, you discover that the payment method is a debit card, you can use one of the following options to proceed because surcharges cannot be applied to debit card transactions:
Create a separate fee for debit-only transactions.
Do not charge the cardholder any surcharge fee or pass any value in the
fee
field.With this option, the Merchant would have to cover the fee amount that you set up in Payrix Pro.
Send a
POST /txns
endpoint request with a setfee
parameter.Do not charge the cardholder any surcharge fee.
Pass a fee amount in the
fee
field.With this option, the Merchant would have to cover the fee amount that you pass.
Flag an alert to the cardholder on the checkout page saying that they need to enter a different card.
With this option, the Merchant avoids paying a fee.
Option 1: Create a separate fee for debit-only transactions
POST /txns HTTP/1.1
Accept: application/json
Host: api-test.payrix.com
Content-Type: application/json
APIKEY:{{private_api_key}}
Example Request Body - Debit Cardholder Transaction:
{
"merchant": "{{Merchant_id}}",
"type": "1",
"origin": "2",
"token": "{{tokenFromPayFieldsResponse}}",
"total": "10000"
}
Result: Customer is not assessed a surcharge or fee for using a debit card. The Merchant is charged a fee for processing the debit card from the Partner.
Option 2: Send a POST /txns
endpoint request with a set fee
parameter
POST /txns HTTP/1.1
Accept: application/json
Host: api-test.payrix.com
Content-Type: application/json
APIKEY:{{private_api_key}}
Example Request Body - Debit Cardholder Transaction:
{
"merchant": "{{Merchant_id}}",
"type": "1",
"origin": "2",
"token": "{{tokenFromPayFieldsResponse}}",
"total": "10000",
"fee": "300"
}
Result: The Customer is not assessed a surcharge or fee for using a debit card. The fee value is passed with the transaction, however, and the Merchant’s transaction total is deducted to cover the fee.
Option 3: Create a checkout page alert to enter a different, valid credit card
Build a basic logic for your payment page to inform customers upon input of their card information that a credit card is required for the transaction:
Example JavaScript Flag Alert:
function checkCardType() {
var cardTypeInput = document.getElementById("cardType").value.toLowerCase();
if (cardTypeInput === "debit") {
alert("Please Note: Credit card required for this transaction.");
} else {
alert("Invalid card type. Please enter a valid credit card.")
}
}
Result: The customer will be prompted to enter a credit card instead of a debit card. This will prevent the Merchant from paying a surcharge or fee altogether.
Comparing Surcharges, Convenience Fees, and Service Fees
As the following fee types are similar in setup and collection process, it’s important to understand the differences between them to avoid legal complications and possible chargebacks.
Surcharges
Surcharges, or Surcharge Fees, as mentioned earlier, are specifically designed for credit card-only transactions at all times. These types of fees are inclusive of all credit card transactions under a Merchant or Group and can be applied consistently as long as card brand and legal requirements are met.
Example: A Merchant offers cash, debit, or credit as payment options to their customers. To help offset the costs of credit card processing, the Partner applies a 3% surcharge to the Merchant for credit card transactions, and in turn, allows the Merchant to collect the surcharge directly from the consumer at checkout through their platform offering.
Convenience Fees
Convenience Fees are fee charges passed on to customers for the ability to pay for a product or service using an alternative payment method that is not standard for a business.
Example: A Merchant can state that they traditionally accept cash or check only, and offer the convenience of paying with a “non-traditional” method (credit card), which the Partner collects and keeps or profit shares with the Merchant. This fee can also be collected directly from the consumer at checkout through the Partner’s platform offering.
Generally, a convenience fee cannot be implemented in in-person settings (such as physical card terminals). Typically, this refers to internet and over-the-phone transactions.
Service Fees
Service Fees are actually a type of convenience fee that comes with specific rules and regulations resulting from certain limited qualifying MCCs, as opposed to a general convenience fee mentioned above where the fee can be assessed generally for alternative payment method usage. For comparison, we will classify Service Fees under Convenience Fees.
Example: A Merchant who operates a business classified as MCC 8220 (such as Colleges or Universities) processes a card payment. The associated interchange and processing fees are debited directly from their Partner’s operating account. Then associated fee costs are reimbursed to the Partner’s platform account through a 100% withdrawal of the Merchant’s entire transaction amount and fee cost.
Conclusion
While both Convenience Fees and Surcharges are similar in their setup and collection processes, there are important legal and compliance distinctions as well as different requirements for when each fee type can be applied.
Convenience Fees
Allowed only on Card-Not-Present transactions.
Applies to alternative payment methods from the Merchant’s standard payment options.
The fee is a flat or fixed amount.
Applicable to credit and signature debit.
Disclosed before the completion of the transaction and the cardholder is allowed to cancel.
Included as part of the total sale.
Allowed on credit and signature debit.
Note: The Convenience Fee requirements listed here are based on Visa’s rules, as they are the strictest. Other rules apply if accepting only MC and AMEX.
Surcharges
Allowed on Card-Not-Present and Card-Present transactions.
Applicable only to credit cards, not debit.
The fee is a percentage of the sale.
Cardholder Disclosure of Surcharge policy required.
Disclosed before the completion of the transaction and the cardholder is allowed to cancel.
Included as part of the total sale.
A 30 days' notice must be provided to the Mastercard card brand network, Worldpay for Platforms, and/or the acquiring bank before starting to surcharge.
Merchants must complete registration directly with Mastercard.
Surcharges are prohibited in some states.
Important!
Surcharges and convenience fees cannot be applied on the same payment.