WooCommerce payment surcharges need 5 decisions before activation: contractual permission, calculation basis, tax treatment, customer disclosure and refund behaviour. A fee plugin can calculate an amount, but that capability does not establish that the business may impose it. The query also names Pay for Payment, so distinguish that plugin from similarly named payment gateways and fee extensions.
What does a payment-fee plugin actually control?
Confirm the intended product first. Pay for Payment is a fee-and-discount plugin described on WordPress.org. It is not itself a merchant account or a payment processor. The similarly named Pay. payment integration is a different product. A search result containing payment words is not enough to identify the software a store already uses; inspect the installed plugin name and developer.
Compare Pay for Payment with the separate Payment Gateway Based Fees extension. Both describe gateway-dependent adjustments, but their settings and limitations differ. The former documents negative adjustments as discounts; the latter documentation says negative values are not supported. This matters if the business intends to reward a chosen method rather than add a surcharge. Do not transfer features between products.
Obtain gateway-specific permission before configuring a charge. Merchant contracts and applicable rules may restrict surcharging, and a plugin developer is not the authority on your account agreement. Keep the exact permitted arrangement with your requirements. If permission remains unresolved, the defensible implementation state is inactive. Rewording a charge as handling does not establish that it is allowed under a contract or local law.
Define what the calculation applies to. Pay for Payment documents configurable inclusion of shipping, coupons and taxes in a percentage base. Those settings can change the result without changing the visible percentage field. Write the basis in ordinary language and have the responsible business person approve it. A test should compare the calculation against that statement, rather than merely checking that a fee appears.
Keep fixed, percentage and combined adjustments distinct in your comparison. Payment Gateway Based Fees also distinguishes adding a percentage from calculating an inclusive commission-style amount. These are mathematical choices, not interchangeable labels. Use actual approved commercial inputs in a private test fixture. This guide deliberately avoids public fee figures because no account-specific schedule or permitted surcharge has been established.
How should you evaluate disclosure and calculation?
Resolve tax treatment through the appropriate adviser and the applicable setup. Both opened product descriptions discuss tax-related configuration, but a selectable tax class is not a legal conclusion. Include the fee line in a test order and inspect the invoice representation. Check whether the configured basis and tax display agree with the approved business rule before considering the checkout ready.
Disclose the adjustment before the customer commits to paying. The fee label should explain the reason accurately, and the updated total should be visible when a different method is selected. Do not depend on a small note elsewhere on the website to explain an unexpected last-step change. Test the exact checkout screen and order confirmation, because an understandable cart can still lead to a confusing receipt.
Test switching away from the charged method. Any adjustment associated only with that method should be reconsidered when the selection changes. Repeat after applying a coupon, changing the delivery choice and returning from a cancelled payment. Record the expected total as well as the observed total. A fee that appears correctly once can still remain incorrectly attached after the basket changes.
Clarify refund and manual-order behaviour separately. Ask whether a refund includes the adjustment and how partial refunds are handled under the approved policy. Pay for Payment distinguishes some manual and pay-for-order features in its product tiers. Do not assume that a demonstration of ordinary checkout establishes the same behaviour for an administrator-created order or a later payment link.
Check the actual checkout architecture. Pay for Payment describes basic block-checkout support with limitations, while the other fee extension documents its own version-specific support. Test the installed versions and intended theme. Retain unresolved compatibility questions in the decision sheet; a generic compatible badge is weaker evidence than completing the business workflow with the exact extensions that alter the order.
Include a private reconciliation exercise after the checkout test. Give the responsible person the fictional order summary, the provider transaction record and the refund record. Ask them to explain the adjustment without opening the plugin settings. If the explanation depends on a hidden calculation basis or an ambiguous fee label, revise the implementation or the documentation. Keep the original expected result with the test evidence so later configuration changes can be checked against it. Also test an order without the adjustment: this confirms that the ordinary route remains understandable and that staff do not assume every difference between an order and a settlement is the same fee. No public commercial figure is needed for this exercise.
Decision worksheet
Original contribution: a surcharge permission-and-calculation record. Give each payment method its own row containing the authority for the charge, the approved formula, included basket components, tax decision, customer wording and refund rule. Add a separate column for observed behaviour. Run a fictional basket through selection, coupon change, shipping change, payment cancellation and refund. Keep the approved expectation unchanged while testing. Where a result differs, classify it as a calculation defect, an unclear business rule or a product limitation. This produces an actionable decision instead of an unexplained pass mark.
| Checkpoint | Evidence to retain | Decision or corrective action |
|---|---|---|
| Permission | Current merchant terms and business approval | Leave surcharge inactive when unresolved |
| Calculation | Approved base and adjustment formula | Compare against an independent worked order |
| Tax | Adviser-approved treatment and invoice example | Resolve inconsistent representation |
| Disclosure | Checkout, order summary and receipt | Remove surprising late changes |
| Refund | Full, partial and cancelled-order examples | Define adjustment handling explicitly |
Prefer the simplest arrangement that meets a verified business requirement. If the requirement is only to offer a payment method, a fee extension may add unnecessary decisions and failure paths. If a discount is intended, compare that capability directly rather than attempting to force a surcharge-only plugin into a different role. Product features can change; re-open the relevant documentation before implementation.
Read online payments for gateway context and WordPress for the store platform. To discuss a proposed checkout, get started with the adjustment rule and a redacted order example. Keep merchant agreements and sensitive account information out of an initial public enquiry.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.