B2B NET 30 / Net Terms Payment for Magento 2

Key Features

Custom Magento 2 payment method 'Net Terms / Invoice' registered via payment.xml, di.xml and a MethodInterface provider — appears at checkout for eligible buyers only

NET 30/60/90 (and custom day-count) terms assigned per Magento customer group, configurable in system.xml under Stores → Configuration

Per-customer credit limits with a live running balance entity (own model, resource model, repository and service contract)

Server-side credit enforcement in the payment method's isAvailable() plus a sales_order_place_before observer so limits can't be bypassed from the front-end

Automatic due-date calculation stamped on the order and invoice based on the buyer's term window

Cron-driven reminder engine: pre-due and overdue email notifications via transactional email templates

Overdue monitoring dashboard with an ACL-protected admin grid of outstanding invoices, aging buckets and balances

Buyer self-service net-terms application flow: front-end request form feeding an admin approval queue

Credit balance and outstanding-invoice data exposed over REST and GraphQL via service-contract interfaces for ERP/headless integration

Admin approve/decline/adjust-limit actions with full ACL resources (Ecosire_NetTerms::manage) and action logging

Works on Magento Open Source and Adobe Commerce; coexists with Adobe Commerce B2B without conflicting payment routing

Configurable per store view and website — different terms and limits across multi-store B2B brands

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Magento 2.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

B2B wholesalers and distributors rarely collect cash at checkout — they ship on credit and invoice on NET 30/60/90 terms. Magento Open Source and Adobe Commerce ship no native deferred-terms payment method, and Adobe Commerce's B2B "Payment on Account" is gated behind the Commerce license and offers limited credit governance. This extension closes that gap.

ECOSIRE builds a dedicated payment method module under app/code/Ecosire/NetTerms that registers a custom \Magento\Payment\Model\Method\AbstractMethod-style gateway (modern Magento\Payment\Model\MethodInterface via a payment provider in payment.xml + di.xml). At checkout it appears as "Net Terms / Invoice" — selectable only when the logged-in customer's customer group is term-eligible and their available credit covers the cart, enforced server-side in the method's isAvailable() and validated again in a sales_order_place_before observer so the limit can never be bypassed from the front-end.

What you get: configurable NET 30/60/90 windows per customer group, per-customer credit limits and live running balances (a custom entity with its own repository and service contract), automatic due-date calculation stamped onto the order/invoice, a cron-driven reminder + overdue monitor that emails buyers before and after the due date, and a buyer net-terms application flow (front-end form → admin approval queue with ACL-protected grid).

Balances are exposed through service contracts (Api/, Api/Data/ interfaces) and surfaced over REST and GraphQL so your headless storefront or ERP can read remaining credit and outstanding invoices. Everything is admin-configurable under Stores → Configuration with proper system.xml, ACL resources, and admin grids.

This is built to order — not an instant Marketplace download. ECOSIRE scopes it to your exact Magento version, theme, customer-group taxonomy, and any ERP/accounting sync, then installs and tests it on your environment.

What you get

Installable Magento 2 module (Ecosire_NetTerms) under app/code, composer-installable, with registration.php and module.xml pinned to your Magento version

Custom payment method, system.xml configuration, ACL (acl.xml) resources and admin grids

Database schema via db_schema.xml for credit limits, balances, terms and application records, with data/schema patches

Cron job definitions (crontab.xml) for the reminder and overdue-monitoring engine

REST + GraphQL endpoints with documented service-contract interfaces (Api/ and Api/Data/)

Transactional email templates for pre-due reminders and overdue notices, across your enabled store views

Installation and configuration on your staging then production environment, including setup:upgrade and di:compile validation

Admin user guide plus a short handover walkthrough for your finance/operations team

Who this is for

B2B Wholesaler Selling on Credit

Ships bulk orders to repeat trade customers and needs them to check out on NET 30/60 without paying upfront, while keeping each account inside an approved credit limit.

Distributor with Tiered Accounts

Runs different customer groups (new vs. established dealers) and wants term length and credit ceiling to vary automatically by group, with overdue accounts flagged before they become bad debt.

Finance / Accounts-Receivable Manager

Needs accurate due dates, automated reminders, an aging view of outstanding invoices, and the ability to approve or freeze a buyer's credit from the Magento admin without touching code.

How B2B NET 30 / Net Terms Payment for Magento 2 Compares

Criterion	ECOSIRE	Custom Build	Competitor
Deferred NET 30/60/90 payment method at checkout	Included	Partial support	Included
Per-customer credit limits with live running balance	Included	Partial support	Partial support
Terms varied automatically by customer group	Included	Partial support	Partial support
Cron-driven pre-due + overdue email reminders	Included	Partial support	Partial support
Built, installed and supported on your store by the vendor	Included	Partial support	Not included
Tailored to your Magento version, theme and ERP sync	Included	Included	Not included
REST + GraphQL credit/balance data for headless or ERP	Included	Partial support	Partial support
Available on Magento Open Source (no Commerce license required)	Included	Included	Partial support

Frequently Asked Questions about B2B NET 30 / Net Terms Payment for Magento 2

How long does delivery take, and what's the process?

Because this is built to order, ECOSIRE first scopes the work against your exact Magento version, customer-group structure, and any ERP/accounting sync. A standard build typically takes 2–4 weeks from approved scope: development on our environment, deployment to your staging for sign-off, then installation on production with setup:upgrade and setup:di:compile validated. Complex multi-store or ERP-integrated builds may take longer, and we confirm the timeline in writing before starting.

Is this an instant download from the Adobe Commerce Marketplace?

No. It is a custom module ECOSIRE builds, installs, and tests on your Magento install — not a one-click Marketplace purchase. You receive the full source under app/code (composer-installable) plus installation on your environment. This lets us tailor the credit logic, terms, and integrations to how your business actually invoices.

What about ongoing support and updates after launch?

Your purchase includes a warranty period for defect fixes after handover. Beyond that, ECOSIRE offers optional support and maintenance covering Magento minor-version compatibility, patch testing, and enhancements. Because you own the source, you are never locked in — but we recommend a support arrangement so the module stays compatible as you upgrade Magento.

Does it work on Magento Open Source as well as Adobe Commerce?

Yes. The module is built on standard Magento 2 framework APIs (payment methods, service contracts, observers, cron, GraphQL) so it runs on both Magento Open Source and Adobe Commerce. If you already use Adobe Commerce B2B, we configure it to coexist with B2B features rather than conflict with payment routing or company accounts.

How are credit limits enforced so a buyer can't overspend?

Enforcement is server-side, not just UI. The payment method's isAvailable() check hides Net Terms when available credit is insufficient, and a sales_order_place_before observer re-validates the cart total against the live balance at order placement — so the limit holds even against direct API or tampered front-end requests. Balances update on invoice and on payment, and admins can adjust or freeze a limit anytime from the ACL-protected admin grid.