How to Use Staging Sites and Restores in AccessAlly

This article covers restoring a backup of an AccessAlly site and how to prevent tech hiccups during the process by using a staging site.

Part 1: When should you restore a backup on a live AccessAlly site?

Restoring on a live site AccessAlly site should only be used as a last resort for critical failures.

Restoring is a very dangerous operation, as it erases a portion of the site history. When it absolutely must be performed, the restore timepoint should be as recent as possible. Restoring the live site should be done sparingly as there are better ways to do testing outlined in this article below.

If an AccessAlly site backup is restored any prior payments that were processed during the in-between period are erased and can result in duplicate charges!

Duplicate charges from a backup restore are tricky to find and eliminate because of the site history being erased during the restore!

Part 2: When should you use a staging site?

Staging sites are helpful when doing in-depth development/testing, or migrating from one WordPress course or membership plugin to another, it is preferred to clone the live site to a staging/development site. Changes should be made to the staging/development site and thoroughly tested. Once satisfied, the staging/development site can be deployed to the live site.

The purchase data on the live site will need to be migrated and you can find the tutorial here.

Part 3: How to manage small changes or tweaks to your live AccessAlly site.

If you’re making minor changes that can be performed in a day or less, these can be performed on your live site directly after testing on your staging site. This method is a bit riskier than option 2 above, but you might decide to do this versus a full staging site deployment.

Click here to learn how to set up a Staging Site on WordPress.

What to Do If You Restored During a Billing Cycle

Restoring a backup while subscriptions are processing payments can cause subscription sync failures, “Payment Due” stuck states, and access issues for customers. This section explains how to recover from this situation.

Why Backup Restores Cause Subscription Issues

When you restore a backup, you’re replacing your database with an older version. Here’s what goes wrong:

1. Payment processor processes a payment (Stripe, PayPal, etc.) on the current date
2. AccessAlly receives webhook about the successful payment
3. AccessAlly updates database with payment record
4. You restore a backup from before that payment was recorded
5. Result: Your payment processor knows the payment succeeded, but AccessAlly’s database doesn’t have that record

Symptoms of this issue:

• Users stuck in “Payment Due” status even though they paid
• Subscription shown as “Failed” when payment actually succeeded
• Access incorrectly removed from paying customers
• Users unable to register their successful payment in AccessAlly
• Duplicate charge attempts because AccessAlly thinks payment failed

Prevention Checklist: Before You Restore a Backup

To avoid subscription sync issues, follow this checklist before restoring any backup:

1. ✅ Check your billing calendar
   • Review when subscriptions renew (e.g., 1st of month, 15th, etc.)
   • Check when payment plans charge (weekly, monthly installments)
   • Avoid restoring during these billing windows
2. ✅ Pause recurring payments temporarily (if possible)
   • For small membership sites, pause Stripe subscriptions before restore
   • Restore backup
   • Verify everything works
   • Resume subscriptions
3. ✅ Choose the right backup point
   • Don’t restore to a date that’s mid-billing-cycle
   • If you must restore, choose a backup from right after a billing date
   • This minimizes the number of payments that need manual reconciliation
4. ✅ Notify active subscribers
   • Send email warning about potential access disruptions
   • Provide support contact for payment issues
5. ✅ Export recent payment data before restore
   • Download Stripe payment reports for the period you’re losing
   • Export user list from AccessAlly
   • This helps with manual reconciliation later

Recovery Process: Fixing Subscription Sync Issues

If you’ve already restored a backup and have subscription sync issues, follow these steps:

Step 1: Identify Affected Subscriptions

1. Check your payment processor
   • Go to Stripe/PayPal dashboard
   • Filter payments by date range: [backup date] to [today]
   • Export list of successful payments during this period
2. Check AccessAlly order records
   • In WordPress admin, go to AccessAlly → Orders
   • Look for orders marked “Payment Due” or “Failed”
   • Compare with Stripe/PayPal – find mismatches
3. Create list of affected users
   • Note user email, subscription ID, expected payment date
   • This is your reconciliation list

Step 2: Manually Sync Subscription Records

For each affected subscription, you need to manually update AccessAlly:

1. Locate the user in AccessAlly
   • Go to AccessAlly → Users
   • Search for the customer by email
2. Find their subscription
   • Click “Edit” on the user
   • Scroll to “AccessAlly Order History” or “Subscriptions” section
   • Find the affected subscription
3. Update subscription status manually
   • If stuck in “Payment Due”, change status to “Active”
   • Update “Next Payment Date” to reflect actual billing schedule
   • Add a note explaining the manual adjustment
4. Verify tags are applied
   • Check that the user has the correct access tags
   • Manually apply tags if missing (usually done automatically with status change)
5. Test user access
   • Log in as the user (or have them test)
   • Verify they can access protected content
   • Check that course progress is intact

Step 3: Re-sync Payment Webhooks (Advanced)

If you have many affected subscriptions, you can trigger webhook re-sync:

1. In Stripe:
   • Go to Developers → Webhooks
   • Find recent events that need reprocessing
   • Click “Resend” on payment_intent.succeeded events
   • AccessAlly will receive the webhooks again and update records
2. Monitor webhook delivery
   • Check Stripe webhook logs
   • Ensure webhooks return 200 OK status
   • Failed webhooks may need manual intervention

⚠️ Note: Webhook resending only works for recent events (typically last 30 days). Older events must be manually reconciled.

Step 4: Handle “Payment Due” Stuck States

Users stuck in “Payment Due” status need special attention:

1. Verify payment actually succeeded
   • Check Stripe/PayPal for successful charge
   • Get transaction ID and payment date
2. Manually adjust subscription in AccessAlly
   • Go to user’s subscription settings
   • Click “Adjust Subscription”
   • Select “Mark Payment as Received”
   • Enter transaction ID from Stripe/PayPal
   • Update status to “Active”
3. Reset next billing date
   • Calculate correct next billing date (original date + billing cycle)
   • Update “Next Payment Date” field
   • Save changes
4. Notify the customer
   • Send email confirming their access is restored
   • Apologize for the disruption
   • Assure them they won’t be double-charged

Preventing Future Issues

To avoid subscription sync problems in the future:

1. Schedule backups strategically
   • Take backups right after major billing dates
   • Avoid restoring during active billing windows
2. Use staging sites for testing
   • Test changes on staging first
   • Only restore production as last resort
   • See staging site best practices above
3. Export data before major changes
   • Download user lists, order reports before risky operations
   • Keep payment processor reports handy
   • This makes reconciliation easier if needed
4. Communicate with customers
   • If you must restore during billing cycle, warn customers
   • Set expectations about possible disruptions
   • Provide clear support contact
5. Consider Professional Help
   • Complex subscription reconciliation can be time-consuming
   • Consider hiring a developer if you have many affected users
   • AccessAlly doesn’t provide support for backup-related issues

How Long Does Manual Reconciliation Take?

Estimated time per affected subscription:

• Simple case (1-2 payments missed): 5-10 minutes per user
• Complex case (payment plans, multiple products): 15-30 minutes per user
• Bulk reconciliation (20+ users): Consider automated tools or developer help

Total project time depends on:

• Number of active subscriptions
• Length of time between backup date and restore date
• Billing frequency (weekly vs monthly)
• Complexity of your product offerings

When to Get Professional Help

Consider hiring a developer or WordPress consultant if:

• You have more than 20 affected subscriptions
• Payment data spans multiple months
• You’re not confident manually adjusting database records
• Users are reporting billing issues and you need fast resolution
• You need to reconcile payment plans with multiple installments

Case Study: Backup Restore During Billing Cycle

Scenario: Site restored from 3-day-old backup during monthly billing cycle

Impact:

• 15 subscriptions processed during those 3 days
• After restore, all 15 showed “Payment Due” status in AccessAlly
• Customers were correctly charged in Stripe
• Access was incorrectly removed for those 15 customers

Resolution:

1. Exported Stripe payment report for 3-day window
2. Matched payments to user emails
3. Manually updated each of 15 subscriptions to “Active” status
4. Updated next billing dates
5. Sent apology emails to affected customers
6. Total time: ~2.5 hours for 15 users

Lesson: A 10-minute delay in restoring the backup (to check billing calendar first) would have prevented 2.5 hours of recovery work and customer frustration.

💡 Pro Tip: Set a calendar reminder for your subscription billing dates. Before any restore operation, check if you’re in a billing window. Waiting 24-48 hours to avoid a billing window is almost always worth it.