Fund milestones
with clearer
release conditions.
Where supported, ZoikoRum connects funding and release workflows to agreed milestones, acceptance, approvals, holds and dispute state — so buyers and professionals can see what must happen before funds move.
Payment-protection mechanisms, provider roles, fees and availability vary by market and engagement. Applicable terms are shown before use.
* Exact legal/payment mechanism is shown from market-specific provider configuration.
Milestone-linked funding
Connect funding to defined work rather than a generic checkout.
Controlled release
Release can depend on acceptance, approvals and applicable conditions.
Visible holds
When a hold or dispute affects payment state, it is shown explicitly.
Traceable record
Funding, releases, holds, refunds and provider references can stay connected to the engagement where applicable.
From agreed milestone
to recorded outcome.
Switch perspective to see each step as a buyer, a professional, or the platform.
Agree milestone
Review scope, deliverable, acceptance criteria and commercial terms.
Fund where supported
Complete the required funding step after applicable disclosures.
Deliver
Wait for the agreed deliverable.
Review & accept
Accept, request changes or use an available exception route under governing terms.
Release or hold
If conditions are satisfied the supported workflow proceeds; otherwise state stays blocked or held.
Record
Review final payment-protection events in the engagement record.
This six-step explanation is a communication model. It does not assert that every market, provider or engagement uses identical payment rails or legal structures.
A funded milestone,
exactly as it is.
Pick a scenario. The workspace, release conditions and diagnostic drawer all read the same state.
Acceptance, approval and hold states are projections from their owning domains. They are never editable from the payment card.
Not a release button —
a reason for every state.
Every condition is explained and linked to its authoritative record. No hidden risk scores.
Release conditions · Milestone 2
Scenario: Awaiting review- SatisfiedFunding confirmedThe supported funding step has been confirmed for this milestone.
- SatisfiedCorrect contract + milestone versionRelease eligibility is tied to the currently governing version.
- SatisfiedDeliverable submittedRequired work and evidence has been submitted.
- !Pending · Finance LeadMilestone acceptanceThe authorized acceptance decision controls the milestone state.
- CompleteRequired approvalOrganizational approval requirements are shown when they apply.
- NonePayment holdAn active hold prevents release until its owning process resolves it.
- NoneDispute stateAn open dispute can affect payment state under governing terms.
- AvailableProvider / payment availabilityProvider or market conditions may affect execution even when engagement conditions are satisfied.
Release is not available yet
Finance Lead reviews the milestone against the current acceptance criteria.
If eligibility is computed, the user-visible factors are explained and each one links to its authoritative record where permissions allow.
Recommended payment-protection states
Implementation recommendation · Not yet liveDifferent words.
The same truth.
Choose a moment to compare what each side sees.
Required amount and terms only when approved for display, plus applicable mechanism and fees disclosure.
Whether funding is required before work, and what status will confirm it.
When something changes,
the right workflow takes over.
Escrow Protection shows the state and the route. Specialist workflows own the decision.
“This milestone changed after funding. Release conditions must be revalidated before funds can move.”
Shows who changed it and the owning route. No silent transfer of release authority to the new version.
Reason labels are audience-safe. Sensitive compliance or legal detail may reduce to a general explanation plus a support route.
Agreed milestones
Clear review
Visible outcomesGovern who funds, accepts
and approves release.
Payment authority, acceptance authority and release approval stay separate — and every exception is recorded.
Funding authority
Define which roles can initiate or approve funding, from organizational authority configuration.
Acceptance authority
Separate from payment authority. The authorized accepter is always explicit.
Release approval
Consumes the Approval Workflows outcome — never an ad hoc button.
Separation of duties
Prevent one actor from creating terms, accepting delivery and authorizing release when policy requires.
Threshold rules
Policy Engine decides whether extra controls apply; this page only explains their effect.
Portfolio evidence
Payment-protection events feed Audit & Reporting for cross-engagement review.
Roles & permissions
- Buyer / RequesterTypical allowed actions
View payment-protection state for owned engagements; initiate funding where authorized.
Explicitly not impliedCannot accept milestones or release funds unless separately authorized.
- Acceptance AuthorityTypical allowed actions
Review the deliverable and record acceptance or a change request.
Explicitly not impliedAcceptance is not automatically provider execution.
- Finance / Budget OwnerTypical allowed actions
View or approve funding or release steps where policy grants authority.
Explicitly not impliedCannot change contract scope by acting on payment.
- Procurement / Org AdminTypical allowed actions
Review policy/approval state; manage organization settings where authorized.
Explicitly not impliedCannot see sensitive provider data without need and permission.
- Professional / Firm MemberTypical allowed actions
View funding, release and hold status for the engagement; access the payout route.
Explicitly not impliedCannot override buyer acceptance, policy or holds.
- Support AgentTypical allowed actions
View support-safe diagnostic state and route the issue.
Explicitly not impliedCannot change money state without controlled operational authority.
- Dispute ReviewerTypical allowed actions
View dispute-relevant payment state and evidence per process.
Explicitly not impliedCannot alter unrelated engagement or payment facts.
- Auditor / ViewerTypical allowed actions
Read-only review and export according to scope.
Explicitly not impliedNo operational state changes.
| Role | Typical allowed actions | Explicitly not implied |
|---|---|---|
| Buyer / Requester | View payment-protection state for owned engagements; initiate funding where authorized. | Cannot accept milestones or release funds unless separately authorized. |
| Acceptance Authority | Review the deliverable and record acceptance or a change request. | Acceptance is not automatically provider execution. |
| Finance / Budget Owner | View or approve funding or release steps where policy grants authority. | Cannot change contract scope by acting on payment. |
| Procurement / Org Admin | Review policy/approval state; manage organization settings where authorized. | Cannot see sensitive provider data without need and permission. |
| Professional / Firm Member | View funding, release and hold status for the engagement; access the payout route. | Cannot override buyer acceptance, policy or holds. |
| Support Agent | View support-safe diagnostic state and route the issue. | Cannot change money state without controlled operational authority. |
| Dispute Reviewer | View dispute-relevant payment state and evidence per process. | Cannot alter unrelated engagement or payment facts. |
| Auditor / Viewer | Read-only review and export according to scope. | No operational state changes. |
Who handles funds — and
what applies in your market.
Rendered from market configuration governed by Legal and Payments — never hard-coded marketing copy.
Mechanism, provider role, fees and terms appear here before any funding commitment.
Availability
Whether this mechanism is available for your market and engagement.
No universal availability claim
Mechanism name
Approved market-specific term: escrow, safeguarded funding, payment protection or other approved wording.
“Escrow” only where supported
Provider role
Which approved provider performs the payment function, if disclosure is permitted.
Provider names never invented
ZoikoRum role
The platform and orchestration role, stated accurately.
No implication ZoikoRum holds funds unless true
Funding timing
A plain-language timing model without unsupported SLAs.
Approved wording only
Release conditions
Which engagement states are relevant.
Matches actual implementation and terms
Fees route
Link to current Pricing / Fees & Billing.
No hidden or stale percentages
Dispute / refund effect
High-level effect plus the specialist route.
Never adjudicated on this page
Governing terms
Relevant payment terms, engagement terms and privacy notices.
Versioned and current
Jurisdiction note
Features may differ by jurisdiction.
Always visible before funding commitment
“Payment-protection features vary by market and engagement. Where available, funding and release can be linked to milestone, acceptance, approval, hold and dispute state. The applicable provider role, protections, fees and terms are shown before you use the payment feature.”
What remains
after funds move.
Funding event
By roleConfirmed, pending or failed funding; milestone/version link, timestamp and provider reference where permitted.
Release eligibility event
Engagement rolesWhich source conditions were satisfied or blocked at evaluation time.
Release command / outcome
Role-restrictedInitiation and the provider-confirmed outcome where applicable.
Hold event
Minimized by audienceReason category, source owner, start and end state.
Refund event
Role-restrictedOwning workflow reference and provider outcome where applicable.
Dispute linkage
Permission-dependentDispute identifier and state link — without duplicating evidence.
Terms / mechanism version
Legal / finance / adminWhich market/payment terms and mechanism configuration applied.
Audit event
Audit & ReportingWho or what caused important transitions, and when.
No full bank or card data, unmasked provider tokens, internal fraud signals, confidential legal notes or personal identity data — just because they relate to payment operations.
Engage with clearer
payment conditions.
Find the right professional, agree milestones, and see what must happen before funds move.
ZoikoRum provides marketplace, governance, payment and evidence infrastructure and does not guarantee a professional’s work. Payment-protection mechanisms, provider roles, fees and availability vary by market and engagement.