1. Service model
Eva Store provides an application for organizing communication, service requests, and the tracking of their execution stages. The application does not itself provide an integrated electronic payment gateway for completing payments for these services inside the application.
The application is used to describe the work requested, exchange information with the relevant parties, record the agreed scope and amount where a quotation is accepted, and follow the request status. The service itself is performed by the provider assigned to the request.
2. Request-specific pricing
Pricing is specific to each service request. A price shown in a service catalogue, where one is displayed, is a reference only; it is not a binding price for a particular request. The amount that applies to a request is the amount recorded in the accepted quotation or in the request record shown in the application.
Submitting a request does not create a binding price. A quotation may be accepted, rejected, or countered as the application permits. A quotation, an acceptance, or a status update is not, by itself, proof that a payment was collected or completed.
3. Request lifecycle
A service request normally moves through the following stages, where the application makes them available for that request:
- the customer submits a request describing the work and any required intake information;
- staff review the request and, where applicable, issue a price quotation;
- the customer accepts, rejects, or counters the quotation;
- a provider is assigned to the request;
- the provider accepts or declines the assignment;
- the provider performs and delivers the work through the supported workflow;
- the customer reviews the delivery and may request a revision or open a dispute where the application offers that step.
Not every request has every step. The application shows the actions available for the specific request, and the status shown in the application reflects the backend record.
4. Provider assignment
The backend assigns or reassigns an eligible provider to a request. The provider may accept or decline the assignment. A provider's acceptance is not a guarantee that the work will be completed within a particular time or that a particular outcome will be reached.
Where the application permits a handoff or reassignment, the current provider does not choose the replacement provider. The available handoff, observer, or collaboration options are shown only where the application supports them for that request.
5. Delivery and revisions
Providers deliver work through the supported workflow. A delivery may include notes and files that the provider uploaded and that passed the platform's validation and scanning. The customer can review the delivery and may request a revision where the application offers a revision step.
Revision limits, delivery timing, and acceptance steps are those shown for the specific request. A delivery or acceptance in the application is not, by itself, proof that a payment was collected or completed.
6. Support and complaints
Support and complaints are handled through the in-app support conversation (Profile → Contact support). Include the request reference and a clear description of the issue. The application does not publish a separate support email address, telephone number, or office address.
Support may review the request, the related records, and the available evidence. Support cannot guarantee a particular outcome in a dispute between users and does not decide questions that require a court, regulator, or other legal authority. No response or resolution time is guaranteed.
7. Cancellation and disputes
Cancellation and dispute options exist only where the application shows them for that request. The available options depend on the request status and the workflow enabled for that service.
A dispute does not automatically reverse a payment made outside the application. The application does not provide escrow, payment protection, or a refund guarantee for service payments. Any settlement or refund arrangement is a matter for the parties under the terms approved for the request and the law that applies to them.
8. Payments and local settlement
The evastore application operates as a platform for organizing communication, service requests, and the tracking of their execution stages. It does not currently provide an integrated electronic payment gateway for completing payments for these services inside the application. Payment and financial settlement arrangements, where applicable, are made through local means agreed by the relevant parties outside the application's payment-processing system, in accordance with the terms approved for each service request. Creating a service request, accepting a price quotation, or updating the request status inside the application is not, by itself, proof that a monetary amount has been collected or that a payment has been completed, unless there is independent, approved evidence under the agreed handling mechanism.
The application does not provide payment links, an in-app checkout, or a payment collection page for service requests. It does not publish a commission, provider payout schedule, refund policy, or delivery guarantee. Do not send money outside the application unless you have independently verified the provider and accepted the associated risk.
9. Disabled digital purchases
Digital purchases are currently disabled. The application may show store, course, or streaming surfaces, but it does not currently offer digital purchases, an external payment page, or a checkout for them. No digital purchase, payment, refund, or delivery commitment is offered through those surfaces while they remain disabled.
If a digital purchase flow is enabled in a later version, it will be subject to the terms and platform requirements that apply at that time. This policy does not promise that any such flow will be enabled.