Refund Policy

Application is not as described

An application is `not as described` if it is materially different from the application description or preview so be sure to `tell it like it is` when it comes to the features and functionality of items. If it turns out the application is `not as described` we are obligated to refund buyers of that item.

Application doesn`t work the way it should

If an application doesn`t work the way it should and can`t easily be fixed we are obligated to refund buyers of the application. This includes situations where application has a problem that would have stopped a buyer from buying it if they`d known about the problem in the first place. If the application can be fixed, then we do so promptly by updating our application otherwise we are obligated to refund buyers of that application.

Application has a security vulnerability

If an application contains a security vulnerability and can`t easily be fixed we are obligated to refund buyers of the application. If the application can be fixed, then we do so promptly by updating our application. If our application contains a security vulnerability that is not patched in an appropriate timeframe then we are obligated to refund buyers of that application.

Application support is promised but not provided

If we promise our buyers application support and we do not provide that support in accordance with the application support policy we are obligated to refund buyers who have purchased support.

No refund scenario

If our application is materially similar to the description and preview and works the way it should, there is generally no obligation to provide a refund in situations like the following:

Force Refund

We hold the authority to refund buyer purchase by force without any request from buyer end. Force refund will stop app access as well as support access by denying purchase code with immediate action.

Refund Request

If a buyer eligible to get a refund then he/she must open a support ticket.