If your business already has dependable supply and your team will set prices, handle orders and own the after-sales process, start by evaluating a retailer-operated online store. A multi-vendor marketplace makes more sense when your strength is bringing independent sellers together and you have people to manage seller onboarding, fulfillment standards and reconciliation. Choose the responsibilities you can operate before choosing the software.
“Multi-vendor marketplace” here means building and operating your own platform for other sellers. It does not mean opening a seller account on Mercado Livre or another existing marketplace. The scope is physical-goods ecommerce serving consumers in Brazil; cross-border imports, tax treatment and product-specific eligibility need separate assessment.
Decide whether you sell products or coordinate sellers
In a retailer-operated store, your business is the seller and manages the catalog and customer orders. You may hold stock or arrange supplier fulfillment. A supplier shipping directly to the customer does not, by itself, turn the business into a multi-vendor marketplace.
In a marketplace, different sellers trade through a shared storefront. Before buying software, define what sellers can change, what the operator approves and who handles stockouts, delays and refunds. Centralized warehousing or customer service can be part of the arrangement, but the seller agreement and operational workflow must reflect it.
Both models require customer acquisition. Creating a new marketplace does not give it the existing audience of an established third-party platform. You must validate buyer demand as well as sellers' willingness to participate consistently.
Compare five responsibilities before comparing features
Allocate operational responsibilities before selecting features. This is a conceptual comparison, not a claim about a particular product's capabilities.
Supply and catalog: A retailer needs purchasing, product records, pricing and listing controls. A marketplace also needs seller onboarding, listing review and rules for presenting offers when several sellers sell the same item.
Inventory and fulfillment: A retailer needs available stock, reservations and dispatch records. A marketplace must distinguish inventory sources, delivery commitments and stockout responsibility by seller. One combined stock total can conceal important differences.
Orders and access: A retailer's team generally handles the sales orders. A marketplace needs clear parent and seller-order relationships and access boundaries. Seller A should not see Seller B's customer orders or settlement information.
Payments and settlement: A retailer reconciles receipts, fees and refunds. A marketplace also needs commission rules, payment-fee allocation, seller receivables and adjustments after refunds. A “pending settlement” entry is not evidence that the payment provider has released the funds.
After-sales and disputes: A retailer follows its own returns process. A marketplace additionally needs seller response deadlines, operator intervention rules and supporting evidence. Giving a buyer the seller's contact details should not automatically close the operator's support case.
These are procurement checks, not promises about an individual application. For example, VTEX's marketplace and seller architecture separates storefront and checkout responsibilities from supply and fulfillment and calls for agreements between the parties. With any other software, ask how the agreed responsibilities become permissions and workflows.
Validate payment scope for the Brazilian operation
“Supports Brazilian payments” does not establish that an application can operate a marketplace. Check payment acceptance, split payments, actual release of seller funds and refunds separately. Confirm the operating entity, seller accounts, payment methods and service agreements that apply.
For example, Mercado Pago Brazil's Split 1:1 prerequisites include seller identity checks and authorization. Its 1:N model requires engagement with its commercial team. A claim of “Mercado Pago support” therefore does not prove unrestricted seller onboarding or payment splitting among any number of recipients.
Its split-payment integration documentation also describes a limitation on full refunds in the 1:1 model when the seller lacks sufficient balance. Ask how the software records, escalates and resolves this situation, rather than accepting a successful-payment screen as the entire demonstration.
For localization, test the Portuguese buyer journey, Brazilian real amounts and decimal formatting, addresses and delivery coverage. Check how seller records and financial documents reach the local operations and accounting teams. Payment-method eligibility needs its own verification; a payment button alone does not demonstrate a localized operating process.
Test one order involving two sellers
Use a demonstration order with an item from Seller A priced at R$120 and an item from Seller B priced at R$80. Exclude shipping and other charges for this test. A ships normally; B must cancel because stock is unavailable. These are test amounts, not actual transactions or a quotation.
For a retailer-operated store, clarify whether your business is the seller of both items. Check how it cancels the unavailable item, continues fulfillment of the other item and links the refund to the original order. Having two suppliers may still be a retail operation.
For a marketplace, ask the provider to demonstrate these steps:
Before payment, the buyer can identify the sellers, delivery arrangements and order split. If a combined payment across sellers is unsupported, the interface clearly explains separate checkouts.
A and B each log in and see only the items and information they need. Authorized operator staff can review the overall progress.
B's cancellation does not incorrectly cancel A's shipment. The buyer can see the status of each item.
Staff can reconcile the R$80 refund request, its actual outcome, commission adjustments and changes to the seller receivable. Fee refunds follow the provider's rules and the agreement.
An unsuccessful refund or insufficient seller balance leaves an assigned, open exception. “Refund requested” is not displayed as “Refund completed.”
Record each result as available, configuration required, development required or unsupported, then include it in the delivery scope. This scenario exposes more useful differences than a long list of menu items.
Choose a starting model your team can operate
Favor a retailer-operated store when you have supply and an operating team and want to validate assortment, customer acquisition, delivery and repeat purchases. If recruiting sellers is not central to the business, establish the catalog-to-refund workflow before opening to independent merchants.
Favor a multi-vendor marketplace when committed sellers and a defined buyer segment already exist, and someone will own seller records, service quality, reconciliation discrepancies and disputes. Budget for training, ongoing review and exception handling as well as the software.
Consider a hybrid of own retail and third-party sellers only with explicit boundaries for the seller, stock, fees and after-sales responsibility of every item. Adding a seller login to a retail application is not necessarily enough. Ask how its order and settlement records support both models.
Bring a responsibility sheet to the quotation
Give providers your initial product scope, expected participating sellers, the seller of record for each type of sale, fulfillment and refund owners, and the exception-order example. Compare the storefront, seller portal, payment and logistics connections, migration, training and maintenance separately. Page count alone is a poor measure of operational complexity.
When discussing Brazilian ecommerce requirements with HUACODE, bring a sanitized responsibility sheet and target workflow. Establishing the business model and payment-provider eligibility first makes the delivery and acceptance criteria clearer than choosing a store package solely for its feature count.
Sources checked on 1 November 2026. Amounts and diagrams are demonstrations for evaluating a proposed solution. Confirm product capabilities through a demonstration and agreed delivery scope.