An international Shopify store is not governed by the number of apps installed. It is governed by the task, market, and data boundary assigned to each app. Translation, currency, tax, duties, shipping, catalogs, checkout, orders, and customer data interact, but they do not share the same acceptance test. A reliable app stack makes responsibility explicit, keeps permissions explainable, verifies market behavior, and provides a safe way to leave when a feature is no longer needed.
This guide turns app selection into an operating method. Start with a task map, set compatibility gates for markets and checkout, read scopes before approval, inspect privacy and developer signals, test extensions and localization, then define uninstall and recovery steps. No app is treated as a universal answer, and an app's display is not treated as the same thing as a Shopify setting. The Shopify app selection guide can be used as a companion for organizing the initial requirements.
1. Start with an international task map
Distinguish translation, currency, tax, shipping, and data jobs
Break “internationalization” into observable jobs instead of using one broad app label for every problem. Translation handles language, selectors, coverage, and text shown across the store. Currency work handles market currency, exchange rates, rounding, payment, and refunds. Tax and duty work handles tax display, duties, product classification, origin, and collection responsibility. Shipping work handles countries, markets, shipping zones, and rates. Data work handles orders, customer fields, permissions, retention, and deletion. These jobs can coexist, but their acceptance objects are different.
Write the input, output, and owner for each job before deciding whether an app is needed. A translation job may take product and page content as input and produce localized storefront text; a shipping job may take a market and address and produce eligible methods and rates. This prevents an app that appears to cover international work from receiving access that the task does not require.
| Job | Primary objects | Questions to answer | Exit signal |
|---|---|---|---|
| Language and translation | Products, pages, selectors, checkout text | Which pages need translation, and who maintains each language? | Coverage cannot be verified, or one output cannot be disabled |
| Currency and pricing | Market currency, rates, rounding, payment, refunds | Can displayed currency and charged currency be tested separately? | Rate, rounding, or refund differences cannot be explained |
| Tax and duties | Tax display, duties, classification, origin | Which fields come from store settings, and which are only estimates? | An app display is treated as a final customs result, or fields are not traceable |
| Shipping and availability | Markets, countries, zones, rates | Does the address receive an eligible rate, and is the product eligible in that market? | A product is visible but checkout has no valid shipping choice |
| Customer and order data | Customer fields, orders, exports, retention | Why does the app need each field, and how are deletion and export handled? | Purpose, retention, or erasure path cannot be explained |
The map turns an app from a feature list into a bounded responsibility. If an app touches translation and customer data, assess both surfaces rather than letting the translation function hide the data access. If a job can be handled by Shopify market, catalog, or checkout settings, treat those native settings as the baseline and assess whether the app adds a clear, reversible capability.
2. Set compatibility gates
Ask which market, channel, and checkout surface an app touches
Shopify Markets groups audiences and supports market-specific currency, language, pricing, product availability, domains, taxes, and shipping options. When reading Shopify Markets, focus less on how many regions an app mentions and more on whether it reads, overrides, or merely displays those settings. An app that organizes translation in the admin has a different compatibility profile from one that writes information into the product page, cart, checkout, or order record.
Use four gates for every app. The market gate identifies the markets it processes. The channel gate identifies whether it appears in the online store, admin, or another selling surface. The checkout gate asks whether it changes price, tax, duties, shipping, or address validation. The data gate asks whether it touches customer or order fields. If one answer is unavailable, keep that item open for verification instead of approving the install.
| Compatibility gate | Question | Evidence to retain | If it fails |
|---|---|---|---|
| Market | Which market, catalog, or market customization does it depend on? Does it distinguish inheritance from an override? | Market name, catalog assignment, and current setting view or export | Limit the test to one market and pause wider changes |
| Channel | Does the feature appear on a product page, theme, admin page, cart, or checkout? | Feature location, role access, and visibility condition | Ask the developer to explain the entry point before continuing |
| Checkout | Does it change currency, tax, duties, shipping rates, or address collection? | Expected and observed results for one full checkout path | Separate the app output from Shopify settings and compare each |
| Data | Does it read store data, customer data, orders, or protected fields? | Scope name, purpose, privacy policy, and erasure path | Do not approve unexplained fields or broad access |
| Exit | What happens to theme code, charges, workflows, locations, and data after disablement or uninstall? | Exit steps, residue checks, and support contact | Keep it away from a critical path until a rollback exists |
Write each gate as an if-then decision. If an app only handles language content, a translation task should not justify unrelated customer fields. If it displays tax at checkout, acceptance must include buyer market, currency, address, and order record. The Shopify Markets setup guide is useful when the market baseline needs to be restated.
3. Read permissions before installation
Match requested scopes to the task
The install screen exposes requested store or customer data permissions and the developer privacy policy. On installing and setting up apps, translate each requested permission into plain language: what is read, why it is read, whether anything is written, and which workflow uses it. Do not infer the access boundary from an app name or a feature image.
Shopify's developer guidance is to request the scopes required for the task rather than excessive scopes. Scopes can change, protected fields may be redacted, and some access may require additional approval. Use manage access scopes to check what a scope means. A useful approval record has at least four columns: task, required fields, read or write behavior, and a shutdown or replacement option. If the explanation does not map to the task list, return it for clarification.
Permission review is also time-sensitive. The range shown at installation should not be treated as a permanent promise; when settings change or an app requests additional access, reassess the impact. For customer data, separate “can access” from “should access”: narrow the fields first, then verify how they are protected, retained, exported, and erased.
4. Protect customer data
Minimize fields, access, retention, and exports
The first customer-data question is not whether an app can obtain a field. It is whether the task actually needs it. Protected customer data calls for minimizing access, explaining purpose, securing the data, and requesting access appropriately. List email, phone, address, order details, and other customer fields separately; do not let the phrase “customer data” conceal the real fields.
For every field, define the reader and the lifecycle. Which feature reads it? Which admin role can see it? Is it exported to another destination? Who performs retention and deletion? If an app needs order status but asks for a complete customer profile, request a narrower design or decline the install. If a field may be redacted, include the no-access behavior in acceptance rather than treating redaction as a random failure.
| Data dimension | Minimization decision | What to verify | Response to a mismatch |
|---|---|---|---|
| Fields | Keep only fields required to complete the task | Does each scope map to a field and a feature? | Remove unrelated fields or ask why they are necessary |
| Access | Limit the app feature, role, and interface | Who can see it in admin, and which calls touch it? | Tighten role and scope; document paths that must not access it |
| Purpose | Give every field a readable purpose | Do the privacy policy and app interface agree? | Pause that field and ask the developer to clarify |
| Retention | Define retention, deletion, and reinstall handling | How are uninstall, disablement, and deletion requests different? | Create a deletion confirmation step; do not treat uninstall as complete |
| Export | Allow only the required format and destination | Who exports, how often, where does it go, and how is it protected? | Stop unnecessary exports and inspect copies already created |
International operations can change the context in which data is viewed. A support agent may need an address to explain an order; that does not mean a translation app should continuously copy the address. Separate localization needs from customer-data needs so privacy review and exit scope stay precise.
5. Verify developer and privacy signals
Record policy ownership and support paths
When finding and choosing apps, inspect data access, erasure behavior, developer information, and whether the app accesses all orders in addition to its feature claims. The developer privacy policy should identify the responsible party, purpose, and contact route. A broad phrase such as “improve the experience” without field-level and deletion detail is not a sufficient explanation.
Support paths should match the fault boundary. A price or tax display issue may require the store settings owner. A permission or customer-data issue may require the developer and a privacy contact. A missing extension or theme residue requires checks in both Shopify admin and the theme. Record who to contact, which logs are needed, and which customer fields must not be sent during diagnosis.
Shopify's App Store requirements identify behavior, checkout use, TLS, scopes, sync accuracy, privacy, and truthful representation as review concerns. This is not a promise about an app's outcome; it is a responsibility boundary to inspect. If a custom capability is being considered, the Shopify app development guide can help frame the maintenance scope before accepting it.
6. Evaluate catalog and localization behavior
Test products, languages, and market inheritance
Catalog membership determines product eligibility in a market. Shopify's creating catalogs for markets describes a catalog as products, with optional prices, assigned to a market; a product must be in that market catalog to be visible and purchasable there. If an app synchronizes products, translates titles, or writes market fields, verify that it respects catalog assignment instead of checking only a default market.
Market customizations have inheritance behavior and can be overridden at the market level; see adding or removing market customizations when a setting changes. Market matching may use IP, browser, domain, or manual selection. IP can be inaccurate, so test a selector together with a shipping-address check. Domains, language assignments, translation coverage, hreflang, sitemaps, and checkout-language limitations also require separate checks; a localized page is not proof that product eligibility is correct.
| Surface or object | Inspect first | Test action | Pass condition |
|---|---|---|---|
| Product availability | Market catalog and product state | Check one included, one excluded, and one review-needed product | The result matches catalog assignment, and the excluded product cannot be wrongly purchased |
| Language | Translation coverage, selector, and checkout text | Switch language and continue to cart or checkout | Critical text has an explicit expectation, and missing text does not mislead |
| Domain | Market domain, subdomain, or subfolder | Visit the domain and manually select a market | The domain signal does not place the buyer in the wrong market |
| Inheritance | Default settings and market overrides | Record the default, then change one market customization | Only the expected market changes, with an explainable override |
| Matching | IP, browser, selector, and shipping address | Change the signal and enter checkout with a target-country address | Market choice and address check do not contradict each other |
The app's localization output should be treated as a presentation or workflow layer, not as a replacement for catalog and market settings. The Shopify localization guide is a useful companion for content checks; the actual pass condition is consistency across product, market, language, and checkout expectations.
7. Evaluate pricing, duties, and checkout behavior
Separate app output from Shopify settings
An international app may display prices, tax, duties, or shipping information, but a display layer is not automatically the calculation or collection owner. Shopify's pricing in local currencies ties local browsing, payment, and refunds to payment and checkout configuration. Currency, rates, conversion fees, rounding, refunds, and chargebacks also need review through currencies for markets. Compare app output with the order record and store settings rather than accepting a product page alone.
Tax and duties are separate checks. Tax display, tax-inclusive behavior, classification, origin, and collection responsibility form one set of market settings. Duties, import tax, and brokerage can also depend on classification, origin, a DDP-capable carrier, and actual customs handling. Shopify's guidance on setting up duties and taxes for markets and duties and import taxes is not a universal tax conclusion. In checkout, inspect each displayed line item and distinguish an estimate from a cost that can still vary.
Shipping is another independent gate. A country needs to be in an active market and a shipping zone with rates for a buyer to select shipping at checkout; see shipping zones and markets. Shopify Checkout collects shipping and payment information and evaluates inventory during the flow; inventory is held only after payment details are submitted, as described in Shopify Checkout. If an app changes front-end copy without changing those native conditions, do not attribute a native gap to the app, and do not treat the app display as a collection guarantee.
8. Review extensions and admin surfaces
Identify where a feature appears and how it is removed
An app feature may appear in the theme, admin, product editor, order page, or a checkout-related surface. App extensions bring app functionality into Shopify while still involving authentication and rate limits. During acceptance, map the path from entry to read, write, display, and removal: who sees the control, what it changes, what happens on failure, and what disappears after disablement.
Do not inspect only the app switch. Managing apps helps review activity, permissions, privacy details, and unused access. If a feature enters the theme, check whether theme code or snippets remain and whether a page still loads them. If it touches workflows, locations, or external charges, check those separately. For a custom capability, the Shopify custom app guide can help assess which responsibilities the store would own.
Verify that an extension can actually be removed before enabling it. Can one entry point be disabled? Is a theme snippet removal required? Must scopes be revoked? Can an order or customer-data copy remain? List each entry in the exit plan so that an app disappearing from the admin list does not leave old text, an active workflow, or an external charge behind.
9. Control installation and changes
Use a small test store and an evidence checklist
Start with a narrow test space and one complete path: one market, one language, one currency, one catalog-included product, and one defined shipping address. If the task involves customer data, use the least sensitive test data and never copy real customer information just to debug. The goal is not to prove that an app is always correct. It is to identify the boundary between the app and Shopify settings.
Use one checklist for every install or settings change. Capture permissions, market customizations, catalog assignment, language and domain, currency, and checkout expectations before the change. After the change, retest each item and classify the mismatch as app output, Shopify configuration, or input signal. Installing and setting up apps and manage access scopes provide useful permission checkpoints.
| Change point | Before the change | After the change | Rollback action |
|---|---|---|---|
| Permissions | List each scope, purpose, and field | Confirm the actual request matches the approved range | Decline unrelated access and pause the affected feature |
| Market and catalog | Record defaults, overrides, and product assignment | Retest with View as, a direct product path, and the selector | Restore the last explainable catalog and override settings |
| Language and domain | Record target language, domain, and selector expectation | Check page, cart, and checkout text | Close the new entry and restore the prior mapping |
| Price, tax, and shipping | Record currency, rounding, tax, duties, and rates | Run a full checkout with the target address | Restore each changed setting without stacking another adjustment |
| Extension and theme | Record entry point, theme snippet, and admin location | Disable, refresh, and inspect for residue | Disable the extension and remove only confirmed residue |
Change one control point at a time. If the market, language, currency, and app settings all change together, an unexpected result cannot be assigned confidently. Keep observed pages, order records, permission screens, and setting values in one review record so the next check does not depend on memory.
10. Plan uninstall and data erasure
Check theme residue, charges, workflows, and locations
Uninstall is a process rather than a single button. Uninstalling apps notes that theme code may remain and that recurring or external charges, data retention, locations, workflows, and reinstall behavior need attention. List every entry point and field used by the app before deciding the order of disablement, uninstall, theme cleanup, and data-erasure requests.
Before uninstalling, preserve necessary store configuration and permission information without creating wider customer-data copies. Identify which information remains in Shopify records and which has moved to the app or another destination. Ask the developer how deletion, retention, and reinstall are handled. If protected customer data is involved, specify the fields and erasure request and keep a confirmation that does not contain sensitive values.
Check exit in four layers. First, the app list and scopes should no longer be needed. Second, theme code, admin entry points, workflows, and locations should be checked for residue. Third, external charges, retention, and reinstall behavior should be confirmed. Fourth, a market's product, language, price, shipping, and checkout path should return to an explainable state. If one layer is unclear, do not mark the exit process complete.
11. Reconcile app data with Shopify records
Define mismatch ownership and retry behavior
Reconciliation is not just comparing one amount. List products and catalogs, markets and languages, currencies and prices, tax and duty line items, shipping rates, orders, and customer fields separately. For each item, identify whether Shopify settings, app output, or human input is the controlling point. When the two sides differ, correct the controlling point before deciding whether to retry a sync.
When a sync fails, retain only enough evidence: market and country, an internal product or order label, time, displayed state, address type, scope range, and relevant setting values. Do not send a full customer profile or unnecessary order export to support. If authentication or rate limits are involved, confirm whether the call succeeded and whether it wrote twice before making one bounded retry; repeated clicks are not a responsibility model.
The app requirements' focus on sync accuracy, privacy, scopes, and truthful representation gives useful questions for review, not a promise about a particular tool's output. For inventory, pricing, translation, or order status, define who corrects a mismatch before defining how long to retry. If the same discrepancy returns, pause the path and revisit scopes, market inheritance, input signals, and the app's handling explanation.
12. Maintain the stack over time
Recheck scopes, policies, compatibility, and exit readiness
An international app stack needs review when change occurs; installing an app once is not permanent governance. When a market, language, currency, shipping zone, tax setting, or checkout text changes, rerun the compatibility gates. When an app requests new access, changes its privacy policy, changes an extension entry point, or interacts with a changed Shopify setting, reassess the task map. Managing apps helps review activity, permissions, and privacy details.
Every review should answer four questions. Is the app still solving the original task? Is its data access still minimal? Is its behavior across catalogs, markets, languages, prices, duties, shipping, and checkout still explainable? If it were disabled today, could the store restore its theme, workflows, locations, charges, data handling, and buyer path? If one answer is no, put that item into the next work cycle instead of substituting app count or promotional language for evidence.
Use change triggers to organize reviews: market changes call for catalog and inheritance checks; tax or duty changes call for price and checkout line-item checks; language or domain changes call for selector and coverage checks; permission changes call for customer-data checks; extension changes call for entry and exit checks. Shopify capabilities and regional requirements change, so check current admin settings and official documentation before acting. The outcome of governance is not more apps; it is an app stack in which every app can explain its task, boundary, evidence, and exit.
Frequently asked questions
How do I decide whether an international app is actually needed?
Write the task as an input, output, and acceptance condition first. Then check whether Shopify market, catalog, currency, tax, shipping, checkout, and language settings already cover it. An app is worth a narrow test only when it fills a defined gap and can explain its permissions, market compatibility, data handling, and exit steps. Do not combine unrelated jobs merely because an app label says “international.”
Can I reject every permission except the smallest possible set?
Use the smallest set required for the task, but do not reject permissions arbitrarily. Confirm which fields must be read or written and what stops working if access is removed. Ask for a clearer purpose, protection, retention, export, and erasure path when needed. An unexplained scope should not be approved, and broad access should not be accepted simply to make a feature run.
Why can a product remain unavailable even when an app translated it?
Language display and product eligibility are separate. The product still needs to be in the relevant market catalog, while inheritance or a market override can change the result. The destination country, shipping zone, and valid rate can also affect checkout. Check the selector, direct product path, catalog assignment, and target address in sequence so translation, catalog, and shipping defects remain distinct.
Does uninstall automatically delete every piece of data and page residue?
Do not assume that it does. Theme code may remain after uninstall, and recurring or external charges, data retention, locations, workflows, and reinstall behavior need separate checks. Review the app list, scopes, theme, admin entry points, external destinations, and the developer's deletion process. Treat erasure as complete only when each layer has a clear confirmation.
Should I change Shopify settings or install the app first when expanding a market?
Start with the task map and compatibility gates, then establish a baseline with one market and minimal data. Record Shopify expectations for market, catalog, language, currency, tax, shipping, and checkout before installing or enabling the app, and change one control point at a time. This makes it possible to assign an anomaly to app output, native settings, or an input signal and restore the last explainable state.