Mobile money transfers carry a small sending charge. A shop can absorb it or pass it on, and both are defensible. What is not defensible is passing it on invisibly — letting the customer send the order total, then telling them afterwards that they are short by a few taka.
Make it a cart line, not a footnote
The fee is added as a real fee on the cart the moment that payment method is selected, and removed the moment another is chosen. It appears in the order summary above the total, with the payment brand named, so the number the customer is asked to send is the number they see.
The rate is a setting rather than a constant, because it changes and because the shop may decide to absorb part of it. Setting it to zero removes the line entirely, so “we cover the fee” is a configuration choice rather than a code change.
The condition that is easy to get wrong
A fee calculated without checking which payment method is currently selected will attach itself to every order, including the ones paying by another method entirely. The calculation is therefore gated on the session’s chosen method, and skipped in admin contexts where there is no customer session at all — otherwise a manually created order in the dashboard quietly picks up a surcharge nobody asked for.
Key takeaways
- If a fee exists, show it before the customer pays, named and itemised.
- Make the rate configurable — absorbing the fee should not require a deployment.
- Gate fee calculation on the selected payment method, or it applies to everything.
- Skip cart-fee logic in admin contexts where no customer session exists.
Related reading: manual bKash, Nagad and Rocket payments, and auto-selecting free shipping at a cart threshold.
Running into a similar limitation in your own WooCommerce or WordPress store? Let’s Talk — ArtinTech Solution builds exactly this kind of custom store tooling.