Send Again
Close
X
Login
Already have an account with us Login to your account
X
Sign Up
Create an account with Webkul Store
Please Login to Write Your Review
X
- Description
- Reviews
- FAQ
- Customers ()
- Specifications
- Cloud Hosting
- Changelog
Laravel Marketplace Order Accept Extension is an add-on to the Marketplace extension. This extension allows sellers to accept or reject orders within a specified time set by the admin.
With this feature, sellers can easily manage their orders by setting clear time-based boundaries for acceptance. If the seller does not respond within the allotted time, the order is automatically canceled to ensure that customers aren’t left waiting and to maintain an efficient order processing workflow.
Note -This module is an add-on of the Marketplace Module. To use this module, you must have Laravel Multi Vendor Marketplace installed first.
Highlighted Features of Laravel Marketplace Order Accept
Enable/Disable Module
The admin can enable or disable the Laravel Marketplace Order Accept module anytime from the backend.
Order Notification Settings
Admin can enable or disable order notifications for customers, sellers, and themselves.
Set TurnAround Time
Admin can define the TurnAround Time (in days) after which the order will get auto-cancelled if not accepted.
Seller Order Approval
Sellers have the ability to accept or cancel customer orders based on availability or other criteria.
Why Do We Need Laravel Marketplace Order Accept?
Laravel Marketplace Order Accept is needed to give individual vendors control over their part of a customer’s order. In a multi-vendor marketplace, it allows each seller to review, confirm, or reject orders before processing.
This ensures accurate inventory handling, reduces fulfillment errors, supports partial order management, and improves communication between sellers, customers, and admins.
Also, if you are looking for an extension that allows the customers to return and replace the products that have been ordered by them by creating an RMA request, then checkout Laravel eCommerce Marketplace RMA extension.
Module Configuration
You can easily configure this module. To do so, go to Admin Configuration and click on OrderAccept. From this section, the admin can manage all the available functionalities.
- Enable or disable the module.
- Enable Notify Admin for order notification.
- Enable Notify Customer for order notification.
- Enable Notify Seller for order notification.
- Enable “Cancel After Accept” option.
- Set TurnAround Time (TAT) in days.
Accept or Reject Order
Once the customer places an order, the seller has the option to accept or cancel the order as per stock availability or other factors.
- Seller can accept the order.
- Seller can cancel the order.
Accept Customer Order
If the seller accepts the order, they can proceed to complete the order operations like invoice creation and shipment.
- Can create invoice.
- Can create shipment.
Cancel Order
The seller can cancel the order manually, or the system will auto-cancel it after the turnaround time (TAT) set by the admin.
- Seller can cancel the order.
- Order is automatically canceled after the set TAT.
Support
For any issue related to this module, please create a support ticket or send an email to [email protected]. You may also check our quality Bagisto Extensions.
Specifications
Product Version2.4.10.0
Released1 year ago
CategoryBagisto Laravel, Marketplace,
Last UpdatedSeptember 9, 2026 (17 days ago)
License Single application
Supported Versions2.4.x
Write a review
Frequently Asked Questions
Who can use Razorpay?
Any registered Indian business or individual with valid KYC can use Razorpay.
Does Razorpay support international payments?
Yes, but merchants need to turn on international payments in their Razorpay dashboard.
Is Razorpay safe and secure?
Yes, Razorpay is secure and follows strict safety standards.
Does Razorpay provide a test mode for transactions?
Yes, Razorpay offers a test mode to simulate transactions before going live.
Can I integrate Razorpay with my e-commerce store?
Yes, Razorpay has plugins for Bagisto, WooCommerce, Magento, Shopify, and more.
How long does it take for Razorpay to settle payments?
Most payments settle within two business days.
Specification
Detailed technical features and requirements to help you understand the module’s capabilities and ensure smooth integration with your system.
Cloud Hosting
Detailed technical features and requirements to help you understand the module’s capabilities and ensure smooth integration with your system.
Move to Cloud Today
We’re partnered with top-tier, trusted providers!
Default Configuration Details of Server
1 GB
RAM 1 Core
Processor 30 GB
Hard Disk
RAM 1 Core
Processor 30 GB
Hard Disk
1 GB RAM & 1 Core Processor
Database
Database
Want to know more how exactly we are going to power up your eCommerce Website with Cloud to fasten up your store
* Server Configuration may vary as per application requirements.
Change Logs
- - Feature Add (+)
- - Feature remove (-)
- - Bug Fixed (!)
- - Modification (*)
Version 2.4.10.0
- + Compatible with Bagisto v2.4.10 and Bagisto Marketplace v2.4.10.0; bumped the module version to v2.4.10.0.
- * Normalised
marketplace-order-accept:installto the core Marketplace installer shape. The migration step now runs againstrealpath(__DIR__.'/../../Database/Migrations')with--realpath, resolving the module's own migrations regardless of the working directory or where the package is symlinked, in place of the hard codedpackages/Webkul/MarketplaceOrderAccept/src/Database/Migrationsrelative path. The command now seeds via$this->call(DatabaseSeeder::class), force publishes the provider's view overrides, runsoptimize:clear, and prints a newsrc/Templates/on-boarding.phpASCII welcome banner before the success message. - * No code change was needed for the upgrade. Every base class, event, template hook, and config key this module extends is unchanged in Marketplace v2.4.10.0, including the
DataGrids\{Admin,Seller}\Sales\OrderDataGridgrids and theirbindClasses()bindings, themarketplace.sales.order.save.after,marketplace.sales.order.cancel.after, andmarketplace.seller.update.afterlisteners, thebagisto.admin.marketplace.seller.edit.form.settings.afterandbagisto.seller.orders.view.actions.beforetemplate events, theseller/sales/orders/indexandadmin/marketplace/sales/orders/indexview overrides, and themarketplace.order-accept.general.*settings. None of the v2.4.10 core changes, including the 20 argument productImporter, theThemeCustomizationRepositorytoSectionRepositoryswap, the removed extension subsystem, or the renamedmarketplace.sales.seller.transaction.save.afterpayout event, touch this module's surface. - * Aligned
composer.jsonwith the core Marketplace package shape. The PSR 4 map keepssrc/, while the unusedextra.laravelauto discovery block, the deadautoload-devtest namespace, and the redundanttype,homepage, andprefer-stablekeys were dropped in favour of the manual provider registration documented in the README and CI. - * Bumped the GitLab CI base image to
webkul/bagisto:2.4.10and the Marketplace clone reference to the v2.4.10 line. - * Refreshed the README requirements to Bagisto v2.4.10 and Marketplace v2.4.10.0 and bumped the
marketplace-order-accept:versionconstant to v2.4.10.0.
Version 2.4.9.0
- + Compatible with Bagisto v2.4.9 and Marketplace v2.4.9.0. Marketplace moved its order datagrids under
DataGrids\{Admin,Seller}\Sales, re-parented the admin order screens underadmin.marketplace.sales.*, rebuilt the seller dashboard, and reorganised its admin configuration. Both grid subclasses and thebindClasses()bindings were repointed at the new base classes. Against an older Marketplace, the module now fails at class declaration time, before any route registers, so Marketplace must be upgraded first. - ! Fixed invoicing and shipping being blocked store wide while the module is switched off.
bindClasses()replaces the Marketplace order model unconditionally, but the listeners that stampacceptance_statusare gated on Status. On a disabled install, whereactiveseeds to0, no order was ever stamped andcanInvoice()andcanShip()refused every order for every seller. Each gate now asksisAcceptanceRequired()before refusing anything and delegates toparent::instead of re implementing the base fraud and quantity checks. With Status on, behaviour is unchanged. - ! Fixed the seller single order accept route being reachable without the permission.
Http\Middleware\Sellerenforces the seller ACL by route name and onlyseller.orders.mass_acceptancewas declared, so any signed in seller could accept an order by URL regardless of their role.Config/seller/acl.phpnow lists bothseller.orders.acceptandseller.orders.mass_acceptance, and the Accept button on the order view is gated onsales.orders.acceptlike the grid's mass action and checkboxes already were. - * Updated the admin orders override to publish to
resources/views/vendor/marketplace/admin/marketplace/sales/orders/index.blade.php, matching the base view's new name. At its old path, it overrode nothing. Both forked grids were re taken from Marketplace v2.4.9.0 core and carry only the acceptance status delta again, so they pick up the responsive card layout, pinned text action buttons, and new column groupings.marketplace-order-accept:installwrites the new file but cannot remove the old one; deleteresources/views/vendor/marketplace/admin/orders/index.blade.phpby hand. - - Removed the forked seller dashboard orders view. Marketplace v2.4.9.0 rebuilt the seller dashboard around overview and stock tiles and deleted
marketplace::seller.dashboard.orders, so the fork and its publish entry no longer overrode anything. Acceptance status is still shown and is now filterable on the seller and admin order grids. Delete the staleresources/views/vendor/marketplace/seller/dashboard/orders.blade.phpafter upgrading. - * Moved Configure → Marketplace → Order Accept to the end of the Marketplace configuration list. Marketplace v2.4.9.0 split its own configuration into eight sections sorted 1–8 and this module still claimed
sort => 2, colliding with Sellers. No stored setting changed; the config codes are stillmarketplace.order-accept.general.*. - + Added Awaiting to the acceptance status filter on both order grids. The column rendered the yellow Awaiting badge but offered only Accepted and Rejected in its filter, so there was no way to list the orders actually waiting on a seller. The admin grid also names the column in its header group, so it can be sorted.
- ! Fixed the
2024_12_18_132916_add_tat_time_column_in_marketplace_orders_tablemigration guarding onis_acceptedwhile adding and dropping the column actually namedacceptance_status, which leftdown()silently unable to drop it.up()behaves identically on a fresh database and the migration has already run everywhere else, so there is nothing to re run. - ! Fixed
Turnaround Time (in days]andEnter TAT in days (1-30]closing a parenthesis with a square bracket in 21 of the 22 locales. - * Completed localisation across all supported locales. The Awaiting acceptance status label shipped as the English string in all 21 non English locales, so the seller and admin grids showed one untranslated badge sitting between a translated Accepted and Rejected; it is now translated everywhere. The Bengali Rejected label also carried Devanagari Hindi text rather than Bengali and has been corrected. The package now matches the Admin package locale for locale, with the same 22 locales and every key present in each.
- * Retargeted the Playwright suite at the 2.4.9.0 panels. Configuration is applied across the new General, Products, and Sellers pages with the
marketplace[general][general][…]field names in place of the removedadmin/configuration/marketplace/settingsscreen. The seller product form is reached atseller/catalog/products/create, the admin Marketplace menu is walked through its new Sales level, and an order is opened through the grid's View Order action rather than a positional selector. AddedensureOrderAcceptConfiguration()so the seller specs enable the module themselves instead of depending on the admin spec having run first, and removed the remainingwaitForLoadState("networkidle")calls. - * Bumped the
marketplace-order-accept:versionconstant to v2.4.9.0.
Version 2.4.x
- + Added an Awaiting acceptance status.
acceptance_statusonmarketplace_ordersgains a third value and the order is stamped with it the moment it is placed, instead of stayingnulluntil the seller accepted or the order was cancelled. It renders as a yellow Awaiting label on the seller grid, the admin grid, and the dashboard widget, and the Accept button appears for bothawaitingorders and oldernullones. The invoice and ship gates still requireacceptedand the auto cancel query still keys offstatus = 'pending', so neither is affected. Fresh installs build the column fromAcceptanceStatus::values()and need nothing extra; an already migrated store must widen the enum by hand. SeeUPGRADE.md. - + Added a dedicated
sales.orders.acceptseller permission under Sales → Orders. The mass accept action and its row checkboxes were gated onorders.cancel, a key that does not exist in the seller ACL and so never matched a custom role. Seller roles keep their permissions as a JSON list and there is no data migration, so a seller on a custom role sees the Accept action only after the permission is granted by re saving the role. - + Added a separate e mail for orders cancelled after acceptance, because a timed out order and an order the seller had already accepted read very differently to a customer.
OrderCancelNotificationtakes anafterAcceptflag that swapssubjectandreason-to-*forsubject-after-acceptandreason-after-accept-to-*. Both variants exist for all three recipients in every locale. Recipients are still gated individually onnotify-admin,notify-customer, andnotify-seller, and the send still sits inside atry/catch report($e)so a mail failure never blocks the cancellation. - * Hardened
marketplace-order-accept:cancel-pending. It returns early unless the module is active, records whether the order had already been accepted before cancelling so the right e mail template goes out, and force syncs a seller order tocanceledandrejectedwhenOrderRepository::sellerCancelOrder()reports failure but the parent order has in fact moved tocanceled, instead of leaving it half cancelled. The command is still not registered in any scheduler by the package, so without a schedule entry, orders never auto cancel whatever the TAT is set to. - * Re synced the forked order views with Marketplace core, which had drifted from the base views they fork. The dashboard recent orders widget read
report.statistics['refunded']whileDashboard::getRecentOrders()returnsclosed, and the mismatch threw onundefined.lengthand blanked the whole widget. The admin grid showed arecord.shop_titlefield that no longer exists and an outdated actions block, while the seller grid was running on<x-shop::datagrid>instead of<x-marketplace::seller.datagrid>. - * Restored dark mode on the forked seller dashboard and seller orders views, which had lost the
dark:utility classes and, on the dashboard, the card wrapper and heading that Marketplace ships. - * Updated the seller dashboard's Pending, Processing, Completed, and Refunded tabs to sit in a single horizontally scrollable row instead of wrapping into a tall block on small screens. The desktop layout is unchanged.
- * Moved the admin system config from
src/Config/system.phptosrc/Config/admin/system.phpto match how Marketplace lays its own config out. The Configure → Order Accept page and everymarketplace.order-accept.*key are unchanged.
Version 2.4.4
- + Compatible with Bagisto v2.4.4
- ! Fixed the slugs passing across all module functionality.
- ! Fixed the seller datagrid to show in no seller cases also.
- + Added filtering via acceptance status across datagrids in admin as well as seller panel.
- + Added all the updated 22 lang files to module.
- + Enhancement: Mail dispatching when order is accepted by seller.
- ! Fixed the TAT visiblity by injecting it after setting form at admin panel.
- ! Fixed the updation of TAT in marketplace_sellers table.
- ! Fixed rejected and canceled status in seller_payout_status and acceptance_status.
- + Added migration to accept multiple acceptance status previously which was only for accepted.
- + Fixed the routes changed according marketplace for orders, transaction and payment requests.
Version 2.2.2
- + Compatible with bagisto version v2.2.2
- + Order status updates correctly for customer and admin after seller cancel.
- + Fixed exception on seller's Accept button click.
- + Accept button now disables after TAT expiry.
- + Fixed default seller TAT issue preventing admin TAT application.
- + Cancel button now hides after order cancellation via command.
