Membership plugin - Paypal IPN is already used in my Paypal account


For my membership site, I've set up PayPal Payments Standard Gateway. Apparently it requires me to set up a Paypal IPN listening URL.

In order for Membership to function correctly you must setup an IPN listening URL with PayPal. Failure to do so will prevent your site from being notified when a member cancels their subscription.

In my Paypal account, I already have a IPN handler set up for an Aweber app. What should I do now?


  • David King


    I know this ticket is a little old, and M1P has been superceded by M2P, but it'd be great to get clarification on the following:

    @Patrick said:

    Actually, that inline documentation is a bit outdated and should be changed to reflect the new way we have coded the plugin.

    With the new PayPal API, Membership now dynamically handles IPN stuff, and you no longer need to enter a URL at PayPal.

    In contrast, @Michael Bissett said here that:

    You need to configure the IPN URL inside of Paypal in order for subscription cancellation/modification/expiration to work properly. When a user signs up for a subscription, the notify_url parameter inside the plugin will take precedence, because the subscription request comes from your site.

    But, imagine for instance that a user goes directly to his PayPal account and cancels the subscription or payment pre-approval. You won't ever be notified about that if your IPN URL is not configured. Hence, the user won't be paying but will still have access to his membership.

    Can you clarify whether M2P (or M1P, for that matter) does or does not require a default IPN listener configured with PayPal?


  • Patrick

    Hi @David King

    I hope you're having a great day!

    Indeed the thread is an old one and should be updated as the info I provided for the old Membership plugin is not valid for M2.

    The Membership2 Pro plugin requires that you set up the IPN listening URL at PayPal if you are using the PayPal Standard gateway. With recurring payments, it is necessary to notify your site if a user cancels their subscription at PayPal so their membership on your site can be adjusted.

  • David King


    Thanks for the confirmation.

    That being the case, and since it appears impossible to disable IPN for manually-generated buttons, it seems necessary to provide a special listener for such buttons, because M2P's notification listener gets confused if the appropriate metadata aren't present.

    Rather than write something from scratch, it seems to me that the better solution would be to adapt Aaron Edward's IPN forwarder script (that you or somebody else pointed me at a while back) to support a generic, log-only IPN endpoint.

    I have begun a github project for this at and have attempted to contact @Aaron (don't know if that's the right Aaron!) via his website but, if you are able to get in touch with him and in case that message doesn't get through, please would you let him know of the above?

    For anybody else reading this thread, you will need to use either Aaron's original IPN forwarder script (as linked above) or my adapted one (whatever becomes of it) if you have multiple applications attached to the one PayPal account.

  • David King

    I'm not sure that a broadcaster is a good idea, unless M2P's behaviour — and that of every other IPN listener involved — when receiving unexpected IPNs is well-defined. Better to route IPNs to the correct destination than to rely on each listener to "do the right thing", if at all possible.

    To add to my earlier post in this thread and after a bit more research into Aaron Edward's IPN forwarder script, ipn-forward.php needs some way of identifying how to route the message. It can do so based on a variety of fields one of which is the PayPal 'custom' button field which M2P doesn't otherwise appear to use. You can do so by using a filter as I demonstrated here.

    ETA: the following code will do the job:

    defined( 'M2P_CUSTOM_FIELD' ) or define( 'M2P_CUSTOM_FIELD', 'IPN_MS2PRO' );
    add_filter( 'ms_gateway_paypalstandard_view_prepare_fields', 'membership_button_custom_fields' );
    function membership_button_custom_fields( $fields ) {
            $fields['custom'] = Array( 'id' => 'custom', 'type' => 'hidden', 'value' => M2P_CUSTOM_FIELD );
            return $fields;
    • David King


      IPN stands for Instant Payment Notifications. It's PayPal's way of communicating back to the initiator of a transaction (eg an ecommerce store) the result of a payment transaction. For one-off transactions (eg shopping carts, buy-now and one-off donation buttons), the initiator can specify the URL to which PayPal should transmit the IPN message.

      However, you can also set an IPN listener URL in your PayPal profile itself. PayPal will use this if notify_url is not specified, or if, for example, a recurring payment such as for an M2P subscription is cancelled (because in such cases, PayPal is initiating the IPN message and there is no notify_url to specify).

      If you're running just one application, like M2P, then you set the listener URL at PayPal to that indicated by M2P.

      If, on the other hand, you run multiple stores or multiple applications, suddenly you may have a problem: Each application may require you to set PayPal's IPN URL to their own, but you can't set more than one URL because PayPal can't tell which URL to use. In such cases, you either need to use an IPN broadcaster as @Patrick suggested, or you can use an IPN forwarding script I linked in a previous post to this thread.

      If you aren't running multiple applications, then you don't need to worry about this. Just set the IPN listener URL at PayPal as M2P instructs you to.

  • HamRadioDude

    @David King Thank you for updating the IPN Forwarder Script.
    I have a 2 questions I'm a little confused on 2 things. I downloaded your github project master zip
    First: The code you have above for Membership 2 Pro Plugin

    defined( 'M2P_CUSTOM_FIELD' ) or define( 'M2P_CUSTOM_FIELD', 'IPN_MS2PRO' );

    add_filter( 'ms_gateway_paypalstandard_view_prepare_fields', 'membership_button_custom_fields' );
    function membership_button_custom_fields( $fields ) {
    $fields['custom'] = Array( 'id' => 'custom', 'type' => 'hidden', 'value' => M2P_CUSTOM_FIELD );
    return $fields;

    Do we need to put that into the script?

    Second: you have this field
    define('INC_PASS', 'xxxxxxxxxxxxxxx');
    I'm I correct that we need this if we define ($_POST['inc_pass']) in the script that goes to pay at paypal?

    OK I lied I have a third Question
    where do we put the /log/ directory?

    thank you so much for updating this

  • David King


    The IPN forwarder code is not my code, sorry, and I haven't yet deployed it so I can't answer any questions about it directly. My suggestion is that you set up a staging instance and play with different applications using PayPal sandbox credentials. Be sure to check what happens when the client cancels any recurring payments etc.

    Do we need to put that into the script?

    The code snippet I provided can be put anywhere that is executed as part of the normal wordpress request execution path. Don't put it in the IPN forwarder, because that only gets invoked by PayPal when it makes IPN callbacks.

    wp-config.php would probably do, else you can write a plugin and put it in there. This might make more sense on a WPMS instance (and is what we do for custom code we want to affect certain sites).

    I'm I correct that we need this if we define ($_POST['inc_pass']) in the script that goes to pay at paypal?

    I don't think that's right. $_POST is a reserved variable that contains the POSTed parameters when the request has a MIME type of application/x-www-form-urlencoded or multipart/form-data. Setting variables in it won't transmit them to PayPal because it reflects the contents of the inbound request being processed.

    If you want to get information handed back to you by PayPal, you have to send certain fields to PayPal as hidden inputs in the form that takes you to paypal. The variable CUSTOM will be handed back verbatim in the IPN call and its contents will never be seen by the user, but you can potentially use other fields such as ITEM_NUMBER or the ON*/OS* fields (which are visible to the user).

    It all depends on the applications you're using and whether they use the CUSTOM field or not, and if they do, whether there is anything in it you can use to identify the application to which the IPN call can go.

    Note: Some applications may not require the IPN routing code because you can override the default notification URL with NOTIFY_URL in the payment request. Those applications probably don't need the router, unless there are recurring payments involved that PayPal needs to notify the application of in the future.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.