Surcharge

Payment brands, such as card schemes and debit network providers, charge a fee for accepting payments on their payment network, called a payment acceptance fee. As a platform, you must have agreements in place with your users about how the payment acceptance fee is charged for each payment.

Your users can pass on these costs to their customers by adding a surcharge to their payments.

Requirements

Before you begin, take into account the following requirements, limitations, and preparations.

How it works

After the surcharge amounts and/or percentages are configured:

1. You make a payment request like you normally do. There are no special parameters required to trigger the surcharge.

2. The screen shows the purchase amount and instructs the customer to present their card.

3. Based on the card that the customer presents, the terminal calculates the surcharge using the surcharge amounts and/or percentages you configured.

4. If configured, the terminal shows a confirmation screen with the total amount of the payment, the surcharge amount, and the card scheme that the extra fee is charged for.

   In a Tap to Pay integration, the mobile device doesn't show a confirmation screen. The surcharge is applied automatically.

   

5. On the terminal, the customer selects the Confirm key to accept, and the payment is processed. The payment response shows the surcharge amount in the TotalFeesAmount field.

   If the customer doesn't accept the surcharge and selects the Cancel key, the whole transaction is cancelled.

Skipping the confirmation screen

It takes a bit of time for the customer to review the confirmation screen with the surcharge details. To avoid this delay in the payment flow, you can configure a setting to hide this screen. For Tap to Pay transactions that include surcharges, the confirmations screen doesn't show.

The flow will then be:

1. You make a payment request like you normally do.
2. The customer completes the payment.
3. Based on the card that the customer presents, the terminal calculates the surcharge and adds it to the payment amount during the authorization.

Configure surcharges

The payment acceptance fee charged to your user depends on the payment method brand (scheme), funding source (credit or debit), currency, and the country/region that issued the payment method (domestic or international). Therefore, the surcharge that your user passes on to the customer must be specific for the combination of brand, funding source, currency, and country/region.

The surcharge fee can be a fixed amount for each transaction, a percentage of the sum of the purchase amount and the tip, or both. You can configure the surcharge logic for payments based on the agreements you have with your users.

To configure surcharges:

1. Check the current surcharge configuration (if any) by making a GET request to the /terminalSettings endpoint for the company account, merchant account, store or terminal, and checking the surcharge object.

2. Create an overview of all surcharges that you want to apply. For example:

   Brand	Funding source	Country/region	Currency	Percentage	Amount
   eftpos			AUD	(none)	AUD 0.10
   Mastercard	Credit		AUD	1.2 %	AUD 1
   Mastercard	Debit		AUD	0.58 %	(none)
   Visa	Credit or Debit	AU, NZ	AUD	0.63 %	(none)
   Visa	Credit or Debit		AUD	1.63 %	(none)
   American Express	Credit		AUD	1.5 %	AUD 1.2

   Specifying the country field inside the configurations object applies the surcharge settings only to payment methods issued in that country/region. If not specified, the surcharge applies to all payment methods that meet the rest of the conditions.

3. Make a PATCH request to the /terminalSettings endpoint for the company account, merchant account, store or terminal.
   In the request body, specify a surcharge object with the following properties:

   Parameter	Data type	Description
   askConfirmation	Boolean	Indicates whether to show (true) or hide (false) the surcharge confirmation screen on the terminal.
   configurations	Array[Object]	List of payment methods for which to apply surcharges with the details per payment method. The order of different surcharge objects inside the configurations array impacts the order of execution. The condition that is met first is executed without checking the rest of the configuration.

   In the configurations object, specify:

   Parameter	Required	Description
   brand		A payment method supported for Management API, for example eftpos_australia or mc.
   currencies		An object with: currency code: the three-character ISO currency code. percentage: surcharge percentage per transaction up to two decimal places. For example, 1% or 2.27%. amount: surcharge amount per transaction, in minor units.
   sources		Can be: Credit or Debit. If not specified, the currencies settings apply to all possible funding sources for the brand.
   country		The country/region where the specified payment method has been issued. If used, the surcharge settings only apply to the payment method issued in that country/region.

   The response returns all terminal settings at the level where you made the request.

4. (Optional) Ask our Support Team to configure single tap. When this feature is enabled, the customer doesn't need to present their contactless card again after the terminal has calculated the total amount.

   When accepting payments with surcharges using Tap to Pay on a mobile device, only single tap flow is available.

Book the surcharge to your user

A surcharge is a type of transaction fee imposed by the card scheme, paid by your user's customer. Similar to the other transaction fees, you can use split instructions to define how to book the surcharge.

By default, the surcharge amount on a payment is booked to your liable balance account. However, you can book this amount directly to your user's balance account.

1. When splitting a payment, add a split item for the surcharge.

   When adding a new split item, always include this in the total number of split items specified in the split.nrOfItems field.

2. For the split item of the surcharge, specify:

   Key	Description	Example
   split.item[ITEM_NUMBER].type	The type of split. Set this to Surcharge.	split.item5.type=Surcharge
   split.item[ITEM_NUMBER].account	Account that will receive the surcharge. This is the balanceAccountID of one of your user's balance accounts. You cannot split the surcharge between multiple balance accounts.	split.item5.account=BA00000000000000000000001
   split.item[ITEM_NUMBER].reference	Your reference for the surcharge, reflected in the Balance Platform Accounting Report.	split.item5.reference=reference_surcharge
   split.item[ITEM_NUMBER].description	Your description for the surcharge, reflected in the Balance Platform Accounting Report.	split.item5.description=description_surcharge

   You do not need to include the surcharge amount in the split.totalAmount or split.item[ITEM_NUMBER].amount fields, since the surcharge amount is only calculated after the customer presents their card.

For example, a payment of EUR 636.00 is split into:

• EUR 600.00 to be booked to your user's first balance account as the sale amount.
• The payment fee to be booked to your user's first balance account. This will be deducted from the sale amount.
• EUR 10.00 to be booked to your user's first balance account as the tip.
• EUR 6.00 to be booked to your user's first balance account as the surcharge.
• EUR 20.00 to be booked to your liable account as your platform's commission.

In this case, set the split.nrOfItems to 5 and split.totalAmount to 62000 (the amounts for the tip, payment fee, and surcharge are not known when sending the payment request).

In the PaymentResponse note the following:

• POIData.POITransactionID.TransactionID: Transaction identifier for the payment.

• PaymentResult.AmountsResp:

  • AuthorizedAmount: total amount of the payment (the sum of the original transaction amount, tip amount, and surcharge amount).
  • TipAmount: amount of the tip. If the customer didn't add a tip, this field is not included.

  • Currency: currency of the payment.

    • Response.Result: Success
    • Response.AdditionalResponse: additional transaction data. Depending on the format you used in the request, you receive either a string of form-encoded key-value pairs or a Base64 string that you need to decode to get a JSON object. This includes:
      • posadditionalamounts.originalAmountValue: the original transaction amount in minor units.
      • posAmountGratuityValue: the tip amount in minor units.
      • authorisedAmountValue: the total authorised amount in minor units, which includes the surcharge amount.