Shopify App Delisted: What Should You Do Next?

Confirm which app and partner account the notice concerns. Record the ticket reference, the stated reason, the requested documents and the response deadline. A delisted listing, a restricted installation flow and a terminated partner account are not interchangeable situations. Use Shopify’s wording rather than guessing from the fact that your public app URL no longer works.

Create a short requirement tracker: request, owner, planned delivery, evidence location and status. If Shopify asks for final Incident Report and VAPT reports, keep both as separate deliverables. Do not send only a sales proposal or vulnerability scan and assume the request has been met. Ask for clarification where the scope or expected format is unclear.

If compromise is still possible, follow your incident-response procedures immediately. Restrict affected functions, revoke compromised credentials and isolate systems where justified. Preserve relevant application, access, cloud and deployment logs before their retention period expires. Record the exact time and reason for each action so containment does not become an unexplained gap in the timeline.

Avoid reproducing an issue against another merchant’s live data. Use authorized test stores and accounts whenever possible. Keep original logs read-only and share redacted working copies through a controlled channel. Do not upload tokens, passwords, unredacted customer records or production credentials into a public enquiry form. Obtain technical and legal advice for notification obligations.

Reply through the governance channel identified in the notice. State who owns the response, what is currently confirmed, what remains under investigation and when you expect to provide the next update. Shopify’s published security guidance lists security@shopify.com for security incidents; that does not replace answering the specific governance correspondence you received.

Distinguish the deadline to respond from the time required to finish testing. Acknowledge promptly even when a final report cannot yet be completed. Do not promise a completion date before the tester has reviewed the app scope, access, incident evidence and developer availability. If a milestone changes, explain why and provide a revised plan rather than allowing the thread to go silent.

Give the assessor the notice, app architecture, backend domains, API inventory, relevant permissions and original vulnerability report. Agree authorized environments and safe testing conditions in writing. For a multi-merchant app, consider tenant isolation, object-level authorization, OAuth, session handling, tokens and webhooks, not just the public marketing website.

The incident investigation and VAPT answer different questions. Investigation examines what happened using available evidence. VAPT assesses exploitable weaknesses within the agreed scope at the time of testing. Neither should claim to establish facts that the available logs or access cannot support. Ask for limitations and unknowns to be made explicit in the final documents.

Assign each finding an owner and remediation plan. Track the deployment version that contains the fix and retain a clear change history. A developer saying “fixed” is useful progress information, but it is not independent verification. Retesting should reproduce the original condition safely and establish the current status of the affected control.

Submit a coherent package with a cover note, the requested reports, finding statuses and retest evidence where available. Reference the app and governance ticket consistently. The anonymised Scantra case linked below ended with Shopify confirming relisting, but that past result does not establish a standard process, response time or guarantee for another app. Shopify controls the final decision.

Build a one-page note before your first update. Use these headings: app and ticket reference; time the notice was received; current listing and installation state; confirmed security facts; immediate containment; requested documents; response deadline; responsible people; next update date. For each claim, add an evidence reference or explicitly mark it unconfirmed. Keep the note internally versioned and use it to check that the acknowledgement matches engineering reality. For example, “endpoint disabled” is not the same claim as “root cause fixed,” and “testing commissioned” is not the same as “VAPT completed.” If the response needs confidential detail, move it into a controlled attachment rather than the email subject. Revisit the note as evidence changes and retain earlier versions so the incident history remains reconstructable.