Shopify Blog
Türkçe sürüm: Shopify Türkiye Satışa Hazırlık Kontrol Listesi
Sources last checked: 31 October 2026. This general guide does not certify that a particular store has passed testing.
Launching a Shopify store for Turkish customers requires more than translating a theme. Decide who sells the goods, where inventory is held, and who handles payments, documents, delivery and returns. Use this checklist to assign responsibility and collect evidence before accepting live orders.
Who is this for?
International brands and agencies planning sales to customers in Turkey. It covers technical and operational readiness, not incorporation, tax registration or legal advice. A cross-border seller and a Turkish local entity may need different operating arrangements.
Decide your route before configuring the store
| Decision | Cross-border sales from an overseas business | Local Turkish operation |
|---|---|---|
| Seller of record | Identify the overseas contracting seller | Identify the actual local contracting seller |
| Fulfilment | Define origin, importer responsibilities, customs and delivery promises with qualified providers | Define local stock, warehouse and carrier responsibilities |
| Payments | Confirm eligibility for the actual entity, account and currencies | Confirm eligibility with the actual entity and provider |
| Documents and tax | Obtain advice on the applicable sales/import/document model | Obtain advice on local obligations and e-document scope |
| Returns | Define return destination, costs and handling | Define local handling and inventory/document consequences |
These are planning questions, not a recommendation that every foreign brand must form a Turkish company. Do not choose an entity or tax structure solely to activate a payment feature.
As checked on 31 October 2026, Turkey is not listed among supported business countries for Shopify Payments. An overseas merchant’s eligibility depends on its actual business country, documents and other provider conditions; selling to Turkey does not automatically establish or remove eligibility. Check Shopify’s current list.
How to use the checklist
Track each row as Pending, Testing, Complete or Not applicable. In your working copy add the named owner, test date and evidence link. Explain exclusions. Redact personal and commercially sensitive information from shared evidence. The acceptance criteria below are proposed implementation checks, not legal certifications.
Operational and technical checks
| No | Area | Check | Owner | Test | Acceptance criterion |
|---|---|---|---|---|---|
| 1 | Business | Seller identity and contact details | Merchant | Compare storefront, invoice and account details with approved business records. | Details agree and the merchant has approved them. |
| 2 | Business | Account ownership and access | Merchant + technical team | Check ownership and roles for the store, domain, apps and providers. | Merchant retains access; appropriate roles replace shared passwords. |
| 3 | Catalog | Products, variants and SKUs | Merchant + technical team | Compare sample options, SKUs, prices and inventory with source data. | Samples match; invalid and duplicate records are resolved. |
| 4 | Catalog | Collections, filters and product information | Merchant + technical team | Check mobile navigation, filters and product information. | Sample products are discoverable and essential information is complete. |
| 5 | Payments | Provider and business eligibility | Merchant + payment provider | Verify entity country, business type, bank account, currencies and contract eligibility. | Eligibility and supported scope are confirmed, not assumed. |
| 6 | Payments | Successful and declined payments | Technical team + merchant | Use the provider-supported test method for successful and declined transactions. | Order and payment states are correct; declined orders are not marked paid. |
| 7 | Payments | Live configuration and reconciliation | Merchant + technical team | Exit test mode and check amounts/currencies. Obtain separate merchant approval for any real-money test. | Live settings are approved and reconciliation has an owner. |
| 8 | Inventory | Source of truth and synchronization | Merchant + integration provider | Define the stock source of truth and test order/inventory updates. | Direction and latency are documented; no duplicate or incorrect movement. |
| 9 | Invoicing | E-document scope and method | Merchant + Turkish tax adviser | Assess applicable Turkish e-document requirements against current GİB guidance and the actual business model. | Adviser determines scope; technical implementation follows that decision. |
| 10 | Invoicing | Order-to-document mapping | Technical team + invoicing provider | In an appropriate test environment compare customer, lines, tax, discount and shipping fields. | Document and order reconcile; test data is not confused with real fiscal documents. |
| 11 | Accounting/warehouse | Accounting, ERP and warehouse scope | Merchant + provider | If needed, document records, directions, frequency, versions and failure ownership. | Invoice issuance and accounting/warehouse sync are separate scopes; non-applicability is justified. |
| 12 | Shipping | Zones, rates and delivery information | Merchant + technical team | Test representative destinations, cart values, weights and free-shipping conditions. | Checkout rates agree with the merchant-approved delivery information. |
| 13 | Shipping | Labels, tracking and notifications | Technical team + shipping provider | Create a test shipment and check tracking and customer links. | Correct order/tracking match; live rates, labels and tracking are verified separately. |
| 14 | Marketplaces | Product, price and order synchronization | Merchant + integration provider | If a channel is used, test sample SKUs, prices, stock and incoming orders. | Source/direction are documented with no duplicate orders or conflicts; otherwise mark not applicable. |
| 15 | Policies | Merchant-approved policies | Merchant + legal adviser + technical team | Compare contact, delivery, return and contractual pages with approved versions. | Required content/links are correct and legal wording has adviser approval. |
| 16 | Policies | ETBİS and official filings | Merchant + adviser | Assess applicable registrations/notifications using current official sources and the business model. | Ownership and evidence are recorded; universal applicability is not assumed. |
| 17 | Data/consent | Cookies, data flows and analytics | Merchant + legal adviser + technical team | Inventory tools/data flows and test accept, reject and change-preference paths against the approved consent design. | Tool behaviour matches approved choices; transfer/retention decisions are documented. |
| 18 | Data/consent | Marketing permissions and İYS | Merchant + adviser + messaging provider | If marketing is planned, assess permissions and any applicable İYS process; test unsubscribe. | Transactional and marketing messages are separated with permission/unsubscribe ownership. |
| 19 | Communications | Domain and sender authentication | Technical team + merchant | Check HTTPS, domains, form delivery and DNS records required by the actual email service. | Pages load securely, form delivery reaches the intended inbox and provider authentication checks pass. |
| 20 | Communications | Order and shipping notifications | Merchant + technical team | Test message links, support details and amounts in the chosen language. | Correct recipient/language/order data; an order email is not treated as a fiscal invoice. |
| 21 | SEO | Indexability and migration URLs | Technical team | Check intended crawl/index controls, canonicals, sitemap, Search Console access and any migration redirects. | Intended pages are accessible, staging blocks are removed and sample redirects work; no ranking guarantee. |
| 22 | Measurement | Events and lead validation | Merchant + technical team | Validate purchase and relevant lead events through an actual permitted test journey. | Expected events record once with correct values; test data is separated from performance reporting. |
| 23 | Returns | Cancellation and partial/full refund | Merchant + providers | Check payment, stock, invoice and shipping consequences in appropriate test environments. | Refund/document tasks have owners; partial refunds and restocking decisions reconcile. |
| 24 | Handover | Mobile and end-to-end order journey | Merchant + technical team | Complete product-to-payment, inventory, document, shipping and return checks on representative devices. | No critical failure remains; evidence is stored with personal data redacted. |
| 25 | Handover | Training, scope and support | Merchant + technical team | Train the operator and document recovery approach, change plan and support limits. | Merchant can perform core tasks; acceptance, open issues and support scope are recorded. |
Additional checks for international brands
| Check | Owner | Evidence required |
|---|---|---|
| Seller, importer and returns responsibilities | Merchant + advisers + logistics provider | Written responsibility map for the selected operating model |
| Turkish-language experience | Merchant + qualified reviewer | Reviewed product, checkout-available text, emails, help and policy content; no unsupported promise of full checkout customisation |
| Prices, currencies and settlement | Merchant + payment provider + adviser | Approved customer display, checkout currency, settlement and refund assumptions |
| Delivery and border costs | Merchant + logistics/customs adviser | Agreed delivery terms, customer-facing information and exception handling |
| Customer support | Merchant | Responsible team, Turkish support capability if promised, hours and escalation route |
| Data flows and vendor access | Merchant + legal adviser + technical team | Reviewed international vendor/data flows and appropriate access/consent design |
Avoid common scope mistakes
A shipping-rate rule is not proof of label or tracking integration. Issuing an invoice is not proof of accounting or warehouse synchronization. A visible cookie banner is not proof that tracking respects the approved consent choices. Translation is not local legal review.
Use provider-supported test environments where available. A real-money payment or refund needs the merchant’s explicit approval and may incur fees. Before launch confirm that test mode is disabled and that a named person will monitor initial live orders. Shopify test-order guidance
A practical example
Hypothetical scenario: A European apparel brand chooses to fulfil from an overseas warehouse. Before launch, it defines the contracting seller, obtains advice on import/document responsibilities, agrees delivery and return handling, and verifies that the chosen provider supports its actual entity. It then tests Turkish-language customer communications and the relevant order journey. This is an illustrative workflow, not a completed Pratikis case study.
Budget by responsibility
Separate implementation labour from Shopify subscriptions, theme/app licences, payment fees, document usage, carrier charges, translations and professional advice. Agree which system owns each record, what is included, what needs an additional scope and who maintains the integration.
Release decision
Do not sign off an affected workflow while critical payment, inventory, document, data or order-processing errors remain unresolved. Record non-critical outstanding items with owners and dates. The merchant, implementation team and relevant advisers approve their own areas. A checklist does not replace their professional responsibilities.
Frequently asked questions
Do we need a Turkish company to sell to Turkish customers?
This checklist does not determine that. Cross-border and local models differ. Obtain advice for the actual seller, goods, import arrangements and operating model before implementation.
Does Shopify Payments support every store targeting Turkey?
No such assumption should be made. Provider eligibility relates to the actual business and its supported conditions, not merely the language or destination market.
Do all businesses need the same invoice and registration integrations?
No. Establish the applicable requirements first, then choose suitable providers and technical scope.
Is this a compliance certificate?
No. It is an operational and technical planning resource. Legal, tax, customs and data-protection decisions require appropriate professional review.
What can Pratikis help implement?
Store setup, theme development and separately scoped integration work can be discussed based on the project requirements. Incorporation, tax, customs and legal advice require the relevant qualified advisers.
Discuss implementation
Review Pratikis Shopify theme development and implementation scope or submit your requirements, budget and intended start date. The service page is available in English; the project application page is in Turkish. You can describe your requirements in English. An initial 15-minute fit call is for scope, budget and timing. Store-specific analysis, architecture and implementation are separately scoped paid services; the call is not a free consulting workshop.
Primary sources
Last checked: 31 October 2026. Recheck provider and official conditions before publication and implementation.
