Verify store identity and regional settings at the start
For store management, the first ikas setup check is whether administrative information and customer-facing information are used in the right places. The official store-settings guide explains that values can appear in emails, payment screens and operational documents. Inspect seller identity, brand imagery and contact channels in representative customer outputs. Do not assume the telephone used by operational providers is the same field as the customer’s support number.
Verify currency, default language and time zone against the source decisions. For example, reporting day boundaries and a campaign start can be interpreted incorrectly when staff assume different time zones. Changes to foundational settings after orders begin need planned review. Record the setting, current value, business approval and test output. A populated admin field is not by itself proof that the intended business rule has been implemented.
Test products, variants and category paths together
When reviewing product-data quality in an ikas catalogue, inspect how each record is presented to a visitor too. Product titles, images, options, stock sources and category paths belong in the same review. Note how the source-file field maps to the destination. One successful example after a bulk operation does not establish that all products are accurate; prepare a sample representing different record types.
For example, a product sold through size-and-colour combinations needs the price and availability of the actual combination checked. A technical product may have a complete title but lose dimensions or an associated file. Navigation should open a category consistent with the product classification. Do not fill gaps with nonexistent reviews, measurements or contents. Missing source information becomes a visible task for the product owner rather than being disguised by layout.
Source mapping
Compare product identifiers, variants and necessary custom fields with the destination record. Define an alternative for information lost in a representative transfer.
Storefront selection
Try colour, size or other options with their images and prices. Verify the exact combination added to the basket.
Category access
Reach products from navigation, category and search paths. Assess empty categories and incorrect targets with the data and design owners.
FROM READING TO A NEXT STEP
Review the unresolved item in your ikas setup
Share the store, current package and scenario you cannot validate. We can define the first review without requesting customer records.
Verify package, domain and payment access in the live account
During launch preparation, do not apply every statement on an ikas help page automatically to your current package. Plan, purchase period, country and active applications can affect access. Research found different statements about domain availability across official pages. Validate the conditions in your own admin and, where necessary, obtain a current response from ikas support before recording the result.
If a domain will be connected, identify the authorised account owner, existing records and release window. Review DNS records used by other services such as email. Confirm the active payment provider, business approval and supported test method. A payment logo in the theme does not establish that the account is ready to take transactions. Legal, financial and provider approvals are not decisions made by the technical team; they remain explicit project dependencies until authorised.
Test shipping, stock connections and campaign boundaries
Where ERP and store integrations exist, compare ikas stock and order information with surrounding systems. Shipping choices, dispatch sources and unsupported-address behaviour should express the real business rule. Test whether a free-shipping statement agrees with checkout conditions. Do not assume the current carrier or integration supports every delivery arrangement.
For a campaign, test timing, selected products, basket thresholds and interaction with other discounts. For example, a two-product basket may trigger a discount while one product of the same value does not; write the intended rule before judging the outcome. Missing weight or package measurements cannot be treated as proof of a correct delivery charge. The objective is to verify implementation of approved rules, not guarantee a carrier agreement or physical transport outcome. Keep provider-specific constraints visible in the checklist.
Address and method
Try supported and unsupported addresses. Record choices, charges and the explanation given to the customer together.
Stock source
Check variant and location data through a representative order. Make delays or mismatches in connected systems visible to an owner.
Campaign boundary
Test below, above and outside the condition. Include timing, product selection and other-discount interactions in the notes.
Match order records with notification workflows
Automation workflows in an ikas store should reflect actual order states. The official order-detail guidance describes the screen used to follow an order’s movements. Authorised staff should locate a representative transaction and interpret payment, shipping and cancellation status. Adding a label or changing an admin status does not prove that every connected system has received the same outcome.
Review product, amount, contact information and language in customer emails. If another service or application sends additional notifications, investigate repetition and conflicting status messages. For example, a cancellation request’s financial outcome and the explanation given to the customer should follow the same approved decision process. Make support hours and response ownership clear. Enabling an automation does not establish uninterrupted customer-service coverage. Record exception handling as well as the normal path.
Staff rehearsal
Locate the sample order, read its stages and complete the permitted action. Make both permissions and task ownership visible in the test.
Customer message
Compare transactional email with the actual record. Document old contacts, incorrect items or text left in another language.
Exception record
Assign decisions for failed payment, cancellation or missing shipping information. Do not promise a definite result while the state remains uncertain.
Complete handover with mobile and measurement checks
Within the measurement plan, verify that product consideration, basket and purchase events match the relevant actions. Review installed applications and permission choices together. Repeated counting of one order or a test transaction appearing as real revenue is a separate finding. Telephone numbers, email addresses and free-text messages do not belong in analytics events. Explain that reports can follow different source definitions.
Test navigation, selection and basket tasks on mobile with real content. Promotion or chat components should not cover important actions. Handover includes tested settings, open dependencies and operational owners. Use complete, incomplete or not applicable for each task and repeat affected checks when packages or applications change. The store address, current package and unresolved scenario are enough to begin a discussion; passwords and customer records are unnecessary. The result should help staff operate the installation, not only show that configuration fields were filled.
Get the checklist and discuss your scope
Your email and phone are used for this request. This does not subscribe you to a newsletter.
BEFORE YOU DECIDE
Frequently asked questions
Can every ikas package connect a custom domain?
Verify current package and account conditions through your admin or ikas support. Research found differing statements across official pages, so a single general statement should not be applied to every store. Record the current confirmation as evidence.
Does bulk upload complete the catalogue?
No. Compare variants, stock, imagery and custom fields through representative records. Source data and storefront behaviour can differ. Record the product owner’s decision for missing or unsupported information.
Are we ready to sell when a payment logo is visible?
The logo is not proof of account activation or successful processing. Validate the active provider, approvals and supported test method. Technical implementation does not guarantee provider acceptance.
Does a shipping integration cover every order type?
That depends on the agreement, provider and installation. Test address, product class, location and delivery arrangements separately. Unsupported options need an understandable customer-facing explanation.
Is changing an order status the same as completing a refund?
No. An admin-state change and a financial transaction can require separate verification. Authorised staff follow the provider’s supported method, and customer communication reflects the actual approved result.
What should we recheck after changing a package or app?
Review affected product, payment, shipping, notification, theme and measurement scenarios. Previous acceptance is not evidence for the changed configuration. Update open dependencies and staff permissions too.
LET’S DEFINE THE SCOPE
Review the unresolved item in your ikas setup
Share the store, current package and scenario you cannot validate. We can define the first review without requesting customer records.
Discuss your ikas setup check