Start by writing down what the test is meant to prove. “Shopify notifications” can refer to different systems, with different triggers and evidence. Shopify’s documentation separates customer notifications, staff notifications, and webhooks. A third-party Web Push tool is another path, managed through its own integration and sending service.

Use the table to define a test boundary before changing settings. If you are checking a buyer-facing Safari push, do not use a Shopify order email as a substitute test. If you are checking an internal staff alert, a browser prompt on a buyer-facing page is not relevant evidence.

A useful test record names the store, the test page or product, the integration, the Safari profile used, and the event that should trigger a notification. Do not include customer personal data in screenshots or logs. If the test requires an order-like event, use the integration’s controlled test method where available. Avoid creating real customer orders solely to generate a test notification.

Watch the ownership boundary: Shopify’s native notification settings do not establish that a third-party push service is installed, subscribed, or sending correctly. Confirm who owns the subscription and server configuration before asking Shopify support to investigate a browser delivery issue.

Find the source of the push before opening Safari. Check the app or service documentation for the supported setup, the location of its subscription controls, and the test method it recommends. If the store uses custom code, identify who maintains the service worker, subscription handling, and server-side send process. Do not assume that a Shopify order notification automatically becomes a website push.

Record the test conditions in plain language. Include the Mac user account, macOS version, Safari version, test site, network conditions relevant to the test, and whether Safari is open. These details make a failed test repeatable. They do not establish universal compatibility: one Mac and one account cannot represent every visitor’s device or settings.

Keep the page and event controlled. Use a staging page, a dedicated test subscription, or the integration provider’s documented test trigger. Avoid sending unsolicited notifications to real shoppers. Make sure the test copy identifies the sender and explains what will happen when the visitor opts in.

For a team without a suitable Mac, first decide whether the task is only a configuration review or whether it requires observing Safari and macOS behavior. Configuration review may be possible through the provider’s dashboard. A buyer-side acceptance test needs access to a Mac running the intended Safari setup. If the test must use a particular regional environment, document that requirement separately instead of treating location as proof of notification delivery.

Open the test page in Safari and verify that the site clearly explains the purpose of its notifications before asking for permission. The prompt should follow a deliberate user action, such as selecting a clearly labeled subscribe control, rather than appearing without context. Record what the page displayed and what the tester did.

Apple’s Web Push documentation for Safari and browsers describes Web Push as a web technology with a browser and server-side path. That distinction matters during acceptance: the browser’s permission state is one checkpoint, not a delivery receipt.

Test the meaningful permission states without assuming they are interchangeable:

• Permission allowed: Record the site and the visible permission state. This shows that the site has permission to request notifications; it does not show that a subscription is valid or that a message was sent.
• Permission denied: Record the result and check whether the page explains how the visitor can review the setting. Do not repeatedly trigger prompts or imply that the visitor must grant permission.
• Previously denied or changed: Review the current Safari site setting rather than relying on an earlier screenshot. A setting changed since the previous test can explain a different result.
• No prompt appears: Confirm whether the integration requires a specific user action and whether the site already has a saved permission state. Then consult the integration’s instructions before changing code.

Apple provides separate guidance for changing Safari website notification settings. Use it to inspect the browser-side permission, but keep the server and Mac notification checks for later stages.

Once the test subscription exists, use the integration’s documented test event or another controlled trigger. Capture the event name, approximate test time, target test subscription, and result reported by the sending service. Do not infer a successful send from a page message that only confirms a button was clicked.

Check the provider’s logs or dashboard for each relevant transition:

• Did the service recognize the test subscription?
• Was the expected event received?
• Did the service attempt to send a push?
• Did it report that the request was accepted, rejected, or failed?
• Is there an error message that identifies a configuration or subscription issue?

The exact fields and wording vary by integration, so use that provider’s documentation rather than assuming every dashboard uses the same status labels. Save a redacted screenshot or export where possible. Remove tokens, endpoint details, customer identifiers, and other secrets before sharing evidence with your team.

Keep sender-side evidence separate from browser-side evidence. A server log can show that the sending service processed an event; it cannot show that macOS displayed an alert to the intended user. Likewise, a visible permission state cannot replace a server send record.

If no service-side record exists, mark the send as not verified. Do not label the absence of a notification a Safari failure until you have evidence that the service attempted the send. If the service reports an error, preserve the error text and pass it to the integration owner before changing multiple settings at once.

Check the receiving Mac after the controlled send. Note whether a notification appeared, what sender name and content it showed, and whether the result matched the intended buyer experience. Keep the browser permission state and the visible alert in separate fields in your test record.

Then inspect both layers of local settings. Apple explains how to change notification settings on Mac; use that guidance alongside Safari’s website permission controls. Check whether the relevant app or browser is allowed to show notifications and whether the chosen alert presentation makes the test visible. A notification may be permitted but not presented in the way your tester expects.

If Safari is open, repeat the test with the browser closed only when that state matters to your acceptance criteria and the integration supports testing it. Record the condition for each attempt. Do not turn a single result into a claim that every Mac, Safari profile, or user will receive the notification. Individual site permission, system settings, integration state, and the user’s device all affect what you can observe.

A practical record can use these fields:

• Integration: app or custom service and its owner.
• Test target: test page, test subscription, and Mac user account.
• Permission: allowed, denied, or not established.
• Trigger and send: event used and sender-side result.
• Mac display: shown, not shown, or not checked.
• Evidence: redacted screenshots, relevant log excerpts, and test time.
• Scope: exact Safari and macOS conditions used.

This record prevents a common handover problem: one person says “the test passed” because the prompt appeared, while another assumes that the notification was sent and displayed. Each claim should point to its own evidence.

Use the evidence to assign a result instead of relying on a single green status or screenshot.

• Pass for the tested setup: The integration is identified, a valid test subscription is recorded, the service has a send record, and the Mac display was checked under the stated conditions.
• Partial pass: Permission exists but there is no send evidence, or the service reports a successful send but the receiving Mac was not checked. Continue testing; do not claim end-to-end acceptance.
• Repair required: The subscription is missing, the service reports a relevant error, or Safari or macOS settings block the expected presentation. Send the specific evidence to the person responsible for that layer.
• Hold launch: You cannot reproduce the test, cannot identify the service owner, or lack enough evidence to explain a missing notification. Fix the evidence gap before relying on the feature in customer communications.

After launch, keep monitoring the integration’s own operational records and investigate unexplained failures. Do not promise that permission means a notification is guaranteed to arrive. The result only describes the tested configuration and conditions.

How can you test website push notifications for a Shopify store?

Identify the third-party sender first. Use its documented test event or a controlled test page, then record the subscription state, server-side send result, and Mac display as separate observations. A Shopify order email, a successful button click, or a permission prompt is not a substitute for those checks. Keep the test isolated from real customer orders where possible.

Why can Safari allow notifications without showing a push?

The permission setting only covers the browser’s authorization for that site. The integration may still lack a valid subscription, may not have processed the event, or may not have sent the push successfully. If the server reports a send attempt, inspect Safari’s site permission and macOS notification settings next. Without a sender-side record, classify the cause as unverified rather than blaming Safari.

How do you check whether website notifications are disabled on a Mac?

Check the site’s permission in Safari, then inspect macOS notification settings for Safari or the relevant web app. Look at whether notifications are allowed and how alerts are presented. Apple documents these as separate controls, so changing only one may not resolve the problem. Record the settings before and after a change so the next test has a clear comparison.

What is the difference between Shopify order notifications and website push?

Shopify order notifications are store-managed customer or staff messages. Website push is a browser notification sent through a web-push integration and its sending service. They have different triggers, recipients, configuration owners, and evidence. Test the channel you plan to use: an order email can pass while Safari push fails, and a push test does not confirm that order emails are working.

For this acceptance task, a local Mac is the simplest choice if your team already has one and can reproduce the buyer’s Safari setup. Relying only on a provider dashboard leaves out the receiving screen; using screenshots from another person’s Mac may conceal different permissions or notification settings; and placing real customer orders just to test creates avoidable operational work. If your team has no suitable Mac but needs to check the actual Safari and macOS display, compare that temporary need with the cost of buying hardware before deciding. You can review KVMNODE’s US East Mac option or its Mac access options and choose a remote Mac only if it fits your test conditions. A remote session can provide a Mac for controlled verification, but it does not replace integration logs or prove behavior on every customer device.