- A property group has already been approved to buy from a supplier.
- One property may have a long purchasing history.
- Granting credit to the customer login would flatten those differences.
- For a property-procurement marketplace built on Medusa, we implemented supplier credit approval at the property level.
The client problem
A property group has already been approved to buy from a supplier. Does that mean every building it manages should automatically receive the same payment terms?
Not necessarily.
One property may have a long purchasing history. Another may be newly acquired. A third may be managed under a different legal or accounting arrangement. The supplier may accept purchase orders for one location while requiring prepaid checkout for another.
Granting credit to the customer login would flatten those differences. Granting it to the organisation globally would still be too broad.
For a property-procurement marketplace built on Medusa, we implemented supplier credit approval at the property level. Each seller can publish its procedure, each buying organisation applies for the exact property concerned and the seller reviews that application before account terms become available for that relationship.
The platform coordinates the decision. It does not pretend to perform underwriting or calculate a credit limit.
The client problem was the wrong scope of trust
Most ecommerce payment settings are attached to a store, region or customer. That works when “the customer” is the complete commercial unit.
Property procurement has another layer.
The same organisation may represent hundreds of buildings, associations or managed entities. Buyers can share an account while purchases, invoices and liabilities remain property-specific. A seller deciding whether to extend terms may care about the receiving property's identity and address, not only the umbrella organisation.
A global switch such as customer.can_pay_by_po = true would create several problems:
- approval for one property would unlock all current properties;
- newly onboarded properties would inherit terms without review;
- the seller could not explain which location was approved;
- an old decision would not retain the application procedure the buyer followed;
- duplicate or concurrent applications could produce contradictory state.
We needed the unit of approval to match the unit of commercial responsibility.
Let each seller define how credit works
Not every supplier handles account terms the same way.
Some accept the platform's default behaviour. Others require prior approval and have their own instructions, external application URL or PDF form. The seller needs to publish that procedure before buyers can apply.
The credit policy therefore has two modes: default and prior approval. Prior approval points to an active, versioned procedure. Publishing a new procedure creates a new version rather than quietly rewriting the document behind existing applications.
The procedure may be represented by a controlled PDF or an external URL with instructions. PDF publication includes a content checksum so retries can identify the same command without trusting a transient file identifier.
This turns “contact the vendor for terms” into a product capability. The buyer sees the seller's current process in the same marketplace where the purchase will eventually occur.
Bind the application to seller, organisation and property
The application identity contains three business dimensions:
- the supplier deciding whether to offer terms;
- the organisation requesting them;
- the property that will use them.
That combination is more precise than a customer flag.
Before accepting a submission, the store route verifies that the supplier is selected by the organisation and that the property belongs to that organisation. A buyer cannot submit a property ID from another account or request terms from an unrelated marketplace seller.
The server then loads the seller's active policy and refuses the application if no prior-approval procedure is available.
These checks make the URL and interface convenient inputs, not sources of authority. The backend reconstructs the commercial relationship before creating the application.
Snapshot what the seller is being asked to approve
Organisation and property records can change over time.
A building may be renamed. Its external reference or address may be corrected. If an application displayed only live fields, the seller could later see different information from what it reviewed.
Each application stores snapshots of the organisation name, property name, property address and optional external property identity at submission time. It also stores the exact procedure version used.
This gives the decision a stable business context:
“The seller approved this property, presented under these details, using this procedure version.”
The snapshot does not replace the live property record. Checkout and operations still use current commerce data. It preserves the evidence behind the credit decision so later edits do not rewrite history.
Make submission safe to retry
Users double-click. Browsers retry. Networks time out after the server commits. A credit application must not become two pending decisions because the buyer did not receive the first response.
Submission requires an idempotency key and hashes the meaningful request payload. Inside a transaction, the workflow locks the seller policy and the seller–organisation–property application identity.
If the same key and request return, the existing result is replayed. If somebody reuses the key for different input, the mismatch is rejected rather than silently returning the wrong application.
Database constraints reinforce the business rules. The model permits at most one live submitted application for the relationship and at most one live approved application. That prevents two concurrent requests from creating parallel paths to contradictory approvals.
This is the right place for idempotency: around the business command, not only around the HTTP request.
Control when another application is allowed
Retrying the same application is different from applying again.
Before creating a new record, the domain rules inspect previous attempts for the seller, organisation and property. A live submitted request should not be duplicated. An existing approval should not be bypassed by opening another application.
A rejected application may have a different future depending on product policy, but that transition must be explicit rather than an accidental side effect of repeated POST requests.
This keeps the seller's review queue meaningful. One property appears as one current decision, not a stack of nearly identical submissions created by uncertain users.
For the buyer, the interface can show the current status and history for that exact property. They do not have to infer whether an organisation-wide approval includes it.
Keep review on the seller side
The supplier owns the credit decision.
Review therefore requires the application to belong to the seller making the decision. The workflow locks both the seller policy and the specific application before updating it.
Only a submitted application may move to approved or rejected. Repeating the same decision returns the existing result, while attempting a contradictory second decision produces a conflict. A conditional update protects against another reviewer changing the application between read and write.
The record stores who reviewed it, when and an optional decision note.
This produces a clean operational story. The buyer submits. The seller reviews. The marketplace records the decision and can use it when resolving available payment methods for that property.
No administrator needs to impersonate a payment provider or edit an opaque customer flag.
Version the procedure without rewriting past decisions
Seller policies evolve.
A supplier may change its return email, replace a PDF or move to a hosted application form. New applicants should see the new process. Existing applications should remain tied to the process under which they were submitted.
Publishing uses an idempotent command and serialises changes per seller. A new procedure becomes the policy's active version. The application captures that version's identity when it is created.
This separation avoids two forms of ambiguity:
- a seller cannot unknowingly judge an old submission against instructions published later;
- a buyer cannot claim to have followed a procedure that did not exist at submission time.
Versioning is not bureaucracy. It is what makes a long-running commercial approval explainable.
Connect approval to checkout without confusing it with payment
An approved application does not mean an invoice has been paid or that a purchase order is valid.
It means this seller has approved this organisation–property relationship for the relevant account-term path. Checkout may then offer the appropriate purchase-order or credit option when the buyer is operating in that property context.
The later payment lifecycle still has its own states: order creation, PO validation, buyer confirmation and vendor capture. The credit application answers whether the buyer may enter that path; it does not complete the path.
Keeping those capabilities separate prevents a positive approval badge from becoming a false financial state.
This also keeps the architecture reusable. A seller can change its payment workflow without changing the property identity of prior credit decisions.
Why Medusa was the right foundation
Medusa already carries customers, carts, payment sessions and orders. Our marketplace extensions add suppliers, organisations and properties. The credit module connects those primitives through a client-specific commercial rule.
We did not create a separate portal where credit approvals later need to be copied into checkout. The application and decision live close to the context that will consume them.
That is the value of choosing an extensible commerce engine.
Medusa supplies the transaction lifecycle. We can add the exact unit of trust the business needs—seller, organisation and property—then let payment-method resolution use that governed decision.
The result is more precise than a generic B2B customer flag and more integrated than an external spreadsheet.
What this changed for the client
A property group could request account terms without receiving blanket approval for every building it manages.
Each supplier could publish its own current process. Each property could apply independently. Submissions were retry-safe, linked to the procedure the buyer saw and protected against parallel pending or approved decisions. Seller reviewers could approve or reject one clear commercial relationship.
The marketplace could then explain why terms were or were not available:
- the seller does not require prior approval;
- no application exists for this property;
- the application is awaiting review;
- the seller rejected it;
- this property has an approval.
That explanation is far more useful than a disabled payment button.
A practical property-credit checklist
Before adding supplier terms to a multi-property platform, define:
- Is credit granted to a user, organisation, property or another legal unit?
- Can each seller publish a default or prior-approval policy?
- Are procedures versioned rather than overwritten?
- Does an application capture the procedure version and property snapshot?
- Does the backend verify organisation ownership of the property?
- Must the organisation already be allowed to buy from the seller?
- Are submissions idempotent at the business-command level?
- Can concurrent requests create two pending or approved applications?
- Is review seller-scoped and protected against contradictory decisions?
- Does checkout treat approval as eligibility rather than payment completion?
Those answers determine whether account terms become a controlled capability or another customer-service exception.
The broader lesson
The client did not need a global “allow purchase orders” switch.
They needed suppliers to decide where they were willing to extend terms across a complex property organisation, using an explicit procedure and a reviewable application.
We modelled the relationship at the correct scope, preserved the submitted context, protected submission and review against retries and connected the outcome back to Medusa checkout.
One company can manage twenty properties. Credit can still be a precise decision for one of them.