The Active eCommerce Offline Payment Add-on Add-ons extension lets a store built on Active eCommerce CMS accept bank transfers, cheques, cash deposits and other manual payments, with an admin approval step before any order is treated as paid. It is a companion module, not a standalone script: the core CMS must already be installed. Store owners in markets where card and wallet gateways are unreliable, or where buyers simply prefer bank deposit, are the natural audience.
ActiveITzone sells the add-on on CodeCanyon for $25. At the time of writing it has 1,785 sales and a 4.39 out of 5 rating across 33 reviews, which is a reasonable signal of maturity for a niche extension. The developer has kept it in step with the parent CMS through several major versions, most recently in July 2026.
What the Active eCommerce Offline Payment Add-on Add-ons module actually does
The core idea is simple and well executed: checkout gains a set of manual payment options alongside whatever online gateways are configured. A shopper picks one, sees the instructions the store has written for that method, completes the transfer outside the site, then returns to submit a transaction reference and, optionally, a screenshot. The order sits in a pending state until an administrator reviews the proof and approves or rejects it. Nothing is marked paid automatically, which is the correct default for money that arrives by bank rail.
Payment methods are defined by the store, not the developer
Administrators can create an unlimited number of offline methods from the admin panel, each with its own name, thumbnail and step-by-step instructions. That covers bank transfer, cheque, cash on deposit, mobile money handled manually, or anything regional the store needs. Multiple bank accounts can sit under a single method, so a buyer can pick the branch or currency that suits them rather than emailing to ask where to send funds. Clear instructions per method are the least glamorous feature here and probably the one that removes the most support tickets.
Offline payment reaches well beyond product checkout
This is where the add-on earns its price. Manual payment is wired into several parts of the CMS, not just the cart:
- Wallet top-ups. Customers can request a wallet recharge by offline method, and admins can also credit a wallet directly once money has landed externally.
- Order repayment. An unpaid order can be settled later without cancelling and rebuilding it, which matters for wholesale or high-value baskets where buyers take a day or two to arrange a transfer.
- Seller packages. Vendors on a multi-seller setup can upgrade their subscription plan by manual payment, so monetisation does not stall when no online gateway is available.
- Customer packages. Classified and package-based business models get the same treatment.
- Refund payouts. Since version 1.7, customers can request a refund through an offline method and admins can send the money back manually and record it.
Refund and preset-method features depend on the separate Active eCommerce Refund Add-on at a stated minimum version. The vendor lists those version requirements in the changelog, and buyers should read them before assuming the refund path works out of the box.
Administrative control and visibility
Every manual payment lands in a dedicated panel where staff can see the transaction reference, the uploaded proof and the order it belongs to, then approve or decline. Because pending payments are held rather than applied, accounting errors and fraudulent claims are caught before they affect stock or revenue. Later releases moved wallet requests to AJAX loading with separate tabs in both the admin and seller panels, which makes longer approval queues easier to work through.
Where this add-on fits, and where it does not
The clearest fit is a store selling into a region where card acceptance is patchy, expensive or simply not trusted by buyers. Bank transfer remains the default B2B settlement method in many markets, and a shop that cannot record one loses the sale. The same logic applies to grocery and wholesale operations taking large orders, to classified marketplaces selling package placements, and to any multi-seller store whose vendors pay for plans.
It also suits stores that already take bank transfers informally and want the process inside the CMS rather than in email threads and spreadsheets. Reconciliation improves immediately once every claim is tied to an order and an approver.
The wrong choice is a store that only accepts instant online payment and wants orders fulfilled automatically. Manual approval is a deliberate bottleneck: someone has to log in, check the bank statement and click approve. A high-volume, low-ticket shop with hundreds of small orders a day will find that workflow unmanageable and should stay with a gateway. Anyone not already running Active eCommerce CMS should also stop here, because the add-on has no independent installation path.
Strengths and limitations in plain terms
Strengths
- Genuinely broad coverage: checkout, wallets, repayments, seller and customer packages, and refunds all share one manual payment engine.
- Approval-first design keeps unpaid orders out of fulfilment until a human confirms the money arrived.
- Unlimited custom methods with per-method instructions and thumbnails, so regional and niche payment habits are easy to accommodate.
- Multiple bank accounts per method reduces friction for buyers in different banks or currencies.
- A long, documented changelog with explicit CMS version compatibility, which is more than many CodeCanyon add-ons provide.
- Low price relative to the scope, and source files are included (JavaScript, JSON, HTML, PHP and SQL).
Limitations
- It is inert without Active eCommerce CMS. The $25 buys an extension, not a storefront, and the parent CMS is a separate purchase.
- Verification is entirely manual. There is no automatic bank feed, no reconciliation API and no way to confirm a transfer without a staff member checking it.
- The refund and preset-method features are gated behind a separate Refund Add-on at specific minimum versions, so the advertised feature set is conditional.
- Declared compatibility is PHP 7.x and Laravel. Stores on PHP 8 have no stated support, and the vendor does not list a tested PHP 8 version.
- Only 33 reviews underpin the 4.39 rating, so the sample is small enough that individual experiences may vary more than the score suggests.
- The listing marks high-resolution assets as not included, which is a minor point but relevant if branded payment icons matter.
How it compares with the alternatives
The realistic alternatives are three. The first is a dedicated offline or manual payment plugin for a different platform, which is only relevant if the store is not on Active eCommerce CMS at all. The second is a general-purpose form or invoice tool bolted onto the site, which handles the instruction side but leaves orders, wallets and packages disconnected from the payment record. The third is custom development against the CMS, which can match any workflow but costs far more than $25 and needs maintenance at every core upgrade.
Against those, this add-on wins on integration depth. Because it hooks into the CMS natively, offline payment behaves consistently across checkout, wallet, package and refund flows rather than being a checkout-only patch. It loses on automation: a standalone gateway integration or a bank API would confirm funds without human review, and this module never will. For stores where manual verification is acceptable, the trade is clearly favourable. For stores that need instant settlement, no offline add-on of any kind is the right answer.
Frequently Asked Questions
Do I need Active eCommerce CMS to use this add-on?
Yes. The add-on is an extension for Active eCommerce CMS and cannot run on its own. The CMS must be installed on the server first, then the add-on is uploaded through the CMS add-on manager. Budget for the CMS licence separately, since the $25 price covers only the offline payment module.
How does a customer prove they have paid by bank transfer?
The customer submits a transaction ID and can attach a screenshot after completing the transfer. The order stays pending until an administrator opens the payment record, checks the details against the bank statement, and approves or rejects it. The vendor does not state any automated bank verification, so a staff member always performs the final check.
Can offline payment be used for wallet top-ups and seller packages?
Yes. Beyond product checkout, the module covers wallet recharge requests, repayment of unpaid orders, seller package upgrades and customer package purchases. Administrators can also credit a wallet directly once an external payment has been confirmed. This breadth is the main reason the add-on is worth considering over a checkout-only workaround.
Is the add-on compatible with PHP 8?
The vendor declares PHP 7.x and the Laravel framework as the supported stack. No PHP 8 compatibility is stated in the product data, so stores running newer PHP versions should confirm with the developer before purchase. The changelog tracks CMS versions carefully, which suggests compatibility updates are handled, but the PHP ceiling is not documented.
Verdict on the Active eCommerce Offline Payment Add-on Add-ons extension
Buy this if the store already runs Active eCommerce CMS and needs to accept bank transfers, cheques or other manual payments across checkout, wallets, packages and refunds without building custom code. The approval workflow is sound, the method configuration is flexible, and the price is modest for the surface area covered. Skip it if orders must be fulfilled automatically, if the shop is not on this CMS, or if the team cannot spare someone to verify payments daily. The conditional dependency on the Refund Add-on and the unstated PHP 8 support are the two details worth checking against a specific setup before paying.
