- A buyer fills a cart, but one supplier cannot confirm the final price immediately.
- The easy response is to move the conversation into email.
- The supplier sends a spreadsheet or PDF.
- For a property-procurement marketplace built on Medusa, that break in continuity was the real client problem.
The client problem
A buyer fills a cart, but one supplier cannot confirm the final price immediately. Freight depends on the property. Quantities may need adjustment. The buyer needs a formal quotation before committing.
The easy response is to move the conversation into email.
The supplier sends a spreadsheet or PDF. The buyer replies with changes. Somebody eventually copies the accepted lines back into the commerce platform and hopes the price, delivery choice, property and accounting information still agree.
For a property-procurement marketplace built on Medusa, that break in continuity was the real client problem. A quote could not be a decorative document beside the order lifecycle. It had to become a controlled commercial state inside it.
We implemented a quote journey in which seller-specific cart lines become a draft order, the supplier and buyer negotiate against that durable record, and an accepted quote can be converted into a Medusa order. The property, seller, item quantities and prices remain attached to the commerce path; line-level GL allocations are deliberately copied into the draft; a selected shipping option is priced and applied before conversion.
The goal was simple: negotiate without re-keying the transaction.
The client problem was the gap between negotiation and checkout
Standard ecommerce assumes that the catalogue price is ready when the buyer reaches the product page. Procurement is often different.
A supplier may quote a project quantity, confirm availability, change a unit price, add a promotion or propose a delivery charge for a particular site. The buyer may need to ask a question before accepting. The final agreement is not necessarily identical to the cart that started the discussion.
If that exchange happens outside the platform, several versions of the purchase begin to coexist:
- the original cart;
- the supplier's quotation;
- the buyer's accounting allocation;
- the delivery proposal;
- the order somebody finally enters.
Every copy creates an opportunity for drift. A quantity can be changed in one place but not another. A negotiated price can be lost when a fresh cart recalculates. A property can be selected in the storefront but omitted from the emailed document. A line split across GL accounts can disappear during manual entry.
The marketplace needed one commercial thread from request to order.
Start with the supplier's lines, not the whole cart
The buyer may have products from several suppliers in one cart. A request for quotation is addressed to one supplier, so the workflow first identifies the lines that belong to that seller.
It records their variant, quantity, current unit price, title and metadata, along with the cart's currency, region, customer and addresses. The current prices are also preserved as the original price reference for the quote.
Those seller lines become a Medusa draft order. The workflow links that draft to the seller and, when supplied, to the purchasing property and its organisation. If the cart does not yet have a shipping address, the property's address can provide the starting delivery context.
Once the draft and quote exist, the quoted lines are removed from the active cart. They are no longer ordinary cart lines waiting to be checked out at catalogue terms; they have entered a separate negotiation lifecycle.
This is an important marketplace boundary. The buyer can continue shopping, while the supplier-specific request now has a stable identity, its own state and a draft order that Medusa can later convert.
Make the quote a durable business object
The quote record is not just a status field on a cart.
It connects the draft order, seller, customer and property. It stores the original prices and tracks milestones such as when the supplier quoted, when the buyer accepted and when the quote expires. Its lifecycle distinguishes pending supplier work, quoted, accepted, converted, rejected by either party and cancelled.
That state model answers operational questions that an email inbox cannot answer reliably:
- Is the supplier still preparing the quote?
- Has a proposal actually been sent to the buyer?
- Did the buyer accept or reject it?
- Is the quote still eligible for checkout?
- Has it already become an order?
Only the appropriate transitions should be available in each state. The supplier can edit while the quote is pending or quoted. Conversion requires an accepted quote belonging to the authenticated buyer. Once conversion is complete, the quote reaches a terminal converted state.
The platform can therefore show both parties the same commercial position without asking them to interpret the latest attachment in a message thread.
Let the supplier negotiate against a Medusa draft order
The supplier needs to change commercial terms without creating an unrelated replacement record.
The Vendor API loads the quote inside the authenticated seller context, verifies that the quote belongs to that supplier and checks that its current state remains editable. Price updates are limited to line-item IDs that are actually present on the quote's draft order, and negative or malformed prices are rejected.
The platform also supports draft-order edit actions for item changes, promotions and shipping choices. These operations use Medusa's draft-order and order-edit capabilities as the transactional foundation rather than maintaining a second homemade basket model.
Each edit can produce an activity entry containing the quote, seller, acting member, action type and relevant payload. That gives the interface a meaningful history of price or item changes instead of silently replacing the previous proposal.
Medusa is valuable here because the object being negotiated is already shaped like the future order. The marketplace adds the supplier workflow and audit trail; it does not need to invent another order engine and reconcile it later.
Keep the buyer–supplier discussion beside the quote
Commercial negotiation is not only numbers.
The buyer may ask whether an alternative is available. The supplier may explain a lead time or why a quantity changed. Those messages need the same access boundaries as the quote itself.
We modelled comments as insert-only quote messages with an explicit author type. Buyer comments carry the authenticated customer identity. Supplier comments carry the seller and, where relevant, the team member. Both sides retrieve the discussion through quote-scoped routes that verify ownership.
The result is a conversation attached to the commercial object it explains. An operator does not have to assemble the story from an email chain, a cart and a later order.
After the quote is converted, new comments are disabled and the thread becomes read-only. That protects the meaning of the negotiation record. The parties can see what led to the order, but a new message cannot make it appear that the accepted commercial agreement changed after conversion.
The order has its own operational lifecycle from that point onward.
Preserve the property and its accounting intent
In property procurement, “who is buying?” is not answered by the customer email alone.
The quote is associated with the property for which the goods are being requested. Shipping-option discovery uses the quote's property context rather than blindly using whichever property happens to be active in the buyer's storefront later. Tests cover that distinction, including the fallback for older quotes without a property link.
Line-level accounting context also matters. A buyer may have divided one cart line across several GL accounts before asking for a quote. Creating a fresh draft order can otherwise lose those allocations even if the visible product and quantity survive.
The quote workflow therefore copies the line-level allocation metadata from each source cart item to the matching draft-order line and its order-item detail. Matching prefers the variant identity and falls back to the title where required; repeated matching keys are consumed in sequence rather than reusing one source allocation indefinitely.
This continuity is explicitly tested. It means negotiation changes the commercial proposal without casually erasing the buyer's accounting intent.
The allocation still has to satisfy the platform's completeness rules at checkout. Carrying it forward is not the same as accepting invalid accounting data.
Make acceptance different from conversion
Accepting a quote and placing an order are related decisions, but they are not identical.
Acceptance records that the buyer agrees with the supplier's proposal. Conversion is the commerce operation that turns the draft into a pending Medusa order. Keeping those moments separate lets the platform validate whether checkout is currently allowed.
Before conversion, the workflow verifies that:
- the quote exists;
- it belongs to the authenticated customer;
- its status is accepted;
- the property-credit and approval rules required by the marketplace are satisfied.
That prevents a person from converting another buyer's quote or bypassing negotiation by calling checkout while the supplier is still preparing it.
The approval layer can also intercept the request. If the organisation's spend rules require approval, checkout returns an approval request instead of creating the order immediately. The accepted supplier price remains connected to a separate buyer-governance decision.
This is how two business controls coexist: the supplier decides what it is willing to sell for, and the buying organisation decides who may commit the spend.
Resolve delivery before the draft becomes an order
A quote may need a shipping option selected at checkout.
Draft orders do not resolve shipping prices through exactly the same calculated-price context as a normal cart. The conversion workflow therefore loads the draft currency and reads the selected shipping option's prices for that currency. Where several price rows exist, it prefers the most specific rule-bearing candidate.
It then opens a fresh Medusa draft-order edit, adds the shipping method with the resolved amount, requests the edit and confirms it. Only after that delivery action has been applied does it convert the draft order.
This sequence matters for the buyer. The order should not be created first and have an unrelated shipping charge patched onto it afterward. The accepted commercial context and selected delivery choice need to meet at the last controlled point before conversion.
If no shipping option is required, that edit path is skipped. The workflow does not add a fictional delivery action merely to make every quote look the same.
The resulting order can then enter normal marketplace operations with its seller link, property context, items, negotiated prices and applied shipping method.
Continue into payments and marketplace economics
Order conversion is the centre of this article, but it is not the end of checkout.
After Medusa converts the draft, the marketplace calculates the seller commission for the quote-driven order. This is necessary because the quote path does not pass through the regular split-cart event that normally initiates that calculation.
The checkout route also selects the requested payment type. For account-term purchasing, it can prepare the purchase-order provider path; for other configured modes, it selects the corresponding provider. Payment collection and payment status remain separate concerns from the fact that the quote became an order.
That separation prevents a dangerous shortcut: “accepted quote” does not mean “paid”. It means the negotiated draft is eligible to enter the order lifecycle. Payment authorisation, purchase-order validation, later confirmation and capture retain their own states and responsibilities.
The quote is finally marked converted so the same negotiation cannot be checked out as if it were still open.
Why Medusa was the right foundation
The client needed procurement negotiation without abandoning ecommerce operations.
Medusa already provided carts, draft orders, order edits, shipping methods, payment collections, orders and inventory reservation. We extended that foundation with a durable quote, seller and property relationships, a buyer–supplier discussion, accounting-allocation continuity and marketplace-specific approval and payment rules.
On a rigid platform, this workflow often becomes an external RFQ tool followed by manual order entry or a large collection of custom fields that never quite become a coherent lifecycle.
Medusa gave us a better architectural option: make negotiation a controlled path toward the native order rather than a document beside it.
That is why the platform choice matters to the business. Extensibility is not an abstract preference. It lets the client add the exact buying process its customers need while keeping pricing, delivery, payment and order operations on one commerce backbone.
A practical quote-to-order checklist
Before building RFQ into a Medusa marketplace, define:
- Is the request addressed to one seller or several?
- Which cart lines leave the cart when the quote is created?
- Are original prices retained for comparison?
- Does the quote have an explicit state machine?
- Are supplier edits applied to a Medusa draft order?
- Are edit actions attributable to the seller team member?
- Are buyer and supplier comments scoped to the quote?
- Which property owns the request and delivery context?
- Which line metadata, including GL allocations, must be copied deliberately?
- Can only the owning buyer convert an accepted quote?
- Can organisational approval pause checkout before order creation?
- How is the shipping price resolved for the draft currency?
- Which marketplace calculations must run because the normal cart path was bypassed?
- Does conversion close further edits and comments?
These questions expose the difference between generating a quotation and building a procurement capability.
The broader lesson
The client did not need another PDF generator.
They needed a supplier to negotiate price and delivery with a buyer, while the marketplace retained the seller, property, accounting intent and commercial history required to create the right order.
We made the quote a durable bridge between a seller-specific cart request and Medusa's order lifecycle. The supplier could shape the proposal. The buyer could discuss and accept it. Organisational approval could still intervene. Conversion applied delivery, created the order and closed the negotiation record.
The useful outcome was not merely “RFQ supported”. It was continuity: the transaction the buyer discussed became the transaction the platform could operate.