Debug IPN and Webhook Activity for Integrated Gateways

by Kimberly Coleman | Newsletter, PayPal, Troubleshooting

This post shows you how to enable debugging for when your PMPro-powered site communicates with the payment gateway (via webhook, IPN, or silent post).

This is helpful not only when you are experiencing issues, but if you want to have a more detailed view of all the information your gateway transmits about orders and subscriptions.

Choose the Appropriate Debug Statement for your Gateway

The debug lines are listed below for each gateway we integrate with. To enable, just add the appropriate lines to your site’s wp-config.php file. An email will be sent to the site’s admin email as set under Settings > General.

If you have a lot of activity on your membership site, it may be smart to set up a rule in your email account to automatically archive or move these emails to a separate folder.

For PayPal [more info]

define('PMPRO_IPN_DEBUG', true);

For Stripe

define('PMPRO_STRIPE_WEBHOOK_DEBUG', true);

For Authorize.net

define('PMPRO_AUTHNET_SILENT_POST_DEBUG', true);

For Braintree

define('PMPRO_BRAINTREE_WEBHOOK_DEBUG', true);

For 2Checkout

define('PMPRO_INS_DEBUG', true);

If you are using our Add PayPal Express Add On, you can define both the onsite gateway debug as well as the PayPal debug.

Sending Debug Information to Other Emails

You can set specific email addresses to receive the debug information by changing the lines above as follows:

define('PMPRO_IPN_DEBUG', 'email@domain.com,anotheremail@domain.com');

Logging Debug Information (instead of emailing)

You can also set the debug to save to a log file if you’d prefer NOT to receive an email for each piece of activity on your IPN/webhook/silent post URL. Change the line for your gateway as follows:

define('PMPRO_IPN_DEBUG', 'log');

PayPal’s TLS 1.2 and HTTP/1.1 Upgrade and How it Could Impact Your Membership Site

by Jason Coleman | General, Newsletter, PayPal, Troubleshooting

PayPal has announced several security updates set to roll out in 2016 which will impact sites using PayPal gateways. This post covers the TLS 1.2 and HTTP/1.1 upgrade scheduled for June 17, 2016. If all actors involved (your host, WordPress, Paid Memberships Pro, and PayPal) update before June (we plan to), you should experience no disruption in your service. However, if you are using the PayPal sandbox environment now or otherwise want to make sure your host and website are ready, please review the content below.

We’ve outlined the steps to take now to ensure compatibility and avoid a disruption of service.

Note: The contents of this post are highly technical and should be reviewed by your web hosting company and an experienced web developer.

About the TLS 1.2 and HTTP/1.1 Upgrade

PayPal is upgrading the protocols used to secure all external connections made to their system. This includes every connection your site makes with PayPal (onsite or offsite Membership Checkout and via IPN). TLS 1.2 and HTTP/1.1 will become mandatory for communication with PayPal on June 17, 2016.

The latest versions of Paid Memberships Pro have already been updated to use HTTP 1.1 in its API calls to PayPal. However, your server still needs to be updated to use TLS 1.2 for SSL communication.

If your server does not support TLS 1.2 and HTTP/1.1, payments processed via PayPal gateways (PayPal Express, PayPal Standard, and PayPal Website Payments Pro) will fail. You may notice the following error message after clicking to checkout at PayPal:

methodName_ failed: SSL connect error

In addition to this PayPal security update, WordPress also needs to be updated to specify the SSLVERSION for cURL to support PayPal Express moving to TLS 1.2.

Verify Support for TLS 1.2 and HTTP/1.1 With Your Webhost

To avoid disruption in service, you must first verify if your web server supports these security protocols. Contact your web host and find out if your server supports TLS 1.2 and HTTP/1.1. If the answer is no, you will need to work with your web host to enable support. In general, the host only needs to “upgrade OpenSSL to the latest stable version”.

Specify the SSLVERSION for cURL in your WordPress Site

After verifying that your server supports TLS 1.2 and HTTP/1.1, you will also need to make an update to your WordPress site to set an SSLVERSION for cURL (a tool on your server that transfers data from or to a server, using one of the supported protocols). For your site to continue to be able to communicate with PayPal, you need to set your version of cURL to explicitly use the TLS 1.2 protocol. Setting this version prior to PayPal’s TLS 1.2 rollout should not impact current communications with PayPal.

Here’s a code gist for setting the SSLVERSION for cURL that we will continue to develop and improve over time. Copy this code into your active theme’s functions.php file or a custom plugin.

Note: This or some version of this code will be moved in Paid Memberships Pro core or WordPress core prior to the security update in June. The above code gist is only needed if you need to use PMPro with PayPal in sandbox mode in the meantime or if you want to be sure your site will be ready before the updates roll out in the coming months.

Test Checkout via the PayPal Sandbox

The PayPal Sandbox endpoints have already been configured with the latest security standards to which the Production endpoints will be moving.

You can set your Payment Gateway in Paid Memberships Pro to the PayPal Testing/Sandbox Mode to verify support prior to the security release on July 17. See this post on PayPal Sandbox with Paid Memberships Pro »

Testing Your Membership Checkout Process in Development or Sandbox Mode with Integrated Payment Gateways

by Kimberly Coleman | FAQ, Newsletter, PayPal

pmpro_testing-sandbox-membership-checkoutHere are instructions for running a membership checkout test for each of our payment gateway integrations.

These instructions are to be used in place of a “live” test, where you actually pay yourself then refund your transaction.

You can run test on the sandbox first, but we also recommend testing the live environment before going live. Sometimes the sandbox environment isn’t 100% the same as the live environment, either due to configuration differences or because the environments are just subtly different.

Before you do this…

Note that setting your Payment Gateway to “Sandbox/Testing” mode will apply to all visitors that access your site, so I only suggest doing this in a few cases:

In addition to the gateway-specific tests below, you can also set your Paid Memberships Pro plugin to a generic “Testing Only” mode, that will allow you to run through a membership checkout simply by completing all required fields (you don’t need to enter a valid credit card number).

Stripe

Testing a Stripe checkout simply requires you to change some settings in your membership site’s WordPress admin and to use specific testing card numbers provided by Stripe.

  1. Navigate to Memberships > Payment Settings page.
  2. Set your “Payment Gateway” to “Stripe” and set the “Gateway Environment” to “Sandbox/Testing”.
  3. Then, enter the appropriate Stripe API keys for your “Test Secret Key” and “Test Publishable Key”.

After saving the settings, log out or browse to your membership levels page in incognito mode to test checkout for a paid level. Stripe’s testing documentation page has test card numbers you can use for checkout. Use any valid future expiration date, any 3 digit CVV (or 4 digits for Amex) and the test card number below:

Number Card type
Visa 4242424242424242
MasterCard 5555555555554444
American Express 378282246310005
Discover 6011111111111117

PayPal Express, Standard or Website Payments Pro

To test a PayPal checkout, you will need to set up a PayPal Developer account. If you already have a PayPal Developer account, log in to that account via the link above before running a test checkout.

  1. Log in to your PayPal Developer account.
  2. Create Sandbox Test Accounts per PayPal’s documentation.
  3. Navigate to the Memberships > Payment Settings page of your WordPress site.
  4. Set your “Payment Gateway” to the PayPal option you would like to use.
  5. Set the “Gateway Environment” to “Sandbox/Testing”.

After saving the settings, log out or browse to your membership levels page in incognito mode to test checkout for a paid level. You must use a Sandbox Test Account as set up in your PayPal Developer account in order to run the test.

For more information, visit PayPal’s Sandbox Testing Guide.

Authorize.net

Using the Authorize.net Sandbox allows you to simulate the production environment where no actual card processing is performed. You will need to set up a sandbox account with Authorize.net and enter separate “sandbox” credentials for Authorize.net.

  1. Log in to your Authorize.net Sandbox account.
  2. Navigate to the Memberships > Payment Settings page of your WordPress site.
  3. Set your “Payment Gateway” to “Authorize.net”.
  4. Set the “Gateway Environment” to “Sandbox/Testing”.
  5. Enter your Authorize.net Sandbox account’s “Login Name” and “Transaction Key”.

After saving the settings, log out or browse to your membership levels page in incognito mode to test checkout for a paid level. Authorize.net’s testing documentation for page has test card numbers you can use for checkout. Use any valid future expiration date, any 3 digit CVV (or 4 digits for Amex) and the test card number below:

Number Card type
Visa 4111111111111111
MasterCard 5424000000000015
American Express 370000000000002
Discover 6011000000000012

For more information, visit Authorize.net’s Testing Guide.

Braintree

To test a membership checkout with Braintree as the gateway, you will need to set up a Braintree Sandbox account. This is an entirely separate environment from your production account, with unique login information, merchant ID and API keys.

  1. Log in to your Braintree Sandbox account.
  2. Navigate to the Memberships > Payment Settings page of your WordPress site.
  3. Set your “Payment Gateway” to “Braintree Payments”.
  4. Set the “Gateway Environment” to “Sandbox/Testing”.
  5. Enter your Braintree Sandbox account’s “Merchant ID”, “Public Key”, “Private Key”, and “Client-Side Encryption Key”.

After saving the settings, log out or browse to your membership levels page in incognito mode to test checkout for a paid level. Braintree’s testing documentation for the PHP SDK page has test card numbers you can use for checkout. Use any valid future expiration date, any 3 digit CVV (or 4 digits for Amex) and the test card number below:

Number Card type
Visa 4242424242424242
MasterCard 5555555555554444
American Express 378282246310005
Discover 6011111111111117

For more information, visit Braintree’s Testing Guide for the PHP SDK integration.

2Checkout

Testing your 2Checkout integration requires you to set up a 2Checkout sandbox account and use 2Checkout’s provided sandbox test credit card information.

  1. Log in to your 2Checkout Sandbox account.
  2. Navigate to the Memberships > Payment Settings page of your WordPress site.
  3. Set your “Payment Gateway” to “2Checkout”.
  4. Set the “Gateway Environment” to “Sandbox/Testing”.

After saving the settings, log out or browse to your membership levels page in incognito mode to test checkout for a paid level. 2Checkout’s Sandbox Test Data page has card numbers you can use for a test checkout. Use any valid future expiration date and either of the test cards below:

Number CVV
4000000000000002 123
4222222222222220 123

For more information, visit 2Checkout’s Hosted Checkout Testing documentation.

PayPal Payflow

The outstanding gateway in the mix here is our PayPal Payflow integration. In our experience, the only way to set up PayPal Payflow in a “test” mode is to create a totally separate/unique Payflow account and keep it in “trial” mode. PayPal offers this FAQ page on how do I test my integration with the Payflow Gateway? that would be the best starting point if you need to run test transactions for Payflow.

This entry was posted by Kimberly Coleman in FAQ, Newsletter, PayPal and tagged . Bookmark the permalink. Last updated: February 9, 2016. Titled Testing Your Membership Checkout Process in Development or Sandbox Mode with Integrated Payment Gateways

Comparing Payment Gateways: Combined Gateway/Merchant Account

by Kimberly Coleman | FAQ, Newsletter, PayPal

There are plenty of factors to take into consideration when selecting a payment gateway for your membership site. For this post, I’m going to explore the gateways that do not require a separate merchant account.

I’ll cover a few factors including: Transaction/Fixed Fees, Settlement/Payout, Chargebacks & Disputes, and Ease of Use & Issues.

A quick note: Authorize.net was formerly a payment gateway only option, requiring the setup of a separate merchant account. They have expanded their offering to include a Pricing Plan (combined) option. This is the only Authorize.net option compared in this post. You can (potentially) get a better fee structure by using Authorize.net as your Payment Gateway only with a third party Merchant Account. See our reseller pricing here »

Comparing based on transaction fees.

These are the published fees for US-based companies processing transactions over $3,000 USD per month. To see the gateway fees for your country, please check with the gateway directly.

This pricing was last updated on 10/6/2016. Current pricing may vary; please check with the gateway before registration to confirm current fees.

Gateway Transaction Fee Monthly Fee Recurring Billing Fee
Stripe, 2Checkout, Braintree1,
PayPal Express & PayPal Standard		 $0.30 + 2.9% $0 $0
PayPal Payments Pro $0.30 + 2.5% $30 $10
Authorize.net2 Pricing Plan only $0.30 + 2.9% $25 $0

1 Braintree currently offers free processing on your first $50,000 in gross transactions.
2 Authorize.net charges a $49 set up fee.

So, what does this look like for a site with monthly sales of 1,000 units at $20/unit?

Stripe, 2Checkout, Braintree,
PayPal Express & PayPal Standard		 PayPal Payments Pro Authorize.net
Sales $20,000 $20,000 $20,000
Fees (880) (840) (905)
Revenue $19,120 $19,160 $19,095

The Verdict: There is not a huge difference when comparing gateways simply based on transaction and monthly fees. Let’s keep digging…

Getting your cash.

Each gateway has their own payment transfer or settlement timeframe. This is the period of time between when the customer’s payment is accepted on your site and when the cash is deposited into your bank account.

For Stripe, 2Checkout, Braintree and Authorize.net

The payout options vary a bit below, but in most cases funds are automatically deposited into your linked savings or checking account. Here’s a rough schedule of the payment transfer timeframe:

Gateway Timeframe
Stripe Your transfer schedule can be configured within your account either daily, weekly, monthly or manually [more]
2Checkout Via Electronic Funds Transfer to Wire Transfer: Funds are released weekly on a Thursday, This can be extended to 2 weeks or longer to reduce fees [more]
Braintree Credit card payments are generally deposited into your bank account you within 2-5 business days [more]
Authorize.net Credit card payments are settled daily and deposited into your bank account within 2-3 business days

Note that even though your gateway submits the transfer to your bank account, most banks only process the deposit on business days.

For PayPal Express, Standard and Payments Pro

When using PayPal, the funds are automatically deposited to your “PayPal Account” when the payment is approved. You must manually log in to your PayPal account to initiate a withdrawa to your linked bank account. This can be done via a few methods:

  • Requesting a direct deposit to your checking account. Your request will be processed immediately, and your money will arrive in your checking account in 3-4 business days.
  • Requesting a personal check from PayPal. The check will arrive at your home by U.S. Mail within 1-2 weeks.
  • Withdrawing funds immediately using the PayPal Debit Card. Your PayPal balance is immediately accessible via this method. Your card can be use everywhere Debit MasterCard is accepted or withdraw cash from any ATM in the world that displays the MasterCard®, Maestro® or Cirrus® acceptance marks – but note that fees may apply when withdrawing cash at an ATM.

The Verdict: It’s probably a personal bias, but I am not a fan of having to log in to PayPal to initiate a transfer to my business bank account. I tend to swing in favor of the gateways that have an automatic settlement timeframe. Stripe is the most flexible option in this respect.

That said, having a PayPal option at checkout can add significant revenue to your site (I’ll cover this later in the post).

Chargebacks, disputes, claims, inquiries, oh my!

A chargeback or payment dispute is when a customer denies the payment. Even if you offer a refund policy, there will be some number of customers that decide to simply call their bank and initiate a dispute. This could be because of (actual) fraud, dissatisfaction with their purchase, or they are just a despicable person who got their goods and don’t want to pay for it.

Chargebacks/disputes deserve a whole article by themself, but the basic fees are compared below. For each gateway, there is a unique process for managing disputes. You can occasionally avoid the fee by simply issuing a refund, but if a full fraud claim was made, the fee is unavoidable.

Gateway Chargeback Fee Notes
Stripe $15 Disputed charges are withheld from your next settlement [more]
2Checkout $20 Disputed charges are withheld from your next settlement [more]
Braintree $15 Disputed charges are withheld from your next settlement [more]
PayPal $0.30 Disputed charges are immediately frozen in your PayPal balance; The fee for refunding a dispute/claim is the fixed fee portion of your transaction fee ($0.30); The fee for claims escalated to chargeback is $20 [more]
Authorize.net $25 Disputed charges are withheld from your next settlement [more]

You may be able to fight a dispute by submitting evidence that the charge wasn’t fraudulent. You may even be able to contact a customer to have the dispute withdrawn. In my experience, fighting a dispute is rarely successful, and contacting the customer has rarely been a success.

The Verdict: Chargebacks stink, but if I were to select a gateway on this factor alone, the PayPal options are the most favorable. With PayPal, the customer can simply log in to their PayPal account and initiate a claim or dispute WITHOUT calling it a full on “chargeback”. In our own business, PayPal disputes are rarely escalated to chargebacks and the fees are simply the $0.30 fixed transaction fee portion of the payment.

Ease of Use, Issues, Management

Here’s a “synopsis” of some common hiccups we see for the payment gateways covered in this post.

Stripe and Braintree Everything Else
Checkout will fail if your site has JavaScript errors (caused by other plugins, your theme, etc.) Checkout may not fail if you have JavaScript errors, but you should fix them anyway.
Braintree Everything Else
Braintree requires you to create a plan in their dashboard for each PMPro level. Individual plans are created for each order at checkout through the APIs.
PayPal Standard Everything Else
Unknown delay in receiving successful payment notification via IPN (delayed membership activation = frustrated users) Immediate notification of payment success/failure (immediate membership activation = happy members!)
More about PayPal Standard and IPN
PayPal Express, PayPal Standard, 2Checkout Stripe, Braintree, PayPal Payments Pro, Authorize.net
Checkout is a three step process so there is a higher rate of “cart abandonment” or failure at the third party site (frustration or distraction = lost sales) Checkout happens in a single step on your site, and full billing address may be optional (fewer fields and faster checkout = more sales)
PayPal Express, PayPal Standard, 2Checkout Stripe, Braintree, PayPal Payments Pro, Authorize.net
SSL not required SSL required
More about security and PCI Compliance

Using more than one payment gateway.

We offer an add on to add PayPal Express as an option at checkout. This is included by default with the PayPal Payments Pro gateway, so the add on is not necessary if you have selected this gateway.

Many membership site owners find an increase in sales when offering the PayPal option with this add on. Having a PayPal payment option adds credibility and trust to your site and gives you access to over 100 million active online buyers who look for the PayPal way to pay.

Selecting a gateway… continued.

In addition to the various topics covered in this post, you may have unique considerations for your membership site’s gateway selection. You may be limited by your currency or location, or you may be comparing gateways based on security or whether they offer on-site or off-site checkout. You may have a large number of international customers that require different payment methods.

So, just remember that the comparisons above may not be the most important factors in your selection process. If there are other key features in your decision making process, check with the payment gateway directly and learn more about their offering.

Get more information, setup instructions or sign up.

Improving Our PayPal Integrations

by Jason Coleman | About PMPro, Newsletter, PayPal

Paid Memberships Pro integrates with PayPal via four of their merchant offerings: PayPal Standard, PayPal Express, PayPal Website Payments Pro (Legacy), and PayPal Payflow Pro.

Each variation of PayPal has its own quirks, pros, and cons. Our goal is to support any gateway we integrate with to the furthest extent possible. To that end, here are some things we are actively focusing on right now to improve our integration with PayPal.

So what’s going on?

There are a few threads in our support forums and people we have been in email communication about these issues. As we make progress on these, we will share updates on the blog here and in the upgrade notes of any new PMPro version pushed out.

1. Improved synchronization of subscription cancellations.

When users cancel their membership on your WordPress/PMPro site, we attempt to use the PayPal API to cancel their subscription on the PayPal side. I write attempt there because there are cases where PayPal won’t allow us to cancel a subscription through the API.

Most notably, if a user cancels immediately after checking out, their payment is still in “pending” status and PayPal won’t allow us to cancel the subscription. Currently, we send the WP admin an email explaining that the cancelation failed and that they should manually cancel the subscription.

We will investigate ways to detect why subscriptions aren’t canceling and if we can automatically cancel them via a series of API calls (e.g. change the status of the order and THEN cancel the subscription) or schedule the cancelation for later. We will also work to improve the readability and usability of notifications that are sent to emails in edge cases.

2. Improved handling of failed payments.

There are a few ways we can better handle payments that fail on the PayPal side. First, when recurring payments fail, we are not always detecting this via the IPN calls from PayPal to inform users of the failed payment and how they can update their billing information to make the payment right.

Second, there are default settings in PayPal for how many times to retry a failed payment before canceling a recurring subscription. Each API is different, but we should expose these settings to be updated to fit your business and generally make adjusting these values as easy as it is with other gateways we support like Stripe.

Third, when users first checkout with PayPal Express, they are given immediate access to your membership area.

It can take anywhere from a few minutes to 48 hours for their initial payment to process completely.

If the initial payment fails, PayPal will eventually cancel the subscription, which will synchronize to PMPro to cancel their membership on your site. Currently PMPro is developed with the user’s checkout experience in mind and gives them immediate (or a couple minutes in the case of PayPal Standard) access to their membership.

We didn’t want users to have to wait hours or days for payment confirmation before access the site, so we made the decision to give them immediate access. However, site owners should be able to make that decision for their site. We’d like to create a way for site owners to choose whether access is given immediately or after payment confirmation is delivered via the PayPal IPN.

3. Initiating refunds from the WordPress/PMPro dashboard.

We’d like to allow admins to initiate full and partial refunds from the WordPress/PMPro dashboard, when using PayPal or any of the other gateways that support refunds through their APIs. Pretty simple.

If you would like to discuss anything around this development, please feel free to engage with us here in the comments, through the member forums, on GitHub, or in our dev chats.

Customizing your PayPal Checkout Page Design

by Kimberly Coleman | FAQ, Newsletter, PayPal

When you have off-site checkout via PayPal, it is important to give your customers the peace of mind that they are still purchasing from the site they just came from.

PayPal’s “Customize Your Payment Page” setting makes it easy customize the appearance of the checkout page with your own brand’s logo and color scheme.

Getting Started

Log in to your PayPal account then navigate to Profile > Selling Tools > Customize your Payment Page.

This dashboard shows your current page styles and some other options for customizing the Payment Page. You can view all templates, assign the default template, and add or edit templates.

If you click the “Options” tab, you can modify additional settings, including the option to display your customer service phone number.

pmpro-paypal_customize-payment-page

pmpro_paypal-edit-custom-page-stypeAdding a Custom Page Style

From the “Page Styles” tab, click the “Add” button. This will take you to the “Edit Custom Page Style” page.

PayPal currently is updating their checkout page style to a new enhanced checkout experience. A message within my account states that a “select number of customers will experience the enhanced checkout.” The custom style you set up on this page will be used for the new enhanced checkout.

Here’s an overview of the design details you can customize:

  • Page style name (required)

    Enter a name up to 30 characters long. The name can contain letters, numbers, and underscores – but no other symbols or spaces. The page style name is used to refer to the page style within your PayPal account and in the HTML code for your PayPal website payment buttons (not shown to your customers).

  • Logo image URL (optional)

    Enter the URL for an image (.gif, .jpg, or .png) with a maximum size of 190 pixels wide by 60 pixels high. The image appears at the top of the order summary in the enhanced checkout.

    PayPal recommends using an image stored on a secure (https) server. If you do not have an SSL on your site, I would suggest not adding an image to your checkout page layout. If you specify an image that is not loaded over the https protocol, your customer’s web browser might show a message that says the payment page contains nonsecure items.

  • Cart Area Gradient Color (recommended)

    Enter the gradient color for the cart area using HTML hex code. The color code must be 6 digits long and should not contain the # symbol.

  • Header image URL (optional)

    Enter the URL for an image (.gif, .jpg, or .png) that is a maximum size of 750 pixels wide by 90 pixels high. The image appears on the payment page of both the classic and enhanced checkout. The same recommendation for using an image stored on a secure (https) server applies here as well.

  • Header background color (optional)

    Enter the background color for the header using HTML hex code. The color code must be 6 digits long and should not contain the # symbol. The header background color covers the same header area that is 750 pixels wide by 90 pixels high at the top of the payment page for the classic checkout only.

  • Header border color (optional)

    Enter the border color for the header using HTML hex code. The color code must be 6 digits long and should not contain the # symbol. The header border is a 2 pixel perimeter around the header space for the classic checkout only.

  • Background color (optional)

    Enter the background color for the payment page using HTML hex code. The color code must be 6 digits long and should not contain the # symbol. This background color appears as a solid color on the classic checkout and as a gradient on the enhanced checkout.

PayPal in Flux.

I made a PMPro template in my PayPal account, clicked preview, and saw a completely different page from what I see when testing directly from my site. I’m thinking that PayPal is going through some updates at this time, so check your account updates and the PayPal Merchants blog to see when the new new enhanced checkout is 100% live. Until then, your users may see one or more of the following formats:

Specify the Page Style for PMPro Checkouts Only

If you use your PayPal account for more than one business, you may want to use a unique checkout page style for each site you manage.

The code recipe in this post demonstrates how to set the page_style parameter in your PayPal URLs. This will set the page style used for Paid Memberships Pro-based checkouts only (instead of using your PayPal account’s primary style).

Comparing PayPal Gateways and PayPal Gateway Setup Guides for Paid Memberships Pro

by Kimberly Coleman | About PMPro, PayPal

pp_partner_h_rgbPaid Memberships Pro integrates with many flavors of PayPal. See this comparison chart for details on each option, plus a guide on how to set up your selected PayPal gateway under “Memberships” > “Payment Settings”.

See the Comparison Chart

The chart includes links to setup guides for each gateway option. Here’s that list for reference:

Or, you can just offer PayPal Express as an option at checkout

Easily add PayPal Express in addition to your primary integrated processor, such as Stripe or Authorize.net.

Get the PayPal Express Add On

Read This Before Using PayPal Standard with Paid Memberships Pro

by Jason Coleman | FAQ, PayPal

Think twice before you decide to use PayPal Standard as your gateway option with Paid Memberships Pro. There is one good reason to use PayPal Standard over PayPal Express:

  1. Users making one-time purchases on your site will be able to checkout at PayPal without creating a PayPal account.

There are several reasons why you wouldn’t want to use PayPal Standard. I’ll list them here and then go into more detail. If you have gone through this information and still want to use PayPal Standard with PMPro (many people do successfully), be sure to skip below for tips on troubleshooting and avoiding issues that might interfere with your use of PayPal Standard with PMPro.

Why not to use PayPal Standard.

  1. PayPal Standard is not integrated as tightly (more below) as PayPal Express.
  2. If your subscriptions are recurring, your users will have to sign up for a PayPal account anyway.
  3. There are more opportunities for things to go wrong with PayPal Standard.
  4. Many of our Add Ons and code recipes don’t work with PayPal Standard.
  5. PayPal Standard takes more effort for us to support, and we might not choose to support it in the future.

RE #1: the main issue is that with PayPal Standard, the final approval for checkout is done over at PayPal.com. Because of this, we need to wait for the PayPal IPN to send confirmation that the payment was received before we can give a user access to a membership level. We create a WordPress user for them, but we don’t change their membership level until the IPN notification goes through. This is very different from every other gateway we integrate with.

There are many things which can delay or prevent that IPN notification from going through:

  • There can sometimes be a natural delay of a few seconds, to a few minutes, to a few hours. During this time, your members will be in a pending state and have to wait to gain full access to your site.
  • On shared hosting, the script processing the IPN notification might time out and never finish.
  • Some caching plugins and schemes might keep the IPN handling script from running properly.
  • Problems with your PayPal settings (make sure the business email in the payment settings matches the email on your PayPal account) may keep the IPN handling script from verifying the notifications.

If you want to use PayPal Standard, go through this checklist if you are having issues:

  • Make sure you are on VPS hosting or higher. PayPal Standard straight doesn’t work with 90% of shared hosts out there. Many hosts are changing things (caching more aggressively) at the low end which is sometimes causing issues to spring up where they weren’t before. If you are serious about your business, you need to upgrade your hosting and spend $30-$99/month.
  • Make sure your caching plugins and schemes are ignoring the “/wp-admin/admin-ajax.php?action=ipnhandler” URL on your site. If you visit that URL directly, you should see some debugging information. The timestamp at the beginning should update on every page load.
  • Make sure that the “Gateway Account Email” in the PMPro payment settings matches your business email address at PayPal, more preferably it should match your main PayPal email address.

If you are still having issues, we can often work them out for you (assuming you are on a good host) if you sign up for a PMPro support package and share your WP admin account and FTP account with us. Whenever possible, we try to fix issues in the plugin directly so people don’t need one off support like this, but we can’t account for every combination of hosting setups and plugin combinations. PayPal Standard is particularly sensitive, and we often need to tweak things for individual sites.

RE #2: PayPal Express, while still allowing users to checkout offsite at PayPal works better than PayPal Standard because the final transaction is initiated on your own site and confirmation of the payment is received immediately. This way we can upgrade a user immediately and most add-ons related to customizing the checkout process will work as intended.

Because the IPN handler is still used to process recurring payments to create invoices for recurring payments inside of PMPro and send notifications of missed payments, it is still important to make sure that PayPal is successfully connecting to your site. You should go through the same checklist above.

RE #3: As I said, the workflow for a PayPal Standard checkout is different from other gateways. More steps means more chances for something to go wrong.

RE #4: Add Ons and code recipes that rely on hooking into checkout and altering prices or adding fields, etc, may not work as intended with PayPal Standard. This is for a few reasons:

  • It’s hard to keep track of information when users go off to PayPal.
  • At checkout, a user may not have a membership level yet while we wait for confirmation. Some scripts may assume that the user is given a level immediately.
  • The confirmation is eventually processed by the server and doesn’t have access to the user’s current browsing session or cookies.
  • Generally we have to code things once for every other gateway and then once for PayPal Standard, and we sometimes won’t do the later if someone hasn’t hired us to do so.

RE #5: We initially launched PMPro without support for PayPal Standard. However, many people are more comfortable with PayPal Standard since it’s the default in most other membership plugins. So after over a year of people requesting it, we decided to add support. How hard could it be?

It was real hard. And still is. With every update, we spend more time maintain PayPal Standard than we do every other gateway we offer. If I had to do it all over again, I wouldn’t have added PayPal Standard support. In the future, if the burden of support PayPal Standard becomes too much, we may decide to give up on it unless there is someone to donate development time or money to support it. If we do decide to drop support for PayPal Standard, we will be sure to give you lots of early warning and will make a clean break (i.e. at version 2.0) so people who need to have time to migrate or work out support.

So what do we recommend in place of PayPal Standard?

  • If you only have recurring subscriptions, PayPal Express also has no monthly fees and will work exactly as you need to.
  • You might be grandfathered into the PayPal Website Payments Pro API or be able to convince PayPal to let you use it. A phone call could work.
  • You can use Stripe or Braintree or Payflow Pro and setup PayPal Express as an alternative gateway. Stripe and Braintree also have no monthly fees. We hope to make it easier in the future to offer PayPal (or any other gateway) as a secondary checkout option with PMPro.

I hope this helps people who are thinking about using PayPal Standard with PMPro or experiencing issues. If you are still having problems, please sign up for support. If you have comments or concerns about the content of this post, feel free to post a comment, but we will not support the plugin through the comments here.

This entry was posted by Jason Coleman in FAQ, PayPal and tagged . Bookmark the permalink. Last updated: September 16, 2013. Titled Read This Before Using PayPal Standard with Paid Memberships Pro

Users Created Before Payment is Received with PayPal Standard

by Jason Coleman | PayPal

Sometimes we will receive questions like this:

“A problem we are having is that the user account is being created with full access before the payment is processed.”

This is by design and happens when you are using PayPal Standard as your gateway with PMPro.

What we do is give users a WordPress user account before sending them to PayPal to pay, but we don’t apply the membership level until PayPal updates RE the payment later via IPN. We need to do this with PayPal Standard for technical reasons (basically, we can’t remember the password they entered while we wait to hear back from PayPal).

The solutions for this are either:

(1) Lock down you content so it is only available to users with the paid membership level… not just WP users. Or

(2) Use a different PayPal solution (like PayPal Express), which communicates with PayPal immediately… and so we don’t even create a WP users until we hear back about the payments.

The reason this may be extra confusing is that some other membership plugins work different from ours: they process payment and then give users a way to sign up for a WordPress account. What’s great about PMPro is that (when using any other gateway besides PayPal Standard) we create the WP account at the same time that payment is processed. This is a better work flow for users since they only have one checkout/signup page to deal with.

Hope this helps anyone else running into this issue.

This entry was posted by Jason Coleman in PayPal and tagged . Bookmark the permalink. Last updated: March 28, 2013. Titled Users Created Before Payment is Received with PayPal Standard

PayPal DPRP is Disabled for This Merchant

by Jason Coleman | PayPal

If you get the message “DPRP is disabled for this client” or “DPRP is disabled for this merchant” or “DPRP is not available” when checking out for a membership on your site, this means that your have not added the “Recurring Payment Module” to your Website Payments Pro account in PayPal.

You’ll need to log into PayPal and find the link/button to add this feature… easier said than done. I couldn’t find the link in my account, and even if I did, I don’t trust that it will be in the same place or labeled the same way in the future.

UPDATE: I am not sure if there is any way to enable this for Website Payments Pro through the new PayPal interface. The quickest way to get this handled is to call PayPal.

https://www.paypal.com/webapps/helpcenter/helphub/home/

Look for the “Call Us” button.

For the time being though, this link should help you add the feature to your PayPal Business Account with Website Payments Pro:

https://www.paypal.com/us/cgi-bin/webscr?cmd=_dp-recurring-payment-signup

Log into PayPal Business account and then click on this link to go to a checkout form to add Recurring Payments to your account.

This entry was posted by Jason Coleman in PayPal and tagged . Bookmark the permalink. Last updated: March 1, 2012. Titled PayPal DPRP is Disabled for This Merchant