Escrowise User Documentation
A practical guide to onboarding, funding, chatroom use, disputes, and escrow completion.
This is the user operating manual for Escrowise. It explains how the system works from first account setup to payment review, delivery, inspection, and dispute handling.
Core principle
Escrowise works best when the deal record stays inside the platform. Terms, proof, chat, and dispute evidence should all remain tied to the transaction.
If important instructions exist only off-platform, support and dispute review become weaker.
Section 1
Scope and Operating Model
Escrowise is built to support structured transactions from setup through funding, delivery, inspection, and resolution. The platform is designed to preserve an audit-friendly transaction trail rather than rely on fragmented private communication.
What the platform records
Parties, transaction terms, acceptance, payment state, delivery proof, attachments, chat activity, and dispute materials.
Why that matters
The more of the transaction lifecycle that stays inside Escrowise, the stronger the review record becomes for support, verification, and dispute handling.
Section 2
User Roles and Responsibilities
Each party has a distinct operational duty. Clear role discipline reduces premature delivery, unsupported payment assumptions, and avoidable disputes.
Buyer
- Review and accept the transaction only after all commercial terms are clear.
- Fund only through the payment path attached to the transaction.
- Inspect and confirm completion promptly when the seller performs.
Seller
- Do not fulfill until the transaction is accepted and payment state is operationally ready.
- Record delivery, milestones, or service completion in the workspace.
- Avoid off-platform payment requests or undocumented side terms.
Escrowise Operations
- Maintains the recorded workflow, payment review states, and evidence trail.
- Reviews verification and manual payment flows where required.
- Assesses disputes against the documented transaction record.
Section 3
Onboarding and Verification
Onboarding is the first control layer. Proper account setup improves trust, reduces manual intervention, and prepares the account for sensitive transaction activity.
Step 1
Create and confirm your account
Start with account registration and email confirmation before attempting protected actions.
Step 2
Complete your profile
Use correct names, contact information, and account details so the counterparty and admin team can identify you properly.
Step 3
Submit verification when prompted
Individuals may need identity and address documents. Companies may also need business and company files.
Step 4
Wait for review where required
Pending verification can affect higher-trust actions, so keep submissions complete and current.
Section 4
Creating and Accepting a Transaction
The transaction record is the main deal document. It should be complete enough that both delivery and any future review can rely on it.
Create the transaction only after the item, counterparties, amount, currency, and delivery expectations are clearly identified.
Write the critical commercial terms into the transaction record, including inspection period and special conditions.
Use the acceptance step to confirm counterparty participation before anyone performs.
Treat the recorded transaction as authoritative. Important deal terms should not live only inside private chat.
Section 5
Funding, Payment Proof, and Review
Funding state controls when the seller should act. Users should separate payment initiation, proof submission, review, and verified payment state.
A screenshot alone is not the transaction state. The authoritative signal is the payment status inside Escrowise.
Section 6
Fulfillment, Delivery, and Inspection
Once the transaction is active and properly funded, the seller performs and the buyer inspects. Delivery evidence and review timing are critical to clean closure.
Section 7
Chatroom and Document Handling
The chatroom is the operational coordination layer for a transaction. It should preserve context, clarify next steps, and centralize supporting evidence.
Good chat discipline
Keep logistics, clarifications, evidence references, and issue escalation in the transaction-linked chat whenever possible.
Section 8
Dispute Management
Disputes are for material transaction failures, not routine clarification. Strong dispute submissions are factual, timely, and supported by evidence.
Open a dispute when there is a material failure involving payment, delivery, authenticity, quantity, quality, timing, or breach of terms.
Submit a concise explanation and attach objective evidence such as proof of payment, proof of delivery, screenshots, invoices, or signed documents.
Continue responding through the dispute workflow. Delayed or missing responses weaken the factual record.
Expect the review team to rely primarily on the transaction record, timestamps, uploaded proof, and documented system activity.
Section 9
Status Reference
These system states guide user action. Users should rely on them rather than assumptions made outside the platform.
| Status | Meaning |
|---|---|
| pending | The transaction exists and is awaiting the next action. |
| accepted | The counterparty has accepted the transaction. |
| pending_approval | A manual payment path is selected and awaits operational confirmation. |
| pending_verification | Payment proof has been submitted and is under review. |
| verified / confirmed | Payment has been recognized for operational purposes. |
| inspection / inspection_period | Delivery is complete and the buyer review window is active. |
| disputed | The transaction has been escalated for review. |
| completed | The transaction is closed and the value flow is settled. |
Verification review has separate account-level states such as pending, approved or verified, and rejected. Account verification status and transaction payment status are related, but they are not the same thing.
Section 10
What the System Is and Is Not
Good use depends on understanding the platform boundary. Escrowise provides transaction controls and records, but it does not remove every commercial or legal responsibility from the parties.
What Escrowise is
- A structured workflow for documenting agreement, funding state, fulfillment, and resolution activity.
- A workspace for payment proof, delivery proof, chat coordination, and attachments.
- A safer operating environment than informal off-platform arrangements because the record is preserved.
What Escrowise is not
- Not a replacement for legal advice, technical due diligence, or independent inspection.
- Not an approval for prohibited goods, unsupported payment behavior, or off-platform dealing.
- Not a guarantee that every counterparty or underlying commercial claim is risk free.
Section 11
Operating Best Practice
These habits reduce friction, improve transaction quality, and produce a better record if support or dispute review is ever needed.
Use the guide, then move through the workflow inside the platform.
If you are ready to transact, complete onboarding and build the deal inside Escrowise. If a live case needs help, contact support with the transaction reference and keep the conversation in the relevant workspace.