Data Processing Addendum

The DPA applies only when a merchant and FaStart enter into an applicable production agreement or order that incorporates it. It covers processing by FaStart on the merchant's documented instructions, including account-linked store operations, shopper profiles, saved addresses, checkout, orders, returns, reviews, support, media and related service telemetry. The current Backend source contains these bounded-context capabilities, but its default runtime configuration does not prove that any production service or provider is active.

• For merchant-controlled shopper and store data, the merchant determines the purposes and essential means of processing and acts as the data controller or equivalent business. FaStart acts as processor only to the extent it processes that data on the merchant's documented instructions.
• FaStart is an independent controller for data it processes to operate its own public website, account security, fraud prevention, billing of its own services, legal compliance and support of the FaStart relationship. Those activities are described in the KVKK Notice and applicable service terms.
• The merchant's instructions include the activated service, permitted data categories, permitted purposes, authorized users, retention/deletion instructions and lawful responses to shopper requests. Instructions that conflict with applicable law or the activated service must not be followed until clarified.
• This DPA does not transfer the merchant's responsibility for product legality, consumer disclosures, seller-side controller notices, payment-provider terms or fulfillment obligations.

• Data subjects may include merchant owners, staff and invited members; shoppers and guest buyers; recipients and billing contacts; reviewers; support participants; and people represented in a return, report or dispute.
• Categories may include account identifiers, email, password and verification state, session and security metadata, membership and invitation data, organization/store configuration, name, phone, language, currency and time zone, and optional date of birth or gender where the activated flow collects them.
• Checkout, order and return data may include recipient and billing names, phone numbers, email, delivery and billing addresses, postal and location information, product and order snapshots, prices, taxes, shipping, cancellation, return reasons, refund references and evidence-media references.
• Reviews, feedback, reports and support may contain free-text content, moderation or support snapshots, attachments, avatar/media references and information voluntarily supplied by a person.
• If a verified payment provider is enabled, provider-bound payloads may contain identity-number data, name, email, phone, address, country, postal code, IP address, basket and amount data, and card details submitted to the provider request. The FaStart payment schema identified protected provider tokens and last-four metadata, not full PAN or CVC columns; provider-side handling and retention still require the provider's own notice and contract.

• Creating and securing accounts, authenticating users, verifying email or password-reset requests, managing sessions, memberships, invitations and access permissions.
• Provisioning organizations, stores, domains, themes, catalogs and merchant operations that the merchant has activated.
• Preparing and completing checkout, cart, order, cancellation, return, refund and fulfillment workflows, including fraud, reconciliation and support investigations where lawfully required.
• Displaying and moderating reviews, questions, feedback, reports and support conversations; delivering authorized media and return evidence.
• Calling an activated payment, shipping, media or identity provider, maintaining integration references, and resolving failed or ambiguous operations.
• Protecting the platform, preventing abuse, maintaining tenant isolation, troubleshooting incidents, maintaining audit/security records and satisfying legal obligations.
• FaStart must document any separate analytics, profiling, automated decision, marketing or AI purpose before enabling it. No active Backend generative-AI provider was verified in this review.

• FaStart personnel and contractors authorized to process merchant data must be bound by confidentiality obligations appropriate to their role.
• Source controls include hashed authentication secrets, opaque token handling, secure __Host session-cookie settings, tenant and organization scope checks, protected payment-provider tokens, callback digests, and provider/runtime feature gates that default payment and media surfaces to disabled.
• Backend logging rules prohibit raw request and response bodies by default, allowlist headers, and prohibit passwords, tokens, credentials, payment and personal data in application logs. Audit storage and retention are bounded-context and deployment dependent.
• These source controls do not by themselves prove encryption at rest, a particular cloud region, a certification, penetration testing, backup retention or a completed incident-response program. Those facts must be confirmed for the production environment and contracts.

FaStart may use subprocessors only for an activated service and documented purpose, subject to the applicable agreement and transfer law. The public Subprocessor Register identifies source-level candidates and the evidence status; it is not a claim that every listed provider is active. International-transfer mechanism, country, onward transfer and supplementary measure must be confirmed for the actual deployment before production processing.

• Taking account of the nature of processing, FaStart will provide reasonable assistance for access, correction, deletion, restriction, objection, portability, consent withdrawal and security obligations where the activated service and law require it.
• Requests should be routed through the merchant's published channel when the merchant is the controller. FaStart may require identity, scope and authorization checks before disclosing or changing data.
• The current source review did not identify one operational, cross-service data-export and legal-erasure workflow covering IAM, management, core, media and payment records. No public self-service erasure promise is made until that workflow, exceptions and provider deletion steps are implemented and tested.
• A merchant remains responsible for answering its shoppers and for deciding whether a request must be fulfilled, restricted or refused under applicable law.

• FaStart will maintain an incident escalation path appropriate to the activated service and will notify the merchant without undue delay after confirming a personal-data incident affecting merchant-controlled data, subject to applicable law and the executed agreement.
• Cooperation may include the known nature and scope of the incident, affected service, containment steps, reasonably available records, and support for legally required notifications. Exact response contacts and severity thresholds must be fixed in the production runbook.
• The public security contact is security@fastart.tech. It is not a substitute for a merchant incident-notification contact until the production service agreement and runbook name one.

At the end of the activated service, FaStart will follow the merchant's documented return or deletion instruction unless applicable law, a legal hold, security need, payment-provider process or another documented exception requires retention. The Backend uses soft-delete and lifecycle states in several bounded contexts and has limited cleanup jobs, but the source does not establish a single retention schedule or automatic full deletion across every service. Provider-side deletion must be separately confirmed.

On reasonable written request, FaStart may provide available information needed to demonstrate the activated processing and security measures, subject to confidentiality, tenant isolation, security and the protection of other customers. Any audit must be proportionate, scheduled, and must not expose another customer's data or secrets. This DPA does not grant access to source code, credentials or financial records.

This DPA begins only when incorporated into an executed or explicitly accepted production agreement, remains in force for the relevant processing, and may be updated when the service, law or subprocessor set changes. The executed service agreement, merchant instructions and mandatory law control. If a conflict exists, the more specific executed data-processing term controls to the extent permitted by law.

Questions may be sent to legal@fastart.co or privacy@fastart.co. Before activation, FaStart and the merchant must confirm the controller/processor allocation, provider register, transfer safeguards, retention schedule, deletion/return workflow, incident contacts and acceptance record.