Members were paying and locked out. The payment messages were being thrown away.

The problem

Members were being charged every month and finding the members area closed. Support tickets were piling up. The site owner was already working with the plugin's support team and wanted fresh eyes on it.

What made it hard was that nothing looked broken. There was no crash, no error in the server logs, and the firewall was not blocking anything. We checked each of those before ruling them out.

Where the payments were going

When CCBill takes a payment, it sends the website a notification, a webhook, so the site can grant access. The membership plugin's CCBill add-on expected that notification as ordinary form data. CCBill was sending it as XML, a different format.

The add-on could not see anything inside an XML message, so it concluded the account number was missing, wrote an error to its own log, and stopped. Nothing about the payment was ever applied. Orders sat at a placeholder status, no subscription was created, and the member read as having nothing.

That explained the whole picture: CCBill working perfectly, the site receiving every message, and silently discarding each one. The add-on's log turned out to be a file on the server rather than anything visible in WordPress, which is why nobody had seen it. Server logs dated the start almost to the hour.

The repair

We corrected the integration so CCBill's notifications are read and applied. From that point, every new payment and every monthly rebill grants access on its own.

That still left everyone who had paid during the broken period without access. Before touching a single member, we took a fresh database backup and kept a full record of every change, so the whole restoration could be reversed if needed.

• 141 members who were actively paying but had lost access were restored, each to the tier matching what they pay.
• When one more member wrote in, we checked the entire active member list rather than fixing one account. That found 41 more people who had signed up during the broken window, so their purchase had never been recorded at all. All 41 were restored at no extra cost, since it was part of the same fault.
• Two customers had paid but never had a website account created. Creating one would email them a new password, so we handed those two to the owner to decide.

What else we found

The owner forwarded some old notification emails that turned out to reveal two more problems:

• Cancellations were not reaching the payment provider. The channel the site uses to talk back to CCBill was not enabled on the account, so a member cancelling on the website could keep being billed. We flagged it and the owner raised it with CCBill straight away.
• A staging copy was processing live payment events. A test site was receiving and acting on real customers' payment notifications. We removed it.

Results

• The payment integration repaired, so access is granted automatically again.
• 182 paying members restored to the correct tier, with every change backed up and reversible.
• A billing risk on cancellations identified and escalated to the payment provider.
• A staging site removed that was acting on live customer payments.

Client name, site and niche withheld at our discretion. Figures are taken from the project record. The review quoted is public on Nirmal's Codeable profile.