From lot to shipment: the RFQ → order → payment flow

A buyer who has shortlisted an anonymized lot — evidence attached, EUDR tier visible, region visible at a coarse level — is still several steps from a shipment. Getting from that listing to a paid, confirmed order runs through two gates worth understanding before committing time to a lot: a request-for-quote a vendor has to actively accept before identity changes hands, and a payment step that runs in sandbox today rather than live settlement. Neither gate is hidden, but neither is obvious from a listing page alone. This is a walkthrough of the farm supply RFQ marketplace flow end to end — what a buyer controls at each stage, where the anonymization line sits, and where the platform is plain about what's live versus what's still being built out.

The path in outline

Stripped to its stages, the sequence a buyer moves through looks like this:

1. 1Submit a request-for-quote against a specific anonymized lot, with a quantity and a target price.
2. 2The vendor behind that lot reviews the request and responds — with a quote, a decline, or acceptance.
3. 3Acceptance is also the identity gate: the vendor's actual business name is revealed only at this point, not before.
4. 4The buyer proceeds to checkout, either against the listing directly or carrying the accepted RFQ's context forward.
5. 5Payment runs through M-Pesa's STK push, currently in sandbox; the order sits pending until a callback confirms it.
6. 6Once paid, the order is confirmed and, for inventory-backed lots, the underlying stock is decremented.

Each of those steps has a boundary worth understanding on its own, because the platform enforces real constraints at every one of them rather than treating the whole thing as a single checkout button.

Stage one: requesting a quote against an anonymized lot

An RFQ is filed against a specific listing, not a producer. The buyer supplies a quantity requested, a target price, and an optional message — the same three inputs a buyer would bring to any sourcing negotiation, just filed against a lot's evidence rather than a known counterparty. The listing has to be active and available when the request is filed; a request against a lot that's already been pulled or sold out is rejected before it goes anywhere. Once submitted, the request sits in an open state, visible only to the buyer who filed it and the vendor whose listing it targets. Other buyers browsing the same lot do not see that a request exists, and a buyer's own list of requests never surfaces anyone else's.

Stage two: what a vendor can do with an open request

On the vendor side, an open RFQ shows up scoped strictly to the listings that business actually owns — a vendor never sees requests filed against someone else's lots, and a request never crosses that boundary in either direction. A vendor responding to an open RFQ has three outcomes available: quote back a price and message without committing, accept the request outright, or decline it. A response can also carry a counter-price of the vendor's own choosing alongside a message, which is how a target price a buyer names in stage one turns into an actual back-and-forth rather than a single take-it-or-leave-it number. A declined request is terminal — there's no reopening a request a vendor has already turned down; a buyer who still wants that lot files a fresh one. Accepting is the meaningful branch, because acceptance is where the request stops being purely evidence-based and starts becoming a real counterparty relationship.

Stage three: acceptance is the identity gate

Before a vendor accepts, a buyer checking the details of their own RFQ gets back a simple flag: identity not yet revealed, along with the request's current status. That holds through the entire quoting back-and-forth. It is only once a vendor's response sets the request to accepted that the buyer's next lookup returns the vendor's actual business name and the specific tenant behind the listing — the entity a buyer would go on to contract with, invoice, and eventually take shipment details from. Every state before that is deliberately withheld, so a buyer can negotiate on the strength of a lot's documentation without either side committing to a named relationship before there's a real reason to.

An RFQ moves a listing from anonymized evidence to a named counterparty at exactly one point — the moment a vendor chooses to accept it, not a moment earlier.

One more mechanic sits at this exact gate, worth flagging honestly rather than glossing over: when a vendor accepts, that can trigger a platform handling-fee step on the vendor's side — a separate charge from anything the buyer pays at checkout, and not something a buyer needs to manage or track. It exists to keep acceptance a deliberate action on the vendor's side rather than a free, reversible toggle. It has no bearing on the buyer's own price, timeline, or checkout flow that follows.

Stage four: from an accepted request to a checkout

An order does not strictly require an RFQ. A buyer can check out directly against any active listing without ever filing a request first. But the more common path once negotiation has happened is to place an order that references the listing and, where one exists, the accepted RFQ tied to it — carrying that negotiated context into the transaction record rather than starting a checkout from a blank slate. What the platform does not do automatically is copy a vendor's quoted price into the order for the buyer. The buyer supplies the amount and currency at checkout directly, which means carrying forward whatever price was actually agreed during the RFQ exchange is on the buyer, not something the system infers for them. Lots are quoted in US dollars; because the payment rails settle in Kenyan shillings, an order priced in dollars is converted to shillings at the point of checkout. A checkout attempt against a listing that has since sold out or gone inactive is rejected before any payment step starts, the same guard that applies at the RFQ stage.

Stage five: payment — sandbox today, live for confirmed orders

Checkout runs through M-Pesa via Daraja, and it is worth stating plainly rather than implying otherwise: this runs in sandbox in v1. Production payment rails are the plan for RFQ-confirmed orders, not something already switched on for every transaction today. Placing an order triggers an STK push prompt to the buyer's phone; the order is created first in a pending payment state, and it stays pending until Daraja's callback confirms the charge went through. Only that confirmation flips the order to paid and its status to confirmed — there is no path that marks an order paid without a corresponding callback (or, in sandbox conditions, an explicit demo simulation clearly logged as such server-side). A callback that arrives for an order already marked paid is treated as a redelivery and ignored, so a buyer never sees a charge processed twice for the same order.

After payment: what a paid order actually triggers

Once an order reaches paid, two things happen behind the scenes that matter to a buyer even though neither is visible on the checkout screen. First, for lots backed by a tracked inventory record rather than a one-off batch, the quantity sold is decremented from that inventory the moment the order is confirmed — the mechanical start of the fulfillment side of the transaction, separate from the payment side. A lot that sells out this way is marked unavailable going forward, so the same stock can't be double-sold to a second buyer while a first order is settling. Second, a buyer's own order history only ever shows that buyer's own orders; there is no view, by design, where one buyer's purchase history is visible to another. Between the RFQ record and the order record, a buyer ends up with a full paper trail of a single transaction — request, response, acceptance, payment — without any of it being visible to another buyer on the same platform.

What's live, what's sandboxed — stated plainly

• RFQ creation, vendor response, and the identity-reveal gate are live mechanics, not a mockup — a buyer's request, a vendor's acceptance, and the resulting reveal all write real records today.
• Order creation, the pending → paid lifecycle, and inventory settlement on paid orders are live for the transaction record itself — an order genuinely exists, genuinely tracks state, and genuinely adjusts stock.
• The M-Pesa (Daraja) payment rail that moves money is running in sandbox in v1. Production settlement is the direction for RFQ-confirmed orders, not a claim about today's default. Do not read a confirmed order today as evidence of live money movement.
• A vendor-side handling fee can attach to RFQ acceptance. It is a separate mechanic from buyer checkout and is not something this piece quantifies — treat any specific figure as a vendor-facing detail outside a buyer's view, not a marketplace-wide price.

The practical takeaway

For a buyer, the useful mental model is: evidence first, identity second, payment third — and each of those is gated by a real state change, not a formality. Nothing about a lot's producer is visible until a vendor actively accepts a request, and nothing about a transaction is final until a payment callback actually confirms it. That ordering is deliberate rather than incidental. It lets a buyer do real due-diligence work — comparing lots, requesting quotes, negotiating price — before either side is locked into a named relationship, and it keeps the record honest about which parts of a transaction are settled today and which are still running through a sandbox rail on the way to production.

Buyers who want to see the request-for-quote flow against a real, evidence-backed lot can browse verified listings now. Vendors evaluating whether the platform fits their sales process can request buyer access to see the same flow from the other side.