Shopify Store Sign-Off Checklist Before Final Payment

You have seen demos, reviewed the theme design, maybe even tested it yourself. The store looks ready, and the developer is asking for final payment. But ready and tested are different things. A store that works for ten minutes in a demo often fails when real traffic arrives, real payments process, and real customers need support. This guide covers what you should verify before you sign off, so you catch problems while the developer is still responsible for fixing them.

Everything below assumes the store is live or about to go live. If your developer built it in their own Partner development store, ownership has to be transferred to you before anything else on this list means much. If you are changing developers rather than launching, our developer handover checklist covers that situation.

Can you log in and have full access?

Start with ownership. You should log in with your own email address as the store owner and see everything in the admin. If the store is still registered to the developer's email, or they suggest you work from a staff account for now, ask why. Final payment is the point where the store becomes fully yours, and that should be true in the admin, not just in the contract.

Check three specific things. First, go to Settings, then Users. Your developer should appear as a collaborator, never as the owner. Decide whether they stay (for example, on a support period) or are removed at sign-off, and note it in writing. If they are leaving, remove the collaborator account and generate a new collaborator request code in the Security section, so the old code can no longer be used to request access.

Second, confirm the store contact email in Settings, then General, and the email and phone number on your own login. These are what Shopify uses for store notices, login codes and account recovery. If any of them is still the developer's address or a shared phone, change it now.

Third, check your password recovery options. You should be able to receive email at your owner address, and two-step authentication should be set up with an authenticator app only you have access to, not an SMS code to a shared phone. Shopify's two-step authentication guide covers the options.

Can you place a real test order with payments?

A store that displays products and a store that takes orders are two different things. Place a full order from browsing to the thank you page. This tests the checkout flow, the payment connection, the order record and the emails in one go. Shopify documents three ways to do this in its guide to placing test orders: the Test payment gateway, a payment provider's test mode, or a real order that you immediately cancel and refund, which may cost you processor fees.

If you use Razorpay or Cashfree, ask the developer to show you a test order running through the gateway you will actually use, not only through Shopify's test gateway, because that is the connection real customers will hit. One caution from Shopify's documentation: customers cannot place live orders while your payment providers are in test mode, so make sure test mode is switched off before you sign off.

After each test order, check three things. First, does the customer receive an order confirmation email immediately? If not, your transactional email notifications may not be set up, and real customers will never know their order arrived. Email is how they track the order, request updates, and return items.

Second, can you see the order in your admin under Orders? Does it show the correct products, quantities, and prices? Does it show which payment gateway processed it?

Third, if you offer COD, test that flow separately. Place an order with COD selected and confirm it appears on the Orders page with a payment status of Pending, not Paid. Shopify treats COD as a manual payment method, so someone on your team has to mark the order as paid once the money arrives. Make sure you know who does that, and whether your courier or an app is supposed to update it.

Does the store work fast on phones?

Check speed on real numbers, not on the developer's word. Shopify shows a web performance summary on the Online Store, then Themes page, with fuller reports under Analytics, then Reports. It is built from real visitor data over the past 30 days and rates three measurements as Good, Moderate or Poor:

• Largest Contentful Paint (LCP) is how long until the main content is visible. Good is under 2.5 seconds.
• Interaction to Next Paint (INP) is how long the page takes to respond to clicks. Good is 200 milliseconds or less.
• Cumulative Layout Shift (CLS) is how much the page jumps around while loading. Good is 0.1 or less.

The thresholds above come from web.dev's Core Web Vitals. One catch: Shopify notes that a new store, or one still in password-protected private mode, might not have metrics yet, and the data can lag by up to 36 hours. If your store has not had real traffic, ask the developer to run a lab test such as PageSpeed Insights on the home, collection and product pages and share the results with you. If anything shows as poor, ask what they will change before sign-off.

Common speed problems on Shopify stores are: apps that load too much code, theme customizations that run unoptimized JavaScript, images that are not compressed, and too many product images loading at once. The developer should have tested these before handing it over. If they did not, it is a pre-sign-off issue.

Is the store complete on mobile?

Open the store on a phone (not just resizing the browser). Test the main flows: browsing to a product, reading the product page, adding to cart, checking out, and navigating the footer to find contact or legal pages. Look for layout shifts, text that is hard to read, buttons that are hard to tap, and images that load slowly on mobile.

Pay particular attention to the steps before checkout: the cart page or cart drawer, any pincode or delivery date checker, and the button that takes the customer to checkout. These are theme code, so they are your developer's responsibility, and a small layout bug here stops orders on phones while looking fine on a laptop. Our guide to reducing checkout abandonment covers what else to look for.

Are SEO and redirects set up?

If this is a redesign or migration, old URLs need to redirect to new ones. In the admin, go to Content, then Menus, then URL redirects to see what the developer set up. Shopify's URL redirect documentation also allows importing redirects from a CSV, so ask for the redirect file as part of the handover. Old product pages should point to the new product, or to its collection if the product is gone. Old category and blog URLs should point to their new equivalents.

Check that your homepage has a title tag and meta description. Open the home page in a browser, view the source (right-click, View Page Source), and look for <title> and <meta name="description">. Both should be present and should describe what your store does, not just say "Home" or "Welcome".

Do the same for a product page and a collection page. Every page should have a title and description so it shows correctly in search results. The developer should have set these up, and you should verify they did before paying them.

Are your legal pages in place?

You need a privacy policy, terms of service, a refund policy and shipping information. Shopify can generate templates in Settings, then Policies, but they have to be edited for your business before launch. Indian stores also need their GST details set up correctly for invoices, which we cover in our GST setup guide. For what your policies must legally say, check with your CA or lawyer rather than your developer.

Check that these pages exist and are linked in the footer, so customers can find them. Check that they say your business name and contact information, not the developer's name or a template placeholder. A legal page that does not belong to you is not just embarrassing. It can cause problems if a customer has a dispute.

Is your code and customization documented?

Ask the developer for a handover document that lists:

• The theme name and which version it is (in case you need to update it later).
• Which files they customised (sections, snippets, templates, CSS, JavaScript) and why. The more custom code there is, the more this list matters to whoever maintains the store next.
• Apps they installed, what each one does, and how much it costs per month or per order. Some apps charge a percentage of revenue; others charge a flat fee. You need to know which.
• Every third-party account created for the store (payment gateway, email tool, analytics, apps) and whose email it is registered to. It should be yours. Passwords belong in a password manager, not in an email thread.
• A list of all collaborators who currently have access (along with their permission level) so you know who to remove.

If your store is built with Shopify's built-in features (collections, filters, product types), this documentation is simple. If it has heavy custom JavaScript or liquid code, the documentation is more complex. Either way, you should have it before the developer leaves, because code you do not understand is code you cannot fix or change later.

What should you do if something is not working?

Before you withhold payment, give the developer a chance to fix it. Make a written list of every issue: "Checkout does not work on iPhone 13", "Performance report shows poor CLS", "Collaborator account still has access". Send it to the developer with a timeline: "These need to be fixed by [date] before final payment is released."

If the issue is small (a typo, a missing alt text on an image), you might accept it if they commit to fixing it in the first maintenance window after launch. But anything that breaks customer experience (checkout failures, broken payment processing, unresponsive pages) should be fixed before you pay them.

If the developer stops responding, keep everything in writing and refer to the milestones in your contract. For a serious dispute, talk to a lawyer before withholding a large amount. Our guide to scoping a Shopify project covers how to define "done" up front so the next project does not end this way.

Your contract should state this. It should say something like: "Final payment is released when the merchant confirms that the store meets the acceptance criteria in the contract." If you do not have a contract that spells this out, making a written list and sending it now protects you later.

If you have hired a freelancer who is now unreachable, or if fixes are taking too long, contact your payment provider and explain the situation. Most will hold a disputed payment for 30 days to give you time to resolve it. This is not ideal, but it gives you negotiating power while the developer is still contractually obligated to respond.

Want a fresh set of eyes on your store?

After sign-off. If everything checks out, pay and move on. Your developer did their job. If problems appear in the first weeks of real traffic, go to your developer first, since many include a short support period. If that does not work, we can help find out whether it is a theme issue, an app conflict or a configuration problem.

Free pre-sign-off review. Get in touch or email hello@exactwhy.com with the subject "Pre-sign-off review" and your store URL. Send us a screenshot of the Orders page with a test order visible (you can blur the customer email if you prefer). We reply within 4 hours with which acceptance tests look solid, which need rework before final payment, and what to prioritize if your developer found issues.

During the project. If everything checks out, pay them and move on. The developer did their job. But if issues show up in the first week of real traffic, get in touch with the developer first. They may offer support to fix launch issues. If they do not respond, we can help diagnose what broke and whether it is a theme issue, an app conflict, or a configuration problem.