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 situation | What to check | Record and next action |
|---|---|---|
| Language and prices display; no completed journey | Test entry to checkout with one region, product and device | Keep URL, product revision and outcome; display is only one check |
| Checkout cannot complete | Separate product scope, address, delivery and payment checks | Record reproducible conditions and assign the failing step |
| Test order passes; expansion planned | Check notifications, support, refunds and cost scope | Treat a new region, language or SKU as a new scope |
Separate configuration, display and delivery
| Stage | Acceptance evidence | If it fails |
|---|---|---|
| Market and product | Region, SKU scope, language/domain entry and current settings | Repair inconsistent scope or entry |
| Checkout and notifications | One journey covering address, currency, delivery quote, payment and messages | Locate the last passing step and preserve the error |
| After-sales responsibility | Returns wording, contact path, costs and owners | Pause expansion when promises exceed the checked capability |
Run a reviewable check
- Fix one market, SKU set and revision; record the test environment.
- Walk from visitor entry to checkout and record each observed result.
- Use a controlled test method for orders, notifications and support; avoid repeated live charges.
- Repair blockers and repeat the original journey; record new scopes separately.
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.