Privacy & Data

1. Privacy approach

PutinCode processes information to operate a digital marketplace, provide account features, deliver purchases, manage licenses, support sellers, handle service work, secure the platform and understand how the website is used. The platform should collect data for defined purposes rather than collecting information simply because a browser or device can expose it.

This page explains the categories of information the site may process and the choices available to users. The exact legal basis, retention period and rights available to a user can depend on the jurisdiction and the relationship between the user and the marketplace operator. Where local law requires additional notices or consent, the operator should configure the site and business process accordingly.

2. Account information

When a user creates an account, the marketplace may process information such as name, email address, role, account status and authentication data. Passwords should be stored as secure hashes rather than readable text. Account records are used for login, buyer or seller dashboards, notifications, orders, licenses, messages and administrative security.

Users should keep their email address current because order, security or support communication may depend on it. Account information should not be used to request unrelated secrets. PutinCode support does not need a user's password, private key or recovery phrase in order to review a normal marketplace issue.

3. Orders, purchases and licenses

When a buyer places an order, the marketplace may store product, price, buyer, seller, payment method, order status and transaction reference information needed to process and document the purchase. The system may also connect a successful order with a license or download entitlement.

Payment providers can process additional financial information under their own systems. PutinCode should avoid storing full payment credentials when a payment provider is responsible for handling them. Manual payment workflows may include a reference number or proof uploaded by the buyer so an administrator can verify the order.

4. Seller and creator information

Seller accounts may include marketplace profile information, product listings, versions, order history, earnings, withdrawal details, support conversations and moderation status. This information is used to operate the seller workflow and to present public information that the seller intentionally publishes on a product listing.

Creators should remove personal or customer information from product files before upload. A database dump used for a demo should contain safe sample data, not a copy of a live customer's records. Uploaded product packages can remain available to eligible buyers according to marketplace access rules, so release hygiene is part of privacy protection. Creators can use PutinCode to package repeatable digital work into products, templates, components or service offers. The most durable products are designed around clear customer outcomes, consistent naming, reusable setup steps and realistic maintenance. Creators should own or have permission to distribute everything they submit and should avoid including secrets, personal data, unlicensed assets or third-party material that cannot legally be redistributed.

5. Messages and support requests

Registered users can use marketplace messages for buyer, seller, service and support communication. Messages may contain text and permitted attachments, along with sender, conversation and time information. Public Contact submissions can store name, email, enquiry type, subject, message, status and creation time in the admin support queue.

Support content should be limited to what is needed to resolve the issue. Users should redact passwords, API secrets, full card or bank credentials and unrelated personal information. If diagnostic data contains personal information, share only the portion required to explain the problem.

6. Visitor analytics and page activity

The site can record visitor events such as page path, referrer, device type, browser, platform, screen size and timezone. These signals help the operator understand which pages are used, diagnose interface problems and plan marketplace improvements. A session identifier or privacy-preserving hashed network identifier may be used to group events without displaying a raw network address in the visitor dashboard.

Analytics should not be used to infer sensitive personal characteristics that are unrelated to marketplace operation. Administrators should limit access to visitor information and avoid exporting it when aggregated reporting would answer the same business question.

7. Country, region, city and network information

Approximate location and network-provider information can sometimes be derived from network metadata or an external geolocation service. This type of location is approximate and may be wrong, especially when the visitor uses mobile networks, corporate gateways, proxies or VPN services. It should not be treated as precise GPS location.

If the site enriches visitor events with country, state, city, area or network provider information, that data should be used for legitimate purposes such as regional analytics, fraud review or support context and handled according to applicable privacy rules.

8. Precise browser geolocation

Precise latitude and longitude from a browser or mobile device requires the visitor's permission through the browser's geolocation interface. PutinCode cannot force that permission to true and should not fabricate a GPS value when permission is denied, unavailable or blocked. The visitor can use browser or device settings to change location permission later.

When a visitor grants location permission, the system may store coordinates, accuracy and permission status for the purpose disclosed by the site. Because precise location can be more sensitive than approximate region data, access should be limited and retention should be no longer than reasonably necessary for the configured feature.

9. Cookies, sessions and local browser storage

The marketplace uses session technology to keep users signed in, protect forms and maintain account state. Essential session cookies can be necessary for authentication and security. Additional browser storage may be used for interface preferences, consent status or analytics depending on the site configuration.

Blocking essential cookies can prevent login, checkout or account features from working correctly. Where non-essential cookies or tracking technologies require consent, the site should provide an appropriate choice before activating them.

10. Uploaded files and media

Product images, social icons, preview media, chat attachments and other uploads are stored so the requested marketplace feature can display or deliver them. Access rules differ by file type: a public product image can be intentionally visible to everyone, while a private message attachment should be limited to authorized conversation participants.

Users should upload only files they are entitled to share and should avoid embedding hidden personal data in images, documents or archives. Administrators should remove obsolete uploads when they are no longer needed and keep server upload restrictions current.

11. YouTube and external social services

The Media & Social Hub can embed videos using YouTube's privacy-enhanced player domain and can link to external services such as Facebook, Instagram, X, LinkedIn, GitHub, Telegram or WhatsApp. When a visitor loads or interacts with an embedded or external service, that provider may process information under its own privacy policy.

PutinCode can use CDN-hosted platform icons for display when an administrator has not uploaded a custom icon. Loading a CDN asset can involve a request to the CDN provider. Administrators who require fully local assets can upload their own approved icons through the social settings instead.

12. Security and access controls

The platform uses application controls such as authenticated dashboards, role checks, CSRF protection and private file access rules to reduce unauthorized activity. No system can guarantee absolute security, so operators should also keep hosting, PHP, dependencies and administrator credentials maintained.

Users should report suspected account compromise promptly and change credentials that may have been exposed. Administrators should use unique passwords, restrict access to the admin area and avoid leaving diagnostic files or database exports publicly accessible.

13. Data retention

Different records have different operational value. Orders and licensing records may need to be retained longer than temporary visitor analytics because they document transactions and access rights. Support messages may be retained while a case is active and for a reasonable period afterward. Security logs may be kept long enough to investigate abuse or failures.

The operator should periodically review whether old visitor data, inactive uploads or closed support records are still needed. Deletion must also account for backups, legal obligations and records that are necessary to establish or defend legitimate marketplace claims.

14. Sharing and service providers

PutinCode may rely on hosting, email, payment, CDN, analytics, media or other infrastructure providers to operate the service. Those providers can process information necessary to perform their service. The operator should choose providers appropriate for the data involved and configure access to avoid unnecessary exposure.

Marketplace information may also be disclosed when reasonably necessary to comply with valid legal requests, enforce rights, investigate fraud or protect users. Data should not be sold or shared for unrelated purposes merely because it is technically available.

15. User choices and requests

Users can control some data directly through account, browser and device settings. They can choose whether to create an account, whether to submit a public Contact form, whether to open external social links and whether to grant precise geolocation permission. Registered users can also review marketplace records available in their dashboards.

Where applicable law gives a user rights to access, correct, delete, restrict or object to certain processing, the user can contact the operator through the published Contact page. The operator may need to verify the request and may retain information that is legally required or necessary for legitimate transaction records.

16. Children and inappropriate use

PutinCode is intended for people and businesses capable of entering into marketplace transactions and managing digital products. The platform is not designed as a child-directed service. Users should not submit information about children through product data, demo databases or support attachments unless there is a lawful and necessary reason that has been appropriately reviewed.

Sellers and developers should be especially careful with sample data. Synthetic examples are preferable to real personal information when demonstrating a feature or reproducing a technical issue.

17. Policy changes and contact

This Privacy & Data page may be updated when the marketplace adds features, changes providers or modifies its data practices. The published page should describe the current operational approach and should be reviewed alongside the Marketplace Terms and product-specific information.

Questions about privacy, account data or visitor analytics can be sent through the Contact page. When making a request, provide enough information to identify the relevant account or transaction but do not include passwords or other secrets. The operator may request additional verification when necessary to protect account data from unauthorized disclosure.

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.