Doukua

Shopify Markets launch checklist: verify currency, shipping and test orders

Approve one international market with a test record: check currency, shipping, payment, customer promises and unresolved evidence before launch.

TASKOne-market order journey acceptance record
ACTIONFix one market, SKU set and revision; record the test environment.
DONE WHENOne scope has recorded order and support outcomes; all blockers pass a retest before this scope is marked accepted.

Complete the page record ↓

On this page

Decide whether one market is ready to launch

Use this playbook if you already have physical products and a Shopify store, and need to approve one international destination. The result is a launch record with evidence, unresolved issues and a named owner. A translated product page or an active market is not proof that the customer can pay and receive the order.

Prepare a representative SKU and variant, an authorised test account, a destination address you may use, your shipping quote, returns policy and current payment configuration. Check the store's actual capabilities; this method does not establish product legality or tax registration. Official documentation checked on 5 October 2026.

Fix the scope before testing

Write the destination, intended customer, first SKU group, fulfilment origin, storefront language, expected checkout currency, payment provider and owner. Treat a different shipping route, currency or restricted product as a new test condition. Start with one destination rather than assuming that a regional label proves coverage of every country.

Create or review the market in the Shopify admin. A draft can be previewed before it is exposed to buyers. Before activation, Shopify requires shipping rates for the countries in the market. Record the configuration you actually see, including inherited settings. Source: Creating and activating markets, in the official source directory below.

Check currency at the shipping-address step

Record currency and total on the product page, cart and checkout, then enter the destination address. Test the intended provider rather than assuming that a currency selector proves local-currency payment. Shopify documents destination-based checkout restrictions for physical goods with a shipping address; behaviour depends on one-page checkout access and payment configuration.

For an eligible local-currency setup, changing the delivery country can change the checkout currency. Keep screenshots before and after that change and compare them with the intended market. Digital goods have a different restriction scope and should not reuse this physical-goods acceptance record. Source: Understanding checkout restrictions, below.

Your result must show what the customer pays and how the store settles. If checkout uses a different currency than the storefront promise, pause that promise, identify the configuration or provider limitation, and repeat the test. Do not insert an assumed exchange rate or fee into the evidence.

Test shipping with a new checkout

Open a fresh checkout after changing rates. Shopify notes that an abandoned checkout retains earlier rates, so it can produce misleading results. Check the product's physical-shipping setting, weight and inventory location, the destination's active market, and the applicable shipping configuration. Some stores use shipping profiles; others have migrated to shipping options by market. Follow the setup present in your store.

Run one standard address, a permitted remote-area address if relevant, and carts just below and above your own shipping threshold. Include a discounted cart and a mixed cart when you sell items fulfilled from different locations. These are Doukua test recommendations; they are not a universal Shopify requirement.

For each case, record the expected rate from your configuration, the actual rate, service name and delivery wording. A missing rate blocks launch. An unexpected combined rate requires investigation before you advertise free or flat-rate delivery. Source: Troubleshooting and testing shipping rates, below.

Run payment tests without interrupting buyers

Shopify supports its test gateway and Shopify Payments test mode on eligible paid-plan stores. Customers cannot place live orders while payment providers are in test mode. Schedule an authorised test window or use a suitable non-live store; do not silently switch a trading store into test mode. Test orders from supported simulated gateways are not real revenue or payouts.

Check a successful payment and a supported failure scenario, then verify order status, inventory and notifications. Where a real payment is necessary, obtain authorisation and plan cancellation or refund; processing fees may still apply. Record the actual refund result separately from the request. Source: Placing a test order, below.

Make taxes, delivery and returns understandable

Compare the product page, cart, checkout, order notice and policy pages. Write whether taxes are included, what remains estimated, who bears import charges, how dispatch differs from transport time, and where a buyer requests a return. Use confirmed account settings and route terms; this checklist does not decide tax liability, customs classification or consumer-law obligations.

If responsibility or a required product document is unknown, mark the issue as evidence missing and assign an owner. Do not replace an unresolved obligation with a generic disclaimer. A payment success is not proof of delivery capability or compliant goods.

Copy this acceptance record

Market and destination: ____
SKU and variant: ____
Fulfilment origin and route: ____
Language and payment provider: ____
Test date, configuration version and owner: ____
Expected versus actual currency and total: ____
Expected versus actual shipping rate: ____
Payment, inventory and notification evidence: ____
Cancellation/refund reference and confirmed state: ____
Tax, import-charge and return-policy gaps: ____
Decision: proceed / pause / gather evidence
Outstanding action, owner and deadline: ____
Next review date: ____

Save this record in your team's permitted document system. Reference test order IDs and evidence locations without placing customer personal details in public notes. This is a copyable working record, not a claim that Doukua has tested your store.

Apply the launch decision

Proceed only when the scoped SKU and destination have a supported payment path, expected currency and shipping result, consistent customer promises, and no unresolved blocking condition. Pause for a checkout failure, unavailable shipping or a broken cancellation path. Gather evidence when product eligibility, import responsibility or a claimed capability cannot be confirmed.

Limit approval to the tested destination and configuration. After changing a provider, rate, language, SKU group or fulfilment location, repeat the affected tests. After launch, review real order errors and support feedback; a successful test does not establish future sales or delivery performance.

Use the related localisation guide to test comprehension and the fulfilment guide to assign post-order responsibilities. In the Doukua tools menu, use Localisation review to record journey defects and Cost scenarios to test your own fee and return assumptions. They complement this launch record rather than certifying the store.

Choose the order journey to verify

Editorial working method, not an additional eligibility or fee promise. Check current official requirements for your entity, product and location.

Observed situationWhat to checkRecord and next action
Language and prices display; no completed journeyTest entry to checkout with one region, product and deviceKeep URL, product revision and outcome; display is only one check
Checkout cannot completeSeparate product scope, address, delivery and payment checksRecord reproducible conditions and assign the failing step
Test order passes; expansion plannedCheck notifications, support, refunds and cost scopeTreat a new region, language or SKU as a new scope

Separate configuration, display and delivery

StageAcceptance evidenceIf it fails
Market and productRegion, SKU scope, language/domain entry and current settingsRepair inconsistent scope or entry
Checkout and notificationsOne journey covering address, currency, delivery quote, payment and messagesLocate the last passing step and preserve the error
After-sales responsibilityReturns wording, contact path, costs and ownersPause expansion when promises exceed the checked capability

Run a reviewable check

  1. Fix one market, SKU set and revision; record the test environment.
  2. Walk from visitor entry to checkout and record each observed result.
  3. Use a controlled test method for orders, notifications and support; avoid repeated live charges.
  4. Repair blockers and repeat the original journey; record new scopes separately.

One-market order journey acceptance record

Record your conditions, evidence and decision. Copy or download before refreshing. Inputs stay on this page and are not uploaded automatically.

Done when: One scope has recorded order and support outcomes; all blockers pass a retest before this scope is marked accepted.

Decision questions

Does a language switch complete localisation acceptance?

Continue through product, price, address, delivery, payment, notification and support in the same journey.

Does one passing region cover other regions?

List differences in products, quotes, language and fulfilment. Reuse only evidence that applies to the checked scope.

Official source directory

The steps above are editorial working methods. Verify eligibility and changing rules for your own product and operating location.

Suggest a correction →