CBSubs subscription not automatically activated after successful payment

I am experiencing an issue with CBSubs where a paid subscription is not being automatically activated after a successful payment.Environment:

• Joomla (latest 5.4.3)
• CBSubs (latest version)
• PHP 8.2 (HostEurope, only 8.2/8.3 available)
• Community Builder (latest)
• AcyMailing installed (including regacymailing system plugin)

Problem description:A user completes a payment (Stripe / PayPal), and from the user’s perspective the payment appears successful. However:

• The subscription is not properly activated in Community Builder.
• The user does not consistently receive the expected access/permissions tied to the subscription.

When manually saving the user in the backend, the subscription (plan ID 6) gets assigned correctly and the ACL group is updated, which suggests that CBSubs activation logic itself is working in principle. Debug / Error behavior:With debug enabled, the following issues appear extensively:

1. PHP 8.2 deprecation warnings (dynamic properties), e.g.:
   • Creation of dynamic property ... is deprecated
   • affecting multiple AcyMailing classes and plugins:
     • plgSystemRegacymailing
     • subscriberClass, acyuserHelper, filterClass, etc.
     • various AcyMailing plugins (tagsubscription, tagcontent, calltoaction, stats, etc.)
2. Additional warning:
   • explode(): Passing null to parameter #2 ($string) of type string is deprecated
   • in plugins/system/regacymailing/regacymailing.php
3. These messages appear during the CBSubs order and subscription processing flow, including:
   • cbpaidControllerOrder::createSubscriptionsAndPayment
   • cbpaidUsersubscriptionRecord::activate
   • user save events (onBeforeStoreUser, onAfterStoreUser, etc.)

Observations:

• CBSubs does attempt to activate the subscription (seen in stack traces).
• The user and ACL group are correctly updated when saving manually in the backend.
• The issue seems to occur during or immediately after the payment completion workflow.
• The AcyMailing regacymailing plugin is heavily involved in the user save process and produces multiple PHP 8.2 warnings.

Questions:

1. Could the subscription activation failure be related to interruptions in the payment callback / IPN / webhook handling?
2. Is CBSubs sensitive to PHP 8.2 deprecation warnings in third-party plugins during the activation process?
3. Are there known compatibility issues between CBSubs and AcyMailing (especially regacymailing) under PHP 8.2?
4. Is there a recommended way to isolate or bypass third-party plugin interference during subscription activation?

Temporary workaround:

• Manually saving the user in the backend correctly assigns the subscription and ACL group.
• Disabling debug output hides the messages but does not address the root cause.

Any guidance on how to reliably ensure automatic subscription activation after payment would be greatly appreciated.Best regardsJens.
(Written with ChatGPT - sorry...)

Are there any errors in the CBSubs > History Log for their basket?

When this happens it's usually 1 of 2 things. Webhooks aren't configured properly and aren't being received by CBSubs or something is interrupting the payment processing behavior (frequently this is a 3rd party plugin and yes AcyMailing has caused something like this in the past).

Webhooks typically aren't a problem unless the payment goes into a pending state though since Stripe will report back credit card success generally immediately. Are payments going into a pending state? You'd be notified of this on the payment complete page.

Manually saving the user in the backend correctly assigns the subscription and ACL group.

What do you mean by this? You just edit and save them without changing anything in CB > User Management?

Disabling debug output hides the messages but does not address the root cause.

If AcyMailing is causing your issue then I suggest completely turning off AcyMailing and seeing if your issue resolves.

Hi Krileon,

I'm hitting a reproducible fatal error in the CBSubs PayPal PDT handler and would really appreciate your take on it, because I suspect it's a genuine core issue — and it may also explain a longer-standing silent-failure pattern on my site.

## Environment

- Joomla 5.4.5
- Community Builder 2.11.0
- CBSubs 4.9.0
- PHP 8.2 on HostEurope shared hosting
- `memory_limit = 1024M`

## What happens

A new subscriber completes a PayPal payment. PayPal charges correctly (`payment_status = Completed`), the buyer is redirected back to the site, and the PDT handler runs — but the request ends with HTTP 500 and:

```
Allowed memory size of 1073741824 bytes exhausted (tried to allocate 52432896 bytes)
```

The subscription is never activated. The basket stays unpaid in the backend. This happens even with a 1 GB memory limit, so it isn't a sizing issue.

## Root cause (as far as I can trace it)

Looking at the notification history entry, the actual first error is a PHP warning, not the OOM:

```
WARNING: var_export does not handle circular references
in .../plug_cbpaidsubscriptions/processors/paypal/cbpaidsubscriptions.paypal.php on line 1619
```

That line is inside the fraud-check *else* branch of `handlePaypalPDT()`, where CBSubs logs the incoming notification when `noFraudCheckResult` is set:

```php
$this->_setLogErrorMSG(
    3,
    $ipn,
    'Received back from paypal: ' . var_export( $ipn, true ),
    CBTxt::T("Payment notification mismatch: ") . $noFraudCheckResult . '.'
);
```

`$ipn` here is a `cbpaidPaymentNotification` object that contains circular references. `var_export()` doesn't handle circular references — it only warns and then tries to expand them anyway, which blows the memory. The result: the log call that was supposed to tell us *why* the payment was flagged as a mismatch is exactly what kills the request.

So there are effectively two layered problems:

1. Something in the PayPal return data triggers `noFraudCheckResult`. I don't know yet what it is, because...
2. ...the moment CBSubs tries to log the mismatch reason via `var_export($ipn, true)`, it runs out of memory and never writes the reason to history. The diagnostic path is blocked by the OOM.

## Call stack (abridged)

```
cbpaidHistory::logError()            — cbpaidErrorHandler.php:293
cbpaidErrorHandler::_error_handler_callable()
var_export(object(cbpaidPaymentNotification), true)
                                     — cbpaidsubscriptions.paypal.php:1619
cbpaidpaypal::handlePaypalPDT()      — cbpaidsubscriptions.paypal.php:339
cbpaidpaypal::handleReturn()         — cbpaidHostedPagePayHandler.php:136
cbpaidHostedPagePayHandler::resultNotification()
                                     — cbpaidControllerCBTab.php:748
```

## Reproduction

1. Complete a normal PayPal payment for any CBSubs plan on a site where the fraud check will flag the return for any reason (in my case I don't yet know the reason — see below).
2. The PDT handler reaches the else branch and calls `var_export($ipn, true)`.
3. PHP emits the "circular references" warning and then runs out of memory.
4. The request dies, the subscription is not activated, and no history entry explaining the mismatch is written.

Relevant PayPal return parameters (anonymised):

```
cm          = 766          (basket ID)
invoice     = U1288
mc_gross    = 1.20
mc_currency = EUR
payment_status = Completed
item_name   = "PLUS Tageszugang von manni"
receiver_id = AWLTP5KKX44MY
```

## Suggested fix

Replacing `var_export($ipn, true)` with `print_r($ipn, true)` at line 1619 (and possibly in similar places in the same handler) would be the minimal change: `print_r` detects recursion, prints `*RECURSION*`, and returns cleanly without exhausting memory. The logged string becomes slightly less structured, but the fraud-reason log actually makes it into the database — which is the whole point of that code path.

If a more robust solution is preferred, `json_encode((array)$ipn, JSON_PARTIAL_OUTPUT_ON_ERROR | JSON_UNESCAPED_UNICODE)` or a custom serializer that skips known cyclic references would also work. I'd just strongly argue against leaving `var_export` in a branch that runs for every mismatched notification.

## A possibly broader implication

Since 2023 I've observed a pattern of "loyal old PayPal subscribers silently falling out of the system" on renewals. We'd been blaming the 2023 site migration and assumed some Stripe/PayPal gateway binding was broken. But if this var_export/OOM crash fires on *every* PayPal notification that hits the mismatch branch — even for minor reasons — then each such case would:

- charge the customer successfully (PayPal confirms payment),
- crash CBSubs' PDT handler while logging the mismatch,
- never write a history record explaining the mismatch,
- and leave the subscription silently inactive.

If that's what's been happening, it would fit the observed symptoms exactly. That's speculative on my side, but if you think the pattern is plausible I'd be grateful for confirmation — it would change how I handle the back-catalogue of affected accounts.

## What would help me most

1. Is the `print_r` replacement (or equivalent) something you'd consider for an upcoming CBSubs release?
2. Meanwhile: would you recommend I patch line 1619 locally so I can at least see the mismatch reason, or is there a safer workaround (e.g. a CBSubs setting that suppresses this particular log expansion)?
3. Any idea what typically causes `noFraudCheckResult` to be set in a straightforward EUR / `payment_status = Completed` PDT return? Once I can read the log, I can narrow this down myself, but I'd be interested in your experience.

Happy to provide more detail if useful — full GET parameter dump, full stack trace, or a test transaction ID. Thanks very much for your time.

Best regards,
Jens Wortmann
kulturbuero-goettingen.de

It's a circular reference error because $ipn seams to have a copy of itself inside of itself. That's irrelevant, because at this point the IPN has already failed and isn't what caused it to fail. It failed because you've an payment mismatch. That of course needs to be fixed, but I'd rather focus on what is causing the payment mismatch to begin with as that should never happen. Some of the common ways this happens are as follows.

1. You've configured CBSubs PayPal wrong where "PayPal Business (email or secure merchant ID)" and "PayPal Main receiver account (email) (if Business is different from your main account)" are not properly configured to match the payment. For this I recommend setting "PayPal Business" to Merchant ID and "PayPal Main receiver account" to whatever email address is marked as primary at PayPal.
2. You added a fee at PayPal instead of in CBSubs. This causes a price difference. CBSubs will flag that as a fraud attempt.
3. The currency changed at PayPal instead of in CBSubs. This again causes a fraud attempt check.
4. Return data is not properly configured at PayPal as this is happening inside the PDT check (return to site check). See CBSubs PayPal and follow the configuration instructions within it very carefully.

Below are step by step instructions for configurating PayPal please be sure you've configured everything exactly as instructed.

1. At PayPal navigate to Settings > Account and copy "Merchant ID" to "PayPal Business (email or secure merchant ID)"
2. At PayPal navigate to Settings > Account and copy the email address marked "Primary" under "Emails" section to "PayPal Main receiver account (email) (if Business is different from your main account)"
3. At PayPal navigate to Settings > Seller Tools > Website Preferences and configure the following
- 3A. Auto return for website payments = On
- 3B. Set your homepage for the return url
- 3C. Payment data transfer = On
- 3D. Copy "Identity Token" to "Your PayPal Identity Token"
- 3E. Encrypted website payments = Off

The final possible issue is PayPal has its encoding wrong. It should be UTF-8. It can be a bit frustrating to fix that. To fix that use the below link to go to the old PayPal language encoding page because I've no clue where they moved this.

www.paypal.com/cgi-bin/customerprofileweb?cmd=_profile-language-encoding

Next click "More Options" then set "Encoding:" and set "Do you want to use the same encoding for data sent from PayPal to you (e.g., IPN, downloadable logs, emails)?" to "No" followed by selecting utf-8 again. Then click Save. This will ensure you've UTF-8 safe data communication between the sites as it can be a problem if there's an encoding mismatch (a lot of old accounts got set to things like windows-1252).

That should cover the bare minimum. API credentials aren't necessary unless you want to allow for on-site subscription cancellations or on-site refunds.

In the meantime will look into fixing that circular reference bug for a new CBSubs release.

forge.joomlapolis.com/issues/9843

Ok, bug ticket created and fixed but is pending review. Once merged we'll have a new CBSubs build out with the circular loop addressed.

Hi Krileon,
thank you so much — your reply was incredibly helpful and solved the problem completely.
Following your step-by-step configuration guide, I made two changes in particular that turned out to be decisive:

Setting the main receiver email in CBSubs to the email marked as "Primary" in my PayPal account (it had been configured slightly differently before).
Going to the language-encoding page you linked and switching both encoding settings to UTF-8.

After that the next test payment went through cleanly: PDT handler completed, subscription activated, user added to the paid group, no more mismatch and no more OOM.
As a side benefit, the UTF-8 switch also appears to have resolved a longstanding issue I had with Latin-1 bytes in raw_data (the original error that led me down this rabbit hole). So your hint about old accounts still being on windows-1252 was spot-on — thank you for including it.
And thank you especially for turning around the circular-reference fix (#9843) so quickly. Looking forward to the release.
Really appreciate your time and the thoroughness of your response.

Best regards,
Jens Wortmann
kulturbuero-goettingen.de

Hi Krileon,
one small follow-up question if I may: now that PayPal payments are flowing cleanly again, I'd like to receive a copy of every customer invoice email in my own inbox so I can file them for bookkeeping.
In CBSubs 4.9.0 my Settings page only shows the tabs Global, Display, Credit Cards, Promotions, Tax, Mailer and Integration — no dedicated "Notifications" or "Invoicing" tab, and I couldn't find a BCC/admin-copy option in any of them, nor on the individual plan level.
What's the intended way in the current CBSubs version to have invoice emails BCC'd to the administrator (or otherwise forwarded)? Is there a setting I've simply overlooked, or is the expected approach different (e.g. a server-side mail copy rule)?
Thanks again!
Best regards,
Jens