Payment surcharges

Benefits

• For merchants,
  • Reduces the financial burden of credit card transaction fees and improves profit margins for merchants.
  • Allows flexibility to tailor surcharge fees according to the business needs and cost structures.
• For buyers,
  • Provides awareness to understand the additional costs associated with their payment method, leading to more informed payment decisions.
  • Allows the usage of lower-cost payment methods to reduce their overall transaction fees.

Prerequisites 

The payment Surcharges feature is available only if the Invoice Settlement feature is enabled.

If you would like access to this feature, contact your Zuora account team or submit a request to Zuora Global Support specifying your tenant ID.

Permissions and Roles 

The following user role permissions are required for the surcharge capability in Zuora:

1. Surcharge configuration: Surcharge configuration is performed by making an API call to create the combinations of attributes-value pairs that determine the surcharge amount (or rate). An API user is required to perform this action.
2. Surcharges computed during the payment run process will use the Payment Run Schedule Job user to create the debit memo holding the surcharge amount. 

How does Payment Surcharge work?

Attributes (Dimensions) and Mapping

Attributes: Keys or dimensions of the business that define the context of an invoice based on which the rate of surcharge is determined. A set of up to 10 attributes can be configured while defining Surcharges. All the attributes must have a valid mapping to a Zuora object. The following objects are supported for attribute mapping; that is, a standard or a custom field on any of these objects can be used to define surcharge rates:

• Account (API name: Account)
• Payment Method (API name: PaymentMethod)
• Sold to contact on Account (API name: Account.SoldToContact)
• Bill to contact (API name: Account.BillToContact)
• The user defines the attributes' names, which are used to configure the values per permutation of the surcharge rate.
• There can be up to 1,000 distinct permutations of the surcharge. 
• This limit is not applicable in the early adopter phase, but we recommend that any use case that requires a larger number of combinations must be discussed with Zuora.
• Attribute and context matching supports the equality (==) operator (exact matches); that is, the attribute values in the configuration must exactly match that of the mapped <object.field>.
• Attribute values can be String values only. 
• Payment Surcharge configuration should only have unique combinations of attribute values to avoid any race condition during retrieval and evaluation.

Key Features

• Payment Surcharge is configured under a specific surcharge model in Zuora, called “Payment Surcharge”. This model has several combinations of the rates based on the attributes that are used to define the rates (Card Type, Geo, Customer Type and so on).
• Users can define a set of attributes before configuring Surcharge.  
• Tax Mode and Tax code can be defined by combining the attributes. There is a default at the surcharge definition level, but users can modify it at the permutations of attributes like card type, brand, geolocation, and so on. 
• Reversible flags can not be modified at the level of individual combinations of attributes. 
• Accounting and revenue recognition information is maintained at the Surcharge level, not at the individual combination level. 
• Rates can be set as a percentage of the payment request amount or as a fixed fee per transaction. 
• Once set up, the surcharge configuration cannot be updated. It will need to be reconfigured (deleted and recreated). Applicable for the early adopter phase only.
• Since there is only one Payment Surcharge configuration (with n permutations on the attributes), developers can interact with the configuration using category as the handle “PAYMENT_SURCHARGE” (case sensitive).
  • Retrieval and delete can work using Category. You do not need to capture/store/retrieve Ids or keys. 

API (Definition Sample)

 

Sample Configuration 

(Note that there are other elements to the configuration such as Accounting, Revenue Recognition, and Taxation. Refer to detailed API specs for the same)

Auditing Changes to Surcharge Config

Changes to the Surcharge configuration are audited for the following actions: 

• Create
• Update
• Delete

Any changes made to this configuration through these actions are available in Zuora’s Audit Event logs. For more information on the Zuora Audit Trail and how to access it, see Audit Trail. Surcharge specific audit events can be located using the filter “objecttype = ‘Surcharge’” in data query.

 

Surcharge Evaluation 

The following flow diagram details the surcharge evaluation in Zuora:

The sequence of activities for computing surcharges and creating surcharge debit memos:

1. Surcharge eligibility is based on the surcharge configuration and is automatically evaluated via payment run at the time of payment request. 
2. Suppose the payment method in use is eligible for a surcharge. In that case, the surcharge amount is calculated based on the configuration, offering the flexibility of choosing between a percentage or a flat fee.
3. Further, if the surcharge is eligible for tax, tax amount is computed based on the tax code and mode defined in surcharge configuration and is evaluated on the total Surcharge amount.  And always uses the account default sold to address as the debit memo tax address. For computing tax, both z tax and Avalara are supported.

For example:

1. During a payment request to the payment gateway, the payment request includes the invoice balance being processed + applicable surcharge + surcharge tax. The invoice balance is calculated after applying any open credit memo or unapplied payment, should that be the configuration in the payment run. 
2. If payment collection is successful (Payment status = Processed), then a debit memo is created for the surcharge component of the payment. The surcharge debit memo carries the following attributes: 
   • Customer Account: Customer account associated with the invoice being processed in payment run 
   • Source: Payment Run 
   • Source Type: Surcharge 
   • Referred Invoice ID/Referred Debit memo ID: Invoice associated with the surcharge 
   • Memo Date: Max of Payment date or Invoice date
   • Target Date: Payment date 
   • Reason Code: Defaulted to ‘Surcharge’ (this reason code cannot be changed)
   • Charge Name: Name provided during surcharge configuration 
   • Other billing attributes, such as currency code, sequence set, payment term, sold to contact, and bill to contact, will be inherited from the source invoice or debit memo.
3. Once the surcharge debit memo is successfully created, the collected payment is applied to the original invoice. The surcharge debit memo is based on the default application rule configuration in Zuora. 

Surcharge Debit Memo looks like: 

4. The invoice pdf may be regenerated if you have configured the billing document settings. 

Notes:

• The surcharge debit memo (DM) is not linked to any specific invoice item or debit memo item. Surcharge DM carries one line item for the surcharge amount and a taxation item for the surcharge tax amount. 
• Surcharge DM posting does not trigger a separate post Debit Memo notification.
• Surcharge debit memos will be created as posted and will not go through a draft status. 
• Once created, surcharge type DMs cannot be unposted, canceled, or updated. 
• A payment refund will unapply the payment from the DM and leave the DM open (For more information, see Unapply and Refund section).
  • To write off the balance on surcharge debit memo, users can use the write off debit memo capability.
  • The payments associated with surcharge debit memos fully refunded using the Refund and auto-unapply API will be automatically written off when the user unapplies and refunds the payment.

Passing surcharge amount to payment gateway 

The surcharge amount will be passed to the payment gateway (Chase orbital is in scope for the early adopter phase) as Level 2 and Level 3 information.

L2 Information

Level 2 Information will include the ‘Total tax amount’. If a surcharge is taxable, this field will also include the surcharge tax along with the invoice tax.

L3 Information

When a surcharge is applied, Zuora will include it as one of the level 3 line items.

Here is an example (in red) of level 3 line items via Orbital.

<PC3FreightAmt>000</PC3FreightAmt> <PC3DutyAmt>000</PC3DutyAmt> <PC3DestCountryCd>USA</PC3DestCountryCd> <PC3ShipFromZip>98101</PC3ShipFromZip> <PC3DiscAmt>000</PC3DiscAmt> <PC3LineItemCount>1</PC3LineItemCount> <PC3LineItemArray> <PC3LineItem> <PC3DtlIndex>1</PC3DtlIndex> <PC3DtlDesc> <![CDATA[Payton Chesser]]> </PC3DtlDesc> <PC3DtlProdCd>SKU-00000069</PC3DtlProdCd> <PC3DtlQty>10000</PC3DtlQty> <PC3DtlUOM>ACR</PC3DtlUOM> <PC3DtlTaxAmt>000</PC3DtlTaxAmt> <PC3DtlTaxRate>00000</PC3DtlTaxRate> <PC3Dtllinetot>100000</PC3Dtllinetot> <PC3DtlCommCd>82101603</PC3DtlCommCd> <PC3DtlUnitCost>10000000</PC3DtlUnitCost> <PC3DtlGrossNet>N</PC3DtlGrossNet> </PC3LineItem> </PC3LineItemArray>

Notifying the Customer of a Surcharge 

Customers are notified via ‘Payment processed event notification’ with a regeneration of the invoice PDF, which is sent as an attachment. The re-generated invoice will have two modes:

• Detailed - a replica of the invoice with a line item added for surcharge and a grand total 
• Summary - sent as 2 line items. One shows the invoice total, the other shows the surcharge, and the grand total. The summary follows the same styling as the detailed (same as the invoice template).

Accounting for Surcharges 

Revenue Schedules

In a revenue recognition system, the accounting treatment for surcharges is as follows:

• If the accounting treatment of surcharges is configured as revenue (the revenue accounting code is selected while configuring surcharges), then revenue schedules are generated against surcharges.
• Revenue is distributed in the accounting period in which the payment originates.
• For any advanced revenue recognition, such as straight-lining over a period, it is recommended that you associate a specific rule with the Surcharge Configuration from the Manage Revenue Recognition Rules setting.
• Any advanced recognition strategy may need a Workflow and Mass Update. For more information, see Key Considerations.

Unapply and Refund of a Payment including Surcharge

Unapply and Refund of the surcharge is controlled by the ‘Reversible’ attribute value in surcharge configuration.

If `Reversible` = Yes, then when a user performs an Unapply of a payment which includes surcharge, they will be able to unapply a payment from the invoice as well as the associated surcharge debit memo, and issue a refund.

This will lead to both the invoice balance and the debit memo balance to be re-opened. The invoice balance can be closed by collecting future payments against the invoice. 

For closing the balance on the surcharge debit memo, users can use the ‘Write off debit memo’ function.

For automatically writing off the surcharge debit memo balance upon full unapply and refund, users can utilize the refund a payment with auto-unapply API. When a full unapply and refund is originated using this API, the surcharge debit memo balance will be automatically written off.

Key Considerations

• Payment surcharges are supported for payments generated from payment runs and payment retries (OOTB and CPR) only. Payments generated via Zuora UI/API orHPM are not considered for surcharge evaluation. 
• Payment run must be configured to take one payment against one invoice as surcharge is not evaluated in scenarios where a single payment is collected for multiple invoices/debit memos. 
• Surcharge configuration is available via API only. 
• Surcharge integration is supported via the Chase orbital payment gateway.
• Journal Run and Trial balance generation are supported. Revenue Recognition is supported through Zuora finance (and legacy Revenue), not Zuora Revenue (formerly known as Revpro). 
• Journal Run, Trial Balance, and legacy Revenue (upon posting of Debit Memo) are supported. Detailed data source for Journal Run doesn’t contain surcharge. 
• Zuora Advanced Custom Fields are not supported. For more information, see Manage custom fields with the Object Manager.