Magento 2 Surcharges by Payment Method, Shipping Method, and Customer Group

A client asks for "a 3% fee when someone pays by card" and it sounds like an afternoon of work. It is not, for two reasons. The first is legal: card surcharges are regulated by state law and card-brand rules, and getting it wrong is a compliance problem, not a bug. The second is technical: Magento 2 does not tell the server which payment method the shopper clicked until surprisingly late in checkout, which quietly breaks most homegrown payment fee code.

We build and sell the OCM Labs Extra Fees module, which handles the technical half. The legal half is yours, and we will start there because it decides whether you should build this at all.

Is it legal to add a credit card surcharge?

In most US states, yes, within card-brand rules, but the rules are specific and they change. As of when we wrote this, the major card brands generally allow surcharging credit cards but not debit cards, require the surcharge to be disclosed before the sale completes and shown on the receipt, and cap it relative to your cost of acceptance. Some brands also expect advance notice to your acquirer before you start.

State law sits on top of that. A handful of states still restrict or prohibit credit card surcharges, several others regulate how they must be disclosed, and court decisions have shifted the map more than once over the past decade. We are Magento developers, not lawyers: before turning any payment surcharge on, verify current law in the states you sell into, read your card-brand and processor agreements, and note that a "convenience fee" is a separate program with its own rules, not a synonym.

None of this applies to surcharging offline methods. A fee on cash on delivery or purchase orders is a business decision, not a card-brand matter.

How do you add a surcharge by payment method in Magento 2?

With the OCM Labs Extra Fees module for Magento 2, a payment surcharge is one fee record with one condition: Payment Method Is the method's code. Create the fee under Sales > Extra Fees > Manage Fees, pick fixed or percentage, add the condition, and the fee appears as its own labeled line in the checkout totals once the shopper selects that method.

The payment method condition matches on the method code: checkmo for check or money order, cashondelivery for cash on delivery, and whatever code your card gateway registers. The condition supports Is and Is Not, so you can charge a fee for one specific method or for everything except your preferred one.

One behavior to know, and it is deliberate: payment and shipping conditions never match on an incomplete cart. Until the shopper actually selects a payment method, the condition resolves to empty and the fee stays off, so nothing shows on the cart page and nothing fires prematurely. The fee appears at the payment step, when the choice exists. The full condition reference is in the fees and conditions docs.

Why custom payment fee code usually breaks

If you write this yourself, the collector side looks easy:

$method = $quote->getPayment()->getMethod();
if ($method !== 'cashondelivery') {
    return $this;
}
// add the fee to the totals

That code is correct, and it will still fail in checkout, because during checkout getMethod() returns nothing. When a shopper clicks a payment method radio button, Luma's checkout stores the selection in client-side checkout data. The server does not hear about it until payment information is saved, which for most methods happens when the shopper hits Place Order. Your collector runs, sees no payment method on the quote, and skips the fee, right up until the order is placed with the fee suddenly on it. Shoppers reasonably read that as being charged something they never saw.

The fix is frontend work: a JS mixin on the payment selection action that pushes the chosen method to the server and triggers a totals recollection, so the collector runs again with real data. That mixin, plus handling the totals refresh without breaking other checkout steps, is where "a 3% card fee" stops being an afternoon. It is the single most common reason we see homegrown payment fees abandoned half-finished; we covered the rest of the build-vs-buy math in custom code vs extension for Magento 2 fees.

How do you add a fee by shipping method?

Same pattern: one fee, one condition, Shipping Method Is the carrier and method code in carrier_method format, for example flatrate_flatrate. This is how you attach a real cost to a specific delivery option without burying it in the shipping rate, so the shopper sees "Express Processing Fee" as its own line instead of wondering why express shipping costs what it does.

Like payment conditions, shipping method conditions resolve only after the shopper has picked a method, and never on a virtual-only cart. Shipping country, region, and postcode conditions are also available, which covers remote area surcharges: Shipping Country Is US AND Shipping Postcode Is a specific code, or region-level rules like a fee on shipments to Alaska and Hawaii.

How do you charge fees by customer group?

Add a Customer Group condition. Is and Is Not both work, so the two common setups are both one rule each: a fee that only wholesale accounts pay, or a fee everyone pays except a specific group. Conditions mix freely, so "wholesale accounts paying by check on orders under $500" is Customer Group Is Wholesale AND Payment Method Is checkmo AND Cart Subtotal < 500 on a single fee.

The AND/OR toggle applies across the whole condition set. One thing to keep straight from the docs: under AND, each condition must be satisfied somewhere in the cart, but a single item does not need to satisfy all of them at once.

Percentage surcharges, and what the percentage is based on

A percentage fee in the module computes from the pre-discount, tax-exclusive row totals of the matching items, not from the order grand total. Shipping and tax are not in the base. If your card agreement caps a surcharge as a percentage of the transaction, do that comparison deliberately rather than assuming the bases match.

Percentage fees also take optional minimum and maximum caps in base currency. A 3% fee capped at $20 stays a 3% fee until the cart gets big, then stops growing. Caps are clamped after the percentage is calculated, and fixed fees ignore the cap fields entirely, since their amount is already exact. Enter percentages as whole numbers: 3 means 3%, not 0.03.

Keep surcharges from stacking by accident

Every fee whose conditions match will fire, each on its own line. There is no priority system and no conflict resolution, which is predictable but unforgiving: if you create a card surcharge and a separate small order fee, a small cart paid by card gets both lines. That is often exactly right, and occasionally an accident. Review conditions as a set whenever you add a fee, and use Is Not conditions to carve out overlaps you do not want.

If your fees are driven by what is in the cart rather than how it is paid or shipped, that is a different setup, and we wrote it up separately: handling fees for hazmat, oversized, and cold-chain products.

What this costs

The OCM Labs Extra Fees module is $250 for Magento Open Source and $500 for Adobe Commerce, sold directly from our store. Version 1.1.0 runs on Magento 2.4.7 to 2.4.8, PHP 8.3+, Luma and Hyva. Every surcharge described in this post is a fee record plus conditions; none of it needs code. The rest of our catalog is on the Magento extensions page.