Security

How Loyal protects merchant and subscriber data, and what we ask merchants to do on their side.

Last updated 14 August 2026 Applies to loyalapp.com and the Loyal Shopify app

On this page

1. Our approach
2. What data we hold, and what we deliberately do not
3. Infrastructure and hosting
4. Encryption
5. Access control
6. Application security
7. Shopify protected customer data
8. Logging, monitoring and alerting
9. Backups and recovery
10. Data deletion
11. Incident response
12. Vendor security
13. Business continuity
14. Reporting a vulnerability
15. What we ask merchants to do
16. Security questionnaires and documentation
17. Contact

How to read this. This page describes the controls we actually run. It is written for the person at a merchant, agency or enterprise who has to fill in a security questionnaire before approving an app. Every commitment here is repeated in section 12 of the Privacy Policy and Annex 2 of the Data Processing Addendum, and we keep the three in step. If you need something that is not on this page, ask us at support@slashcart.com.

1. Our approach

Loyal sits between a merchant's Shopify store and its subscribers, and it instructs recurring charges. That makes correctness and confidentiality the two things that matter most. Our security programme is built around three principles.

• Hold less. We request the minimum Shopify access scopes, read only the fields a feature needs, and never receive card numbers. Data we do not have cannot be lost.
• Encrypt and restrict. Everything is encrypted in transit and at rest. Access to production is limited to named individuals with multi factor authentication and is removed the day it is no longer needed.
• Say what we do, and only that. We do not publish a control we do not run. Where a merchant asks for evidence, we provide it under confidentiality.

2. What data we hold, and what we deliberately do not

We hold. Merchant account and billing records; product, customer, order and subscription data read from the merchant's Shopify store; portal activity by subscribers; support conversations; usage and error logs. Section 4 of the Privacy Policy lists these in full.

We do not hold.

• Full payment card numbers or security codes. Charges are executed by Shopify against a payment mandate that Shopify holds, or by the merchant's own gateway. We instruct the charge and record the outcome: result code, amount, currency and date.
• Merchant card details. Merchants pay through Shopify Billing and we receive only a confirmation.
• Special category data, government identification numbers or financial account credentials. Merchants must not send these, and if they reach us we delete them and tell the merchant.
• Gateway or network tokens after a migration is complete. They are transmitted to recreate the mandate and not retained once it exists.

Decision needed before publishing. If the subscriber portal shows a card brand and last four digits, this section and section 5 of the Privacy Policy must say whether those two fields are stored by Loyal or read live from Shopify on each portal load. This is the question a merchant's security reviewer will ask first. Answer it the same way on both pages.

3. Infrastructure and hosting

Loyal is hosted with a major cloud provider in data centres that hold independent certifications for physical security, environmental controls and operational practice. We do not operate our own physical servers and no merchant or subscriber data is stored on staff devices.

Production is separated from development and test environments at the network and account level. Real subscriber data is never copied into a non production environment. Test data is synthetic.

Infrastructure is defined in code and changes are reviewed before they are applied. Network access to production is denied by default and opened only for the specific services that need it.

Decision needed before publishing. Name the hosting provider and the region here, and make it match the Subprocessors page. Merchants in the UK and EU will ask where their data physically sits. State the region rather than "a major cloud provider" if you can.

4. Encryption

• In transit. All connections to and from Loyal use TLS 1.2 or above. That includes traffic between a merchant's browser and the app, between the app and Shopify, between the app and our subprocessors, and between a subscriber's browser and the customer portal. Older protocols and weak cipher suites are disabled.
• At rest. Databases, object storage, file attachments and backups are encrypted at rest using AES 256 or an equivalent algorithm, with keys managed by our hosting provider's key management service.
• Secrets. API credentials, Shopify access tokens and signing keys are stored in a secrets manager, never in source code or configuration files, and are rotated when a person with access leaves or when we have any reason to think one may have been exposed.
• Webhooks. Every webhook we receive from Shopify is verified against Shopify's HMAC signature before it is processed. Unsigned or mismatched requests are rejected and logged.

5. Access control

• Access to production systems and to data is limited to the people who need it for their role.
• Every person has an individual account. Shared accounts are not used.
• Multi factor authentication is required for our hosting provider, our source code repository, our secrets manager and every subprocessor console that can reach merchant or subscriber data.
• Access is granted on the principle of least privilege, reviewed periodically, and removed on the day a person stops working with us or changes role.
• Access to subscriber data by our staff is limited to support and fault investigation, is logged, and is not used for any other purpose.
• Merchant access to the app runs entirely through the merchant's Shopify admin. We do not maintain a separate login, so the merchant's Shopify access controls apply.

6. Application security

• Code changes go through peer review before they are merged, and automated tests run on every change.
• Dependencies are scanned for known vulnerabilities and kept patched. Critical vulnerabilities in a dependency are addressed as a priority over feature work.
• We follow the OWASP guidance for common web application risks, including input validation, output encoding, parameterised database queries, CSRF protection and secure session handling.
• Shopify session tokens issued through App Bridge are validated on every request, and each request is checked against the store it belongs to so that one merchant can never read another merchant's data.
• The customer portal authenticates each subscriber before showing or changing anything, and records who made each change and when.
• Rate limiting is applied to public endpoints, including the portal, to reduce the risk of abuse and credential stuffing.
• Security relevant events, including failed authentication and rejected webhooks, are logged and reviewed.

Decision needed before publishing. If Loyal has had an external penetration test, state when, by whom, and that the summary is available under NDA. If it has not, do not mention penetration testing here. Reviewers ask for the report, and a claim without a report is worse than no claim.

7. Shopify protected customer data

Shopify classifies customer name, email address, phone number and address as protected customer data and requires apps that access it to meet specific standards. We meet them as follows.

• We request only the access scopes needed to operate subscriptions, and we can explain the purpose of each.
• Every field we read has a documented purpose in section 7 of the Privacy Policy and is used for nothing else.
• Protected data is encrypted in transit and at rest, and access to it is restricted as described in section 5.
• We implement the three mandatory privacy webhooks: customer data request, customer redaction and shop redaction. We return a customer data export to the merchant within 10 days, complete a customer redaction within 30 days, and complete a shop redaction within 48 hours.
• We keep retention to the schedule in section 11 of the Privacy Policy and delete on uninstall.
• We do not use protected data for our own purposes, for marketing or for training models.

8. Logging, monitoring and alerting

We keep application, access and error logs for 12 months. Logs record who accessed what and when, including staff access to production and subscriber actions in the portal.

Production systems are monitored continuously for availability, error rates and performance. Alerts go to an on call engineer. Anomalous patterns, such as unusual volumes of failed authentication or unexpected data access, are investigated.

Logs are stored separately from the application database, are encrypted, and are readable only by the people described in section 5. We reduce personal data in logs where we can, and where an error report could contain a subscriber field we apply redaction before it leaves our systems.

9. Backups and recovery

Encrypted backups are taken automatically and retained on a rolling 35 day cycle, after which deleted records age out of the backup set. Backups are stored in a separate location from the primary database and are encrypted with keys that are managed independently.

Backups exist for disaster recovery only. They are not restored into live systems except in a recovery event, and they are not used to recover data that a merchant or Shopify has instructed us to delete. Recovery procedures are documented and tested so that we know they work before we need them.

Decision needed before publishing. If you have measured recovery time and recovery point objectives, state them here. If you have not, leave them out. Do not publish a target that has not been tested.

10. Data deletion

Deletion runs on the schedule in section 11 of the Privacy Policy, which is repeated here for convenience.

Deletion from live systems is automated and runs on a schedule, not on request. Data already in an encrypted backup remains encrypted, is not restored except in a disaster recovery event, and is destroyed when the backup expires. On written request within 30 days of uninstall, we confirm in writing that deletion from live systems is complete.

Decision needed before publishing. Confirm with engineering that the uninstall deletion job actually runs within 14 days end to end, including any queued or archived records. Competitors publish 3 and 7 days. Tighten the number if the system supports it, but never publish a number it does not meet.

11. Incident response

We maintain a documented incident response process covering detection, triage, containment, investigation, notification, recovery and post incident review. Every incident is recorded with its facts, effects and the remedial action taken.

If a personal data breach affects a merchant's subscriber data, we notify the merchant without undue delay and in any event within 48 hours of becoming aware, as set out in section 8 of the Data Processing Addendum. The notice describes what happened, what data and how many people were affected as far as we know, the likely consequences, what we have done, and a contact point, and we update it as the investigation continues. We do not notify regulators or subscribers on a merchant's behalf unless the merchant asks us to or the law requires it, because that decision belongs to the merchant as controller.

Unsuccessful attempts that do not compromise data, such as blocked logins or failed exploits, are logged and reviewed but are not treated as breaches.

12. Vendor security

Every subprocessor is reviewed for security and privacy practice before we engage it and is bound by a written contract that flows down our obligations. The current list, with the service each provides and the location of processing, is on the Subprocessors page. We give 30 days notice before adding or replacing a subprocessor that processes subscriber data.

13. Business continuity

Loyal instructs recurring charges on a schedule, so an outage has a cost to merchants beyond inconvenience. Billing jobs are idempotent, which means that if a job is interrupted and re run, a subscriber is not charged twice. Failed or missed billing attempts are queued and retried once service is restored, and the merchant can see every attempt and its outcome in the app.

Our infrastructure runs across more than one availability zone. If Shopify is unavailable, Loyal cannot instruct charges and waits until it returns. We monitor Shopify's status alongside our own.

14. Reporting a vulnerability

If you believe you have found a security vulnerability in Loyal, loyalapp.com or the customer portal, email support@slashcart.com with "Security vulnerability" in the subject line. Include enough detail for us to reproduce the issue. We acknowledge reports within 2 business days, keep you informed of progress, and credit reporters who wish to be credited once the issue is resolved.

We ask that you give us reasonable time to fix an issue before disclosing it publicly, that you do not access, modify or delete data that is not yours, that you do not run denial of service or social engineering attacks, and that you stop and report as soon as you can demonstrate an issue rather than exploring further. We will not take legal action against anyone who reports in good faith under these terms.

Decision needed before publishing. If a bug bounty is offered, state the scope and reward ranges. If not, do not imply one. Also decide whether to publish a security.txt file at loyalapp.com/.well-known/security.txt pointing to this section, which is the standard place researchers look.

15. What we ask merchants to do

The security of a merchant's subscriber data depends on the merchant's Shopify account as much as on us, because Loyal is accessed through it. We ask merchants to:

• turn on two step authentication for every Shopify staff account;
• give each person their own login rather than sharing one, and use Shopify's staff permissions to limit who can manage apps;
• remove staff and agencies from Shopify as soon as they stop working with the store, and review access periodically;
• review the third party integrations connected to Loyal and disconnect any that are no longer used;
• not send us card numbers, credentials or special category data through support;
• tell us immediately at support@slashcart.com if they think an account has been compromised.

Section 24 of the Privacy Policy sets out the same points, and section 9 of the Terms of Service makes account security a merchant responsibility.

16. Security questionnaires and documentation

We are happy to complete a merchant's security questionnaire or vendor assessment. To speed it up, the following are available on request, under confidentiality where marked:

• This Security page, the Privacy Policy, the Data Processing Addendum, the Cookie Policy and the Subprocessors page
• A completed standard questionnaire covering the controls on this page (under NDA)
• A copy of the Standard Contractual Clauses as completed for a specific merchant
• A summary of our legitimate interests assessment
• Confirmation of deletion following uninstall

Decision needed before publishing. If Loyal holds or is pursuing SOC 2, ISO 27001 or any other certification, or has completed Shopify's protected customer data review at Level 2, state it here with the date. If none of these exist, leave this note out entirely. Reviewers will ask, and "in progress" with a target date is an acceptable answer, but an unsupported claim is not.

17. Contact

SlashCart Inc. 131 Continental Drive, Suite 305 Newark, DE 19713 United States

All security enquiries, vulnerability reports and questionnaire requests: support@slashcart.com

This page should be read together with our Privacy Policy, Terms of Service, Data Processing Addendum, Cookie Policy and Subprocessors page, which together form the agreement governing use of Loyal.