Marketplace Terms

1. Scope and acceptance

These Marketplace Terms govern use of PutinCode, including public browsing, account registration, product listings, purchases, licenses, seller activity, remote services, messaging, media features and support. By creating an account, placing an order, publishing a listing or otherwise using protected marketplace features, you agree to follow these Terms together with any product-specific license or service scope shown at the time of the transaction.

If you do not agree with these Terms, do not use the parts of the service that require acceptance. The marketplace operator may publish updates to these Terms when the platform, legal requirements or business processes change. Material changes should be reflected by the published version and effective date. Continued use after an update may constitute acceptance where permitted by applicable law.

2. Accounts and accurate information

Users must provide information that is reasonably accurate for account, order and support purposes. You are responsible for maintaining control of your login credentials and for activity performed through your account unless you promptly report unauthorized access. Do not share passwords, private keys or authentication secrets in public listings or ordinary support messages.

Accounts may be designated for buyer, seller or administrative roles, and different features may be available to each role. Users must not impersonate another person or business, create accounts to evade restrictions, automate abusive registrations or use account access to interfere with other users.

3. Marketplace listings

Sellers are responsible for the accuracy and legality of listings they submit. Product descriptions, screenshots, feature claims, requirements, prices, versions and license information should reflect the actual product offered. A listing must not intentionally conceal a material dependency, represent a demo as included when it is not, or use another party's trademarks, images or code in a misleading way.

Marketplace approval or a verified status indicates that the listing has passed the platform's publication workflow. It is not a guarantee that the product is error-free, suitable for every environment or endorsed for every business purpose. Buyers remain responsible for reviewing product-specific requirements before purchase. Sellers are expected to publish accurate, maintainable listings rather than promotional claims that cannot be verified. A strong listing explains what the product does, what it does not do, the technical stack, installation requirements, current version, media, documentation, support boundaries and licensing. Sellers should keep buyer communication professional, preserve update history and respond through marketplace channels where order context can be understood.

4. Intellectual property and distribution rights

Sellers must own the content they distribute or have sufficient rights to license or redistribute it. This requirement applies to source code, designs, fonts, images, videos, documentation, sample data and bundled third-party components. Open-source software may have license obligations that continue to apply even when it is included in a paid product.

Users must not use PutinCode to distribute stolen code, pirated assets, leaked private repositories, malware, credential theft tools or content that infringes another party's rights. Rights holders may contact marketplace support with a sufficiently specific notice identifying the work, the allegedly infringing listing and the basis for the claim. The operator may hide content while a credible rights issue is reviewed.

5. Purchases and product evaluation

Buyers should review the product page before checkout, including the description, technical requirements, license, support period, current version and any external services required. A purchase grants only the rights described by the applicable license; it does not transfer ownership of the seller's underlying intellectual property unless the listing expressly states otherwise.

Source code products can require technical skill to configure and operate. The marketplace does not promise that a product will be compatible with every host, framework version, plugin, customization or third-party API. Buyers should ask pre-sale questions when compatibility is important to the purchase decision. Buyers should evaluate the listing as a complete decision package: product purpose, framework and version requirements, included files, license scope, support period, update history, seller responsiveness and any external services the product depends on. A professional marketplace reduces uncertainty by making these details visible before checkout, but the buyer still owns the final compatibility decision for the environment where the product will be used.

6. Licenses

A product license defines how the buyer may use the purchased files. License types may vary by product or package. Unless a product specifically states otherwise, purchasing a license does not permit resale of the original source files as a competing stock product, removal of third-party license obligations or redistribution to unrelated parties.

If domain assignment or license activation is supported, buyers must use those features according to the product's license terms. Attempting to bypass license controls, generate unauthorized license keys or use a single-project license across unrelated deployments may result in suspension of access or other marketplace action.

7. Payments and order status

Available payment methods are determined by marketplace configuration and may include wallet, manual transfer or other supported gateways. An order is not considered completed merely because a buyer submits a payment reference. Manual payments may remain pending until the operator verifies the transaction. Gateway availability, settlement timing and eligibility can also depend on third-party provider rules.

Users must not submit false payment proof, manipulate transaction references, charge back legitimate transactions fraudulently or use payment methods they are not authorized to use. If a payment dispute occurs, the marketplace may review order records, messages, delivery status and payment evidence relevant to the transaction.

8. Refunds, disputes and digital delivery

Digital products can be delivered immediately after eligible payment status and may be difficult to 'return' in the same way as physical goods. Any refund decision therefore depends on the marketplace policy, applicable law, the product description, delivery status, license use and the reason for the request. A change of mind or failure to read clearly stated requirements may not automatically qualify for a refund.

If a buyer believes a product is materially different from the published listing, they should contact the seller or support with specific evidence. Sellers should respond professionally and attempt reasonable troubleshooting when the issue is within the included support scope. The operator may make administrative decisions based on the available marketplace record.

9. Product updates and support

Sellers may publish newer product versions through the marketplace workflow. Access to future updates depends on the product, license and marketplace configuration. Buyers should keep legitimate backups and review release notes before replacing production files. Sellers should not deliberately publish broken updates or hide material compatibility changes.

Support terms describe assistance with the purchased product, not unlimited custom development. Installation on an unusual environment, integration with unrelated software or new feature development may require a separate Remote Service. Both sides should communicate the boundary between support and custom work before substantial work begins.

10. Remote services

Remote Services are project-based activities such as installation, customization, migration, integration, performance work or custom development. The buyer and service provider should agree on the intended outcome, scope, access requirements, timing and deliverables. A marketplace service order does not authorize access beyond what is reasonably necessary for the agreed task.

Developers must handle customer systems responsibly, avoid unnecessary copying of personal data and return or remove temporary credentials when the work is complete. Buyers should maintain backups and provide authorized access. Neither party should ask the other to bypass security controls, licensing restrictions or third-party platform rules. Developers and technical teams benefit when marketplace information is structured like engineering documentation. Requirements, dependencies, deployment assumptions, database needs, supported runtimes, API integrations and known limitations should be easy to inspect. Before production deployment, teams should use backups, staging, change control and their normal code-review process instead of treating any downloaded product as a substitute for engineering validation.

11. Messages, uploads and acceptable use

Marketplace messaging and file attachments are provided for legitimate buyer, seller, service and support communication. Users must not use them for spam, harassment, phishing, malware distribution, credential theft or unlawful content. Uploaded files may be restricted by type, size or access controls to reduce risk.

Do not upload content that contains secrets or personal information unrelated to the transaction. The operator may remove attachments, restrict accounts or preserve relevant records when reasonably necessary to investigate abuse, enforce marketplace rules or protect users.

12. Media and social links

The Media & Social Hub may display embedded YouTube videos, social profile links, uploaded preview images and other administrator-published media. External services are governed by their own terms and privacy practices. An embedded player may communicate with its provider when loaded, and users can choose whether to open external links.

Social icons or brand marks are used to identify destinations. They do not imply that the external platform sponsors PutinCode. Users should verify that they are following links published through the official marketplace rather than copies shared by unknown third parties.

13. Platform administration and enforcement

The operator may moderate listings, hide products, adjust featured placement, suspend accounts, restrict access to uploads or messages and take other reasonable steps to protect the marketplace. Enforcement decisions may consider marketplace records, user reports, payment status, intellectual-property notices and repeated violations.

The operator may also maintain, update or temporarily interrupt parts of the service for security, hosting or feature changes. Reasonable efforts may be made to preserve access and data, but no online service can promise uninterrupted availability in every circumstance.

14. Disclaimers and limitation context

Software and development services involve technical risk. Products can contain defects, third-party dependencies can change and server environments can behave differently. Users should maintain backups and test changes before production use. Nothing in the marketplace presentation should be treated as a guarantee of business revenue, regulatory compliance or fitness for a use that was not specifically agreed.

These Terms are intended as the operating rules for the marketplace and are not a substitute for professional legal advice. The operator should review them for the jurisdiction in which the business operates, and mandatory consumer or data-protection rights continue to apply where they cannot legally be excluded.

15. Contact and policy updates

Questions about these Terms can be sent through the Contact page. Product-specific questions should normally begin with the seller or the relevant marketplace conversation, while account, payment or platform issues can be escalated to support.

The published Terms page is the controlling public version of these marketplace rules. If the platform adds new payment methods, product types, media features or service workflows, this page may be updated to explain the new responsibilities. Users are encouraged to review the Terms periodically, especially before beginning a new seller activity or a high-value service engagement.

Practical implementation note

Practical implementation should favor clear records, least-privilege access, documented expectations and reversible changes. Participants should keep relevant marketplace communication attached to the order, product or service whenever possible so that future support does not depend on memory. When a requirement is unclear, ask before changing production systems or committing to a purchase. This approach protects buyers, sellers, developers and creators while preserving a useful audit trail for marketplace administrators.