This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Forums » Developer » BC Simplesubscription with Ez PayPal

BC Simplesubscription with Ez PayPal

BC Simplesubscription with Ez PayPal

Thursday 24 November 2011 7:28:34 am - 7 replies

Hi all,

I'm attempting to setup BCSimpleSubscription with EZ PayPal.

I've just recently rewritten sections of the EZ PayPal extension so that it will now work out of the box. It seems to work for me on several installations without having to do anything except edit the .ini happy.gif Emoticon

I'm now trying to deal with the "post_checkout" trigger that will actually run BCSimple's updating scripts to move the user.

My problem seems to be that the "post_checkout" tigger is never called at anypoint in the order process when using EZ PayPal. Even though there seems to be a continue workflow function called it never runs the "post_checkout" stuff.

I'm now trying to manually trigger this event inside EZ PayPal after it has approved the payment. But can't seem for the life of me to work out how to advance the workflow to the next step.

I've created a new method inside the eZPaypalChecker (extension/ezpaypal/classes/ezpaypalchecker.php) class based on the continueWorkflow() mething that can be found in the eZPaymentCallbackChecker class (kernel/shop/classes/ezpaymentcallbackchecker.php).

Once the payment has been verified Ez PayPal calls my modified continueWorkflow it is in here that I'm attempting to manually trigger the "post_checkout" event to inturn run BCSimple's subscription activation. This is where I fall down however.

I can pull the current workflow (pre_checkout) but cannot work out how to advance the workflow onto the next step. I'm at a complete loss as to how i do this. I've attempted using the following functions:

  • eZTrigger::fetch()
  • eZWorkflowProcess::fetch()
  • eZTrigger::runWorkflow() <- I can get the system stuck in a "pre_checkout" loop :-P
  • eZTrigger::runTrigger()

I'm pretty sure I've got to advance the workflow process to the next step. Then run the workflow but I cannot understand how I would accomplish this.

I've been reading through the class definitions in the Ez Publish documentation but am struggling to understand what is supposed to populate the different variables.

Has anyone had any success in manually manipulating these workflow events?

Finally, I'm running the Ez Community Project 2011.09 on php 5.2.19

Thanks in advance for any help you can offer!!

Thursday 24 November 2011 6:00:55 pm

Hi Daniel, 

I believe you will get a quicker answer by posting in the extension's project forum too :
Hint : after having published there, hit the "Track changes" button to stay tuned.


Thursday 24 November 2011 7:46:26 pm



I actually think this thread hold more relevance to the ezpaypal project (today) and that Daniel was very clever to post here on in wise attempt to reach other users of one or both of these extensions posting here today.


In any case we don't mind (as much) where you post about us as we track changes site wide on both sites and normally respond just as soon as we can.


Ok, now for the good stuff ...


First off calling the workflow in the ways you mention (above) is not the 'best' idea. Infact I'd switch gears becuase that is prolly not the way to run the functionality you want as it is designed in the system.

I took a quick look through all the related files. I think the solution here may be simpler than you had feared. I don't have test system for this use case ready to go so can you test this change for me?

File: 'ezpaypal/modules/paypal/notify_url.php' aka

if( $checker->checkAmount( $amount ) && $checker->checkCurrency( $currency ) )
     * BC: Default line is, $checker->approvePayment();
     *        While we would prefer the following instead
    $checker->approvePayment( true );

The above change of adding the 'true' parameter to parent object call approvePayment should trigger the continuation of the checkout workflow normally (as the code's design appears to provide here) with nothing more than one additional parameter indicating the workflow to continue (I assume on from pre_checkout to (finally?) post_checkout trigger (we hope at least) normally.


The above function parameter call depends on the following summery of code (calls back up the chain of classes)  ... (class eZPaypalChecker extends eZPaymentCallbackChecker)


Though it partially concerns me that the ezpaypal code would not already do this by default.

As post_checkout otherwise known as 'shop, checkout, after' trigger workflows are quite common and strange to omit support for.

This (without more hands on testing by myself) leaves me wondering just what other problems might arise from the above described change to enable the desired workflow support / functionality.


I hope this helps ... let us know how this works for you, or if it does not work or is not enough to reach your goal, let us know cause this may affect other eZ Publish shop + ezpaypal users (who might not have realize it or been able to address it).


And a personal note: Thank you for using and talking about using our solutions in the eZ Community. You made my Thanksgiving weekend asking about bcsimplesubscription and ezpaypal! We love to hear from users of the contributions we share any time, any way, any where. I personally was able to help out in building this solution so it is dear to my heart.


A final question, Daniel, would you mind sharing your modified ezpaypal extension? Even if you did not want to do the work of publishing it yourself online for all to benefit and maintaining the solution yourself.

Brookins Consulting would be happy to help you share this modified ezpaypal by doing the work to publish the code on github (easy to contribute later with) and posting links to the new code online in various help locations (like in the forums of the original project) so other users can test out the new contribution of code. If you don't mind, drop us an email with a zip of the extension, brookinsconsulting+ezpublish at gmail dot com


Thank you for your continued support! This is exactly what makes the eZ Community the best!




Modified on Thursday 24 November 2011 9:01:32 pm by // Heath

Thursday 24 November 2011 8:24:53 pm

I write today to share a bit of personal historical background, as only I can.

When developing and testing bcsimplesubscription, after the initial prototype was prepared, we did infact seek out to test it with both ezauthorize and ezpaypal payment gateways (most popular publicly at the time; for our customers (north american based)).


The test results with ezauthorize were all green (expected since we were intimately familiar with this gateway).

The test results with ezpaypal were all green except one (a devistating result to hear shared when we really hoped that it would work out of the box, a natural design goal for a solution).

One key requirement was not completed re: workflow support to trigger subscription activation). While we very much wanted to offer bcsimplesubscription to ezpaypal users right out of the box (first version) we knew we could not afford to invest in a patching the issue at the time.

This was what we suspected but did not do further research at the time, our failing for sure here, as the team suspected that the differences between ezpaypal and other gateways was the cause and not our prototype design.

The team was really conflicted about this situation and some in the team disagreed (in true allegiance with the community) but in the end our original requirements (only ezauthorize support) were the guiding light and final word on the situation.


With the suspicion that ezpaypal was responsible for the negative behavior found in our test results (#1), with the general rule (at the time) not to chase non-required functionality (#2) or our very firm rule (#3, at the time) to specifically and almost without available exceptions (I don't play) do not attempt to change or patch core behavior of code from eZ Systems (years later we grew up, who knew?)

At the time I felt I had to refuse to allow re-factoring of the design at this point, the problem was outside our control with the available code when used out of the box (and it did not seem to be a configuration issue). Plus I did not want to remove the use of workflows for subscription activation support (at all, but I try to be fair).


I helped the team understand why we could not fight this particular battle (at the time), I even mentioned outright that while we will not mention ezpaypal outright in our release, I hoped the community interested would speak up in the forums and then we moved forward, for the customer (at the time).


Time; It's curious when over the course of little more than time some things come back around. Though more privately than publicly I'm sure ...


We wish you all the very best. If you have any further suggestions, questions or concerns about bcsimplesubscription please do use the forums directly.



Modified on Thursday 24 November 2011 8:27:20 pm by Brookins Consulting

Thursday 24 November 2011 11:44:55 pm

After re-reading your original post I wonder the following ... Nicolas might be right about this being more specific to the differences between ezpaypal, ezauthorize and the expected use of bcsimple subscription. More on that in a moment ...


Do you review any of the possible debug output (assuming you have enabled it) in per page (in browser at end of page debug output, settings required) or in the ez logs (tail -f var/logs/*.log; I suggest tailing them all while testing) that gives any indication of issues with it's execution? Re: #L136 to #L164,

In general I'd expect at least something being written out or displayed that is related to the execution issues experienced.


Also that the gateway itself is called by the shop/checkout module view

which based on workflow event configuration would call,

which extends ezredirectgateway which ezpaypalgateway is based on (also wondering about debug output here),


Also try to think about bcsimplesubscription workflow event (not a payment gateway)(triggered -only- on shop,checkout,after) as separate from ezpaypal's ezredirectgateway based gateway ezpaypalgateway (which fires only on trigger 'shop,checkout,before'). Make certain your not trying to use / run both in the same workflow or assigned to the same trigger (not supported).


Also you might want to put a print_r and die or (test) log write statement in the bcsimplesubscription workflow event's primary method PHP code to ensure that you know when the code is being attempted to be run.

Also worth noting that the workflow event code here depends on an order created/owned by the user at this point in order to complete the activation.


Also worth noting is that when you checkout using ezpaypalgateway the user hits the shop/checkout view and is redirected (away from ez) to paypal, then when payment information has been accepted on and payment has been approved (remember paypal sends a completely separate request (not same session) back to ez to store this approval, then and only then is the user redirected back to ez's shop/checkout module view to resume process in eZ, I'm assuming that's the next trigger (shop,content,after) and next run the workflow event (bcsimplesubscription). In short it's not one request, it's two separate requests which together allow the user to continue shop checkout process.

And so if you ... try to manually run the activation workflow event it will prolly fail in that the dependencies (re: activation order requirements) are incomplete.


Also they are separate workflow events completely so they are not in the 'same process' in terms of workflow events, while within terms of the checkout module view process it is considered the part of the 'same process' ie: trigger / operation 'shop,checkout' (notify module view being separate part as well).


Also since the requests for user to even hit the 'trigger shop,checkout,after' (coming back from paypal) are separate from the code run during 'trigger shop,checkout,before' (trigger redirect to paypal) and the separate payment approval request from paypal (which is required to even run the 'trigger shop,checkout,after' workflow event or continue in the ez shop/checkout process you do not want to try to run our workflow event (or code based on bcsimplesubscription) within ezpaypal's 'ezpaypal/modules/paypal/notify_url.php' module view (note: my above suggested change may be irrelevant and a bad idea, uncertain).

The activation workflow event should (in theory) run -after- the users returns from paypal hits the shop/checkout view, continues operation 'shop,checkout' on to trigger 'after', run the activation workflow, redirect user to the shop order view page (all done).


Though after reading (again),

I wonder of the ezpaypalgateway even supports/allows the later use (by other workflow events) the 'shop,content,after' trigger or if that code in that context is never run at all (and why?). As they simply use a workflow event on the same trigger (before) right after the ezpaymentgateway event.

Can anyone else comment in general if they use ezpaypal with a separate workflow assigned on trigger 'shop,checkout,after'?


Apologies for not being as verbose or clear in my first reply. Always in a rush, you understand.

I hope this helps ...




Modified on Thursday 24 November 2011 11:58:50 pm by // Heath

Wednesday 07 December 2011 7:37:32 am

Hello Daniel,


I was re-reading this thread tonight and wondered if you had reached a solution in your search to use bcsimplesubscription and ezpaypal extensions together or if you were still in need of some assistance.

If you have any questions at all please feel free to ask them here and I will be happy to do my best to answer.

If you reached your goals, we would love to hear the key details surrounding your achievements and what it took to reach them.


Thank you for your continued support




Friday 06 January 2012 12:14:48 am

Hi Heath,

Sorry for the late reply. Christmas and about 1000 projects got ontop of me and I didn't realise you had posted.....

I've actually given  up trying to work out what the workflow problem is here. It's definately got to do with the session being restarted due to the redirect to Pay Pal.

At no point can I actually get any of the scripting for the post checkout stuff on simple subscription to run. It just never seems to trigger the workflow.

Because the site is low volume I've just got a sort of manual activation procedure that the customer has to follow and basically simple subscription handles expiries and what not.

I'm now in the process of having a look at Secure Pay and modifying the EZ Authorize extension to work with Secure Pay. I've read in a couple of places that people have done it so I'm thinking that's going to be my best solution for future sites like this.

If I can get EZ Authorize to interact with Secure Pay I'll have the subscription extension working, as I think you mentioned it was made to work with EZ Authorize.

I think that's going to be the easiest way to get things done, rather than rewrite the whole ez pay pal extension to not redirect which I'm not totally sure I can do with pay pal...

Once again I apologise for the delay in posting. sad.gif Emoticon

Friday 06 January 2012 4:17:39 am

Hello Daniel,


Thank you for taking the time today to share an update here.

No worries on your time away, this is natural, normal and during the seasons in question -expected-

I myself have become even more busy, but the challenge that this thread represents is tempting.

I only have limited time for dev testing in this context but I really still feel compelled to make some time at some point (before the shop module is removed from the kernel blunk.gif Emoticon to setup a test environment with all the tools updated, configured and working so I could test my suggestions myself to see if they affect the results.

Yeah and ... well, I guess I'll come out with it. While I completely understand not being able to reply (soon or at all) and even going in another direction ... I am a bit more than just a little disappointed in that it sounds like you did not test the code change I had requested you to try yourself and report back the results.

I kinda spent a lot of time to do the rather extensive research involved / required on the backgrounds of the processes / usage of the keys software parts involved ... and specific to ezpaypal's usage of them to be able to tell a more specific more based in fact summary as to the way the software should work based on the kernel/ext code involved in the hopes that I could give help based on reading these obscure facts all over again, instead of replying in more general terms.

It hurts to loose that kind of investment of time and effort without an answer, even if a delayed one.


eZ Authorize is one of the most frequently privately re-used payment gateway extension I've ever seen. For years we have had regular reports from users world wide who were using eZ Authorize privately as the basis for another payment gateway service solution in eZ. I'm fairly certain even the most basic PHP developer should be able to re-use it in this way. Though this would depend entirely on the payment service your planning to use supports accepting transactions through a web service and not a web page (curl based transparent payment gateway vs redirect payment gateway).


Again, the hard work has really already been done for you.


I hope this helps ...


Take care ...





You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from