Product Support

Member Payments

Integrates PayPal payments into Participants Database with a full set of features for managing dues payments, pay-to-join and lots more.

Product Setup

Important Note

This plugin is complex and it involves a lot of configuration to get it doing what you need. It is very¬†important to completely test the plugin’s functionality before you start taking payments. I suggest you use the PayPal Sandbox for your testing, it lets you make as many test purchases as you want so you can be certain it’s working as expected. I’ve included a special set of settings just for testing to help you avoid unpleasant surprises after you go live.

I do offer support for configuring the plugin, but I cannot guarantee a timely response. Don’t put yourself in the position of having to make an emergency support request. If you’ve tested the functionality before going live with it, you can be sure that things will go smoothly once you’ve started accepting payments.

How It Works

The plugin works by placing a PayPal payment button in a Participants Database form. When the user clicks on the PayPal payment button, the contents of the form is processed into Participants Database and the user is sent to PayPal to make the payment. When they complete their transaction, a record is made of the payment via PayPal Payment Data Transfer and/or Instant Payment Notification.

To keep a log of member payments, this plugin requires the PayPal account be configured to send Instant Payment Notifications and/or process a Payment Data Transfer.

Configuring the Member Payments Add-On is a bit complex, but these instructions will help you get it all working. These are the main parts, we’ll explain each one in turn.

  1. Set up the PayPal payment button
  2. Set up to receive PayPal payment data
  3. Set up your payment forms
  4. Set up payment logging

Configuring PayPal

Everything in this section requires that you be logged in to your PayPal account.

The first thing you will need to set up is the payment button. You may be familiar with this in PayPal, it is a little snippet of HTML that when displayed on a web page, is a clickable way to make a payment at PayPal.  If you are already using an instant payment button, you can use the same code in the Member Payments add-on.

Set Up Your PayPal Button

Log in to PayPal, and go to your Profile page. Click on My Selling Tools, and find PayPal Buttons near the top of the list of items on the right. Click on “update” to the right of “Manage my payment buttons.” That will take you to a list of default and custom buttons. If you already have a button set up, use that one. Otherwise, follow PayPal’s instructions for setting up a payment button.

Note that you cannot use a “hosted” button, it has to be a button that has all the the payment parameters in it.

Once you have your button code (you must copy it from the PayPal site) insert that code into the “PayPal Button HTML” setting in the Member Payments setup under the General tab. Now, all your Member Payments shortcodes will include that button in the form.

(Setting this up for PayPal Sandbox is exactly the same, with the important difference being you’ll be logged in to sandbox.www.paypal.com with your sandbox account.)

It’s also possible to use a different button code for each shortcode by including the button code in the “button_html” attribute of the signup, record or member payment shortcodes. More on that in the Product FAQ.

If you use “hosted” buttons (which are a bit more secure), you won’t be able to control the return page from the plugin side. The return page when using a hosted button is set up in the button configuration. If you have more than one payment portal, and want to give each one a different return page, you will need to define a separate hosted button for each one.

Logging Payments

There are two ways that PayPal sends transaction information to your website so that the¬†user’s payments can be logged: Instant Payment Notifications (IPN) or Payment Data Transfer (PDT). You can use either or both, but it is recommended you use both so that you have a backup method in case one fails. Using both methods will not result in duplicates in the log, each¬†transaction will only be logged once.

IPN and PDT both supply the same kind of information, but in two different ways:

  • IPN is asynchronous, meaning that is it sent in the background independently of the user’s actions, usually within a few seconds. That means that IPN¬†doesn’t rely on the user going back to the site after authorizing the purchase. Their transaction will be logged anyway. In most cases, this method serves as a backup in case something happens and the user doesn’t make it back to the “thanks” page.
  • PDT requires the user to return to the “Return URL” so the payment data can be given to the website. The advantage here is that the information is available immediately. If you want your users to return to your site to be thanked and have their payment acknowledged, you must use this method.

More info on the difference between the methods from PayPal: IPN vs. PDT

Setting Up Instant Payment Notifications

  1. go to your PayPal profile/My selling tools
  2. find “Instant payment notifications” and click on “update”
  3. click on “Edit Settings”
  4. enter your IPN Notification URL: it is the home URL of your WordPress site
  5. select “Receive IPN messages”
  6. save, and you’re done.

Setting up Payment Data Transfer

  1. go to your PayPal profile/My selling tools
  2. find “Website preferences” click on “update”
  3. Auto Return: select “On”
  4. for the “Return URL,” put the URL for your “thanks” page (the one with the [[pdb_member_payment_thanks]] shortcode)
  5. find Payment Data Transfer, select “On”
  6. just below this, you’ll see the “Identity Token” select and copy this token
  7. go to the bottom of the page and click on “save”
  8. back on your WordPress site, in the Member Payments settings, general tab, paste in the token

With these configurations, logging of PayPal transactions can begin.

Payment Forms

There are three different ways to implement the Participants Database payment button. You can use any or all of them. You’ll need to decide which is right for your situation.

Once you have chosen the method or methods you want to use, you must either change your existing Participants Database forms shortcodes or place new¬†shortcodes. You will need to place new shortcodes if this is a new installation or you want to use the “Member Payment” form.

The shortcodes provided by this plugin use all the same attributes of the regular Participants Database form shortcodes. The [pdb_signup_member_payment] shortcode shows a signup form with a PayPal payment button so that a new record is created when the form is submitted. The [pdb_member_payment] shortcode gives members an easy way to make a payment on their account.

If you are using custom templates, you must alter those templates to include the payment button. By inspecting the templates provided by this add-on and comparing to your custom template it’s easy to add the code needed to show the payment button.

Setting Up the “Thanks” Page

Each of the payment forms can be configured to take the user to a “thanks” page after the payment is made.

The way this works by default is a little different for each one. In all cases, after the user makes a PayPal payment, the user is returned to the “Return URL” as configured at PayPal. They will also be returned to this page if they cancel the transaction, and the plugin will show the “Cancel Return Message.”

For the Signup Payment form, when an offline payment is made, the thanks page will be the “Signup Thanks Page” as configured in the main Participants Database settings.

All of these behaviors can be modified in the shortcode. For the Signup Payment, the page the user is returned to after making an offline payment can be determined by the “action” attribute in the shortcode, for instance: [pdb_signup_member_payment action="offline-payment-thanks"] will send the user to a page named offline-payment-thanks after selecting an offline payment and submitting the form.

(Please note: for any thanks page that is designed to work with the Signup Payment form, you must use the [pdb_signup_member_payment_thanks] shortcode.)

For PayPal payments, the “return_url” and “cancel_return” attributes can be used to set what happens when making a PayPal payment…for example:

[pdb_signup_member_payment return_url="member-payment-thanks"]

This will return the user to the page named “member-payment-thanks” after making their PayPal payment, overriding the “Return URL” setting. When setting up a thanks page for the Member Payment form you must use the [pdb_member_payment_thanks] shortcode on that page.

All of the payment forms will work as their own thanks page: if the user goes back to the form page after making a payment or submitting the form, it will show the appropriate thanks message.

Configuring the Payment Log

The user’s payment is logged to a special field in Participants Database that is automatically set up by the Member Payments plugin. The new field will appear in an admin field group (if you have one, in the first field group if you don’t). After activating the plugin, go to the “Manage Database Fields” page in the admin, click on the tab for an admin field group (the default is “Administrative Info”), and look for a field named “Payment Log” That is your log field and you can change it’s configuration there, including changing it’s title or moving it to another group if you like.

Configuring the Log Fields

When a user makes a payment, PayPal sends a packet of data back to the site. There are lots of pieces of information in that packet, but only a few of them will need to be logged. The plugin pre-configures the log fields, and for most installs, that will be all you need. If you need, you can change which data fields you are logging in the log field configuration: Advanced Log Field Configuration

Configuring a Dues or Payment Schedule

For many situations, you will want members to make payments on a regular basis, such as for a dues payment. The plugin can tell you what each member’s payment status is, but in order to do that, you have to configure your payment schedule.

There are two kinds of payment schedule: fixed date and period. A fixed date schedule is for¬†dues that are always due on a specific date or dates of the year. For instance a biennial schedule could be: January 1st and July 1st. The user’s payment becomes due on those dates. The¬†period schedule is more like a subscription payment: the payment is for a set period of time, beginning the date the payment was made. The next payment will be due when that period is over.

See the “Settings” tab for details on configuring the payment schedule.

Member Payment Status

Each member has a payment status based on the payment schedule and when the last payment was made. Those statuses are:

  • paid (the member is current with payments)
  • payable (it is time to make a payment)
  • due (the payment due date is past)
  • past due (the member is late on their payment)

The “payable” and “past due” dates are configurable relative to the due date. For instance, you can set it up so that the payment becomes past due 7 days after the due date.

When the member’s payment status changes, an event for that change is triggered. When the Email Expansion Kit is installed, it is possible to set up an email that will be automatically sent on the status change. For instance, you can set up an email to go out when the member’s payment is due, and a different one that goes out when the member’s payment is past due.

Setting Up the Last Value Fields

In most cases, it’s the values in the last log entry that carry the most relevant values. You can create what are called “last value fields” that hold the last value of any of the log fields. One useful application of these fields is for showing information to the user: while the log itself is usually only visible to administrators, it may be useful for the regular user to know when the last payment was, for instance.

Last Value Fields are set up by creating a new field with the same name as the log field you want it to mirror. For instance, there is a log field named “payment_date” which holds the date of the payment. By creating a date¬†field named “payment_date” you will set up a field that will always contain the date of the last payment in the log.

To set up a field that shows the last amount paid, you can create a field named “mc_gross” (this is the name of the payment amount field PayPal uses) and it will be filled in with the last amount paid, including manual payments. Once you have created the field, you can change the title of the field to anything you want.

Last Value Fields can use other field types, as well. For instance, with the “payment status” field there is a limited set of possible values (as defined in the IPN/PDT variables), which means it would work well as a dropdown field.

Note that the last value field must appear in the payment log for the value to be transferred to the last value field. This means that the field must be listed in the “options” of the Payment Log field.

If you are planning to offer options for your payments (such as different price options) you can track the user’s selection using a last value field. The instructions for configuring that are in this article: Setting up payment options in Member Payments.

Manual Log Entries

If the “Payment Log Edit Lock” setting is unchecked, it becomes possible to add a new entry to the edit log. When the new entry is added, it is placed in the log according to the payment date.

The manual log entry uses text fields to enter values unless a last value field has been defined for that log field. In that case, the last value field definition is used to define the input control used for the new log entry.

For instance, if you set up a dropdown field (as suggested above) for the “payment_status” log field, when adding a new log entry, the payment status field will be set using a dropdown control.

Value Tags

User feedback and emails use a templating system like the one in Participants Database¬†that allows you to use “value tags” in your messaging. These value tags will include all the fields defined in Participants Database, all the data fields in the PayPal transaction, and several payment status fields if you are using the Payment Status module of the add-on. A value tag is simple the name of the field whose value you want to show in brackets like this [txn_id].

A list of useful tags is as follows.

  • [txn_id] – the transaction ID from the PayPal purchase
  • [txn_amount] – the transaction amount
  • [payment_status] – the current payment status of the account… like “paid,” “past due,” etc.
  • [last_payment_date] – the date of the last payment
  • [next_due_date] – the date the next payment will be due
  • [option_selection1] – if your payment button has options, the selected option will be in a field like this (the name may vary, look at your payment button code for the name you need to use)

Advanced Setup

Here are some instructions for getting deeper into the configuration of this plugin. Instructions in this section are optional, you don’t need to do anything here, they are additional capabilities you can access if you need.

Email Communications

This add-on works with the built-in email functionality of Participants Database: when the signup payment form is used, the person signing up gets the usual receipt email, and the administrator gets their notification (if configured to do so). The same is true of the “Profile Payment” form: as in Participants Database, there is no user email for updating their profile, but there is an administrator notification for that.

The built-in emails can all use the “value tags” from this add-on as described above.

Advanced Email Configuration

With the addition of the Email Expansion Kit, many more possibilities become available for email communications. Custom emails can be triggered on a number of events generated by this add-on:

  • Signup Payment Return
  • Member Payment Return
  • Profile Payment Return
  • Cancel Payment Return
  • PayPal IPN Recieved

Status Change Emails

When using the Payment Status module, events are generated when the member’s payment status changes. For instance, when a member’s uses payment becomes due. These status change events are triggered automatically in the background according to the date, and also when the payment log is updated with a new payment. There are four status change events that you can use:

  • Status Change to Paid
  • Status Change to Payable
  • Status Change to Payment Due
  • Status Change to Past Due

Advanced Payment Log Field Configuration

The payment log is pre-configured to include the most important fields of information. There is more information available, however, and this is how you can change which fields are logged.

Looking at the “Payment Log” field, in the “values” area, you’ll see the log columns defined as a comma-separated list of name::title definitions. For instance, the first one is¬†payment_date::Date that means that the name of the data field is “payment_date” and the title of the field (or column) is “Date” You can change the title to anything you want at any time. Be careful about changing the name of the data field because that corresponds to a data filed in the packet the site receives from PayPal.

A full list of the data fields can be found here: IPN and PDT variables Much of that is pretty technical, and it may take a little research to understand what info you need to log. The default columns that are pre-set by the plugin will give you most of the important stuff, so you can just leave the default setting for the log fields in most cases.

Product Settings

PayPal Settings Tab

Payment Button Label

Optional text label for the payment button in the form.

PayPal Identity Token

This is an identifying code used by PayPal to authenticate a Payment Data Transfer communication with the web server. Not needed if you don’t use PDT.

PayPal Button HTML

Usually, this is obtained from PayPal from the defined payment buttons for your PayPal account. This HTML can be modified (if you know what you’re doing) to add selections and other variations, or to change the appearance.

Member Payment Settings Tab

These settings only pertain to the [pdb_member_payment] shortcode, you don’t need them if you are not using this payment method.

Payment Form Match Fields

These are the fields that are used to identify the user. This could be something like a “username/password” combination, or something as simple as a member ID or even an email address.

This form does not give access to sensitive information, but the field or fields must identify a single record only, so that the payment can be credited to a single record in the database.

Record Not Found Message

Message shown if the entered data does not match any record in the database.

Payment Thanks Message

Message shown on the screen after a payment is made. This is only seen if the user returns to the site after completing the payment at PayPal. Value tags are available in this template.

Cancel Return Message

If the user uses the “cancel return” button on the PayPal payment page and returns to the site without completing a payment, this message is shown on the screen.

Signup Payment Settings Tab

Approve on Payment

When checked, a new signup will have the “approved” field marked “yes” when payment is received.

Signup Payment Thanks Message

This message is displayed on the screen when the user returns after making a payment.

Cancel Return Message

This message is displayed on the screen if the user submits the form without making a payment, or if they cancel out of the off-site payment.

Enable Offline Payments

If checked, the user will have the choice to pay using an offline method, such as a mailed check or an in-person payment.

Payment Type Selector Label

This labels the radio button selector used to choose the payment method.

Offline Payment Label

This is used to label the offline method in the payment method selector.

Offline Submit Button Text

This the text on the submit button when using an offline payment method.

Offline Payment Method Help Message

This is shown next to the offline payment selection in the payment method selector.

Offline Payment Thanks Message

Shown after the user submits the signup form while using the offline payment method.

Payment Status Settings Tab

Enable Member Payment Status

Check this to keep track of your members current payment status.

Payment Due Mode

Theses correspond to two ways of structuring your member payments: either as a set schedule (Fixed Dates) with payments due on certain dates of the year, or as a period determined by the date of the last user payment (Fixed Period) like a membership subscription that is purchased for a set period of time.

This selection determines how the due dates are calculated, and so the next setting shown depends on this setting.

Fixed Dates: Renewal Dates

If the Payment Due Mode is “Fixed Dates” this setting is used to determine when those due dates are. This setting is a list of yearless dates, one date per line.

The default setting is

Jan 1
April 1
July 1
November 1

Which corresponds to a quarterly payment schedule beginning on January 1.

Fixed Period: Renewal Period

If the “Fixed Period” mode is used, this setting determines the period of time the membership payment is good for. Typical payment periods are available in a dropdown, more can be added using a code filter.

Multiple user-selectable payment periods, and payment for multiple periods (for instance if someone wanted to pay for more than one period) are not currently supported, but this is in the works.

Fixed Period: Late Payment Setting

When a payment is received before the due date, it is always credited to the due date, but if a payment is late, you can choose how the payment is applied in that case.

If “Payment goes to last due date” is selected, the late payment will always go to the last due date. For instance, if dues are collected every month, but a member is over a month late with their payment, they will be paying for the unpaid month, not the current month.

If “Payment goes to last payment date” is selected, the late payment counts from the date of the payment. For instance, as in the example above, if the member is over a month late, their payment will go to the current month, and the payment period will begin on the date of the payment.

Last Payment Date Field

This is the field used to store the date of the last payment. It must be a “Last Value Field” holding a date. This defaults to the “payment_date” field in the PayPal transaction data.

The text label used to show the payment status when the user is current with their payments.

Payment Due Status Label

The text label used to show the payment status when the member’s due date is passed, but is not overdue.

Payable Status Label

The text label used to show the payment status when the member’s payment can be made before the due date. This setting also has the number of days before the due date that a payment can be made.

This setting is important to determining which due date a payment can be credited to: if a payment falls within the payable period for a due date, it is assumed the payment is for that due date.

Past Due Status Label

The text label used to show the payment status when the member’s payment is overdue or past due. This setting also has the number of days after the due date that a payment¬†becomes overdue.

Advanced Settings Tab

The settings under this tab are available to administrators only.

Payment Log Edit Lock

If this is checked, the payment logs cannot be edited. This also prevents manual log entries from being made.

Use PayPal Sandbox

PayPal Sandbox provides a way to test your payments setup. It does require some technical knowledge and requires a developer account with PayPal. Setting up the account is free, and PayPal does a good job of explaining how to do sandboxing.

You must use a sandbox account payment button and token to make sandboxed test payments.

More info on PayPal sandboxing here: https://www.sandbox.paypal.com/

PayPal Sandbox Identity Token

This is the token to use while sandboxing, this is obtained from your sandbox account at PayPal.

PayPal Sandbox Button HTML

This is the button code to use while doing sandbox testing.

Testing Date

This is used for testing different scenarios for the member payment status. You can use this to simulate any date and what the member’s status will be on that date. This will also trigger any status change actions (such as an email if you have that configured in the Email Expansion¬†add-on) so those can be tested as well.

This setting is only active if WP_DEBUG has been enabled. Keep it blank if you need to have WP_DEBUG on and want the member payment statuses to be calculated using the current date.

It is not recommended you run a live site with WP_DEBUG on, but if you must, you should leave this setting blank.

F.A.Q.

Is it possible to set the "return URL" in the shortcode?

Yes, both the Return URL and the Cancel Return Url can be set in the shortcode if you need a different payment flow for one of your forms.

What are the value tags or placeholders I can use in email templates?

The Member Payments plugin offers several value tags or placeholders that you can use in your email templates (when using the Email Expansion Kit) which include data returned from the payment processor and values that are generated as a result of the transaction. Here are some of the more useful ones:

  • [payment_status] shows the current payment status for the member (such as “paid” or “past due”)
  • [next_due_date] the date that the next payment will be due

PayPal return values

  • [mc_gross] when using PayPal, this is the amount of the payment that was just made. You can also use the [txn_amount] tag for the same thing.
  • [option_selection1] if you have a selector in your PayPal payment button, this is the value that was selected for that
Do you support other payment portals?

Not at this time, but it is in development. The Member Payments plugin currently supports only PayPal and offline payments.

What if a member wants to pay in person or with a check?

This is what “offline payments” are for. It gives you the ability to log a payment manually, and it will become part of the member’s record.

To add a payment log entry, open the member’s record for editing in the admin side. Find the “payment log” field, and you will see that it is possible to enter values for a new entry. Save the record to store the entry.

If you don’t see the fields you can type the new entry into, make sure the “Payment Log Edit Lock” setting is unchecked. Also, the backend user must have the necessary access level (usually editor or administrator).

Can I use a different PayPal button on another form?

Yes, there is the “button_html” shortcode attribute where you can place the HTML that will determine the PayPal button used. For instance:

[pdb_signup_member_payment button_html='<form action="https://www.sandbox.paypal.com/cgi-bin/webscr" method="post" target="_top">
<input type="hidden" name="cmd" value="_s-xclick">
<input type="hidden" name="hosted_button_id" value="JAFG98A">
<table>
<tr><td><input type="hidden" name="on0" value="membership type">membership type</td></tr><tr><td><select name="os0">
<option value="newbie">newbie $10.00 USD</option>
<option value="regular">regular $25.00 USD</option>
<option value="gold star">gold star $350.00 USD</option>
</select> </td></tr>
</table>
<input type="hidden" name="currency_code" value="USD">
<input type="image" src="https://www.sandbox.paypal.com/en_US/i/btn/btn_buynowCC_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!">
<img alt="" border="0" src="https://www.sandbox.paypal.com/en_US/i/scr/pixel.gif" width="1" height="1">
</form>' ]

It’s important to use single quotes to enclose the HTML, and that the HTML uses double quotes only. If, for some reason, you need to include an apostrophe, you have to use the HTML entity equivalent: &#34;

Note: this code is not a valid button, you must create your own button code in PayPal.

Can a record be automatically un-approved when the payment period ends and they have not made a payment for the next one?

Yes, it requires that you set up an action that is triggered when the account becomes due. This is a gist that demonstrates how to do that.

This action is set to fire when the account becomes due. If the user pays before the due date, the record will not be unapproved because the event won’t fire.

This assumes that you have set up the “Payment Status Settings” in the Member Payments addon.

Is it possible to use "Field Group Tabs" with the payment forms?

Yes, but I had to release an update to make it possible. Because both add-ons affect how the submit buttons works, I needed to create a special template to make it work.

These templates are named “bootstrap-tabs” and you can use them by setting up your shortcodes like this:

[pdb_signup_member_payment tabs=true template=”bootstrap-tabs”]

[pdb_record_member_payment tabs=true template=”bootstrap-tabs”]

Of course, these can be customized, you can use these templates (located in the add-on as /templates/pdb-single-member-payment-bootstrap-tabs.php and pdb-record-member-payment-bootstrap-tabs.php) as a starting point. Be sure to pay extra attention to the submit button setup, it’s a bit complex.

How do I set up automatic notifications for a payment that is due?

You must install the Email Expansion Kit add-on to provide the additional email capabilities needed to automatically notify your users when a payment becomes due.

The process for setting this up is the same for all the payment status events Member Payments generates.

First, of course, configure your Payment Status settings according to your needs. This sets up the conditions under which a user knows whether they are paid, past due, etc. When the user’s status changes, an event is generated. This event can be linked to one or more email templates so that an email will be sent at that time. The Member Payments plugin uses a “cron” to automatically check for these status changes and trigger the event: the user does not have to be logged in for this to happen.

Once you have the Payment Status configured, create a new Email Template and assign the event to the “Send Action” for the template. To let a user know their payment is past due (for example) select “Member Payments: Status change to: Payment Past Due”. Be sure to fill in the recipient name and email (use value tags for that) and then fill in the body and subject of the email that you want sent when that event occurs. You may want to include a link to the page where the payment can be made.

How do I test payment status notification emails?

Once you have your payment status notifications set up (these are email templates that are configured to send when a user’s payment status changes), you may want to see what happens when a payment status change event is triggered. The best way to do this is to use a test account and start with a test payment so you know what the starting condition is. This is helpful because the trigger is a status change, so you will want to know what the initial status is.

Important: to test this you must have WP_DEBUG set. Take a look at this page if you’re unsure how to set that up. This is something you will only want to do temporarily, don’t run your site with WP_DEBUG on unless you’re actively testing. You should also turn debugging on in Participants Database so you can see in the debug log what happened.

So, let’s say that your payment is set up to be good for a month, and then the user needs to pay again. The way to test this is to go to the Member Payments settings under the Advanced tab and set the “test date” to more than a month from the date the test account made their payment. Now go to the test account’s admin edit page and save the record. The plugin will check the status and if it is changed, trigger the event and thus the email. Check the debugging log to see the outgoing email.

Testing the Cron

If you want to test the effect of the cron, you should first install a cron management plugin such as Crontrol. The Member Payment plugin uses a cron named pdbmps_cron_updates to check for payment status changes. Set the test date as explained above, then trigger that cron event. You will see the effect of the status change in the debugging log.

Be sure that you know the initial status of the record you are testing. If the record’s status is already at the tested status, then a change won’t happen and the event won’t be triggered. You may need to look at the record’s data directly (using phpMyAdmin) to know for sure what the initial status was.

Support Discussions for Member Payments

  • We would like to use member payments to enable yearly membership (where next payment date is 1 year from the last paid date). Payment Due Mode is FIXED PERIOD (1 year).

    Currently we have a spreadsheet with last date paid, next payment date (i.e., membership expires) and would like to preload the PDb with the membership list and honor the different payment expiration dates for the members.

    There doesn’t appear to be a way to preload the “as of” member “history” when performing an import of the CSV. I’ve tried setting the last payment date, current status (i.e., paid), and next payment date via the import (using the pdbmps_member_payment_status, pdbmps_next_due_date and pdbmps_payment_date fields). The import updates the participants_database table correctly but since there is no payment history, the LIST Participants function shows blanks in the Member Payment Status, Last Payment Date and Next Payment Due date fields.

    Is there anyway to preload payment history without manually trying to build/load these records (which would be difficult to do)? It almost appears that we have to start from scratch which we don’t want to do.

    • Member Payments is not a full-featured payments manager, there are limits to what it can do. There isn’t any easy way to import a payment history, for example.

      If you need to import records where each one has its own date when the last payment was made, you can achieve that by setting the “date_recorded” timestamp to the date of the last payment for that record. If a record has no payment history, it assumes the last payment was the “date recorded” value for the record if the “Initial Payment Status” setting is set to “paid.”

      • Roland, thanks and understood. I tried that and it works great for the existing members (imported) that have no payment history. However, if a new member registers but does not pay, the last payment date is set to the current date and the next payment date is set one year in the future (with payment type of ‘none’). Makes them look like they really paid (except for the ‘none’). Setting Initial back to blank fixes the member who did not pay but then also resets the status of all the existing members with no payment history. Am I doing that right?

        Only thing I can think to do is load existing members (initial set to blank) and then just add a manual payment history record with a backdated date for each existing member – like 12/31/2019). Their membership expires this Dec and the email expansion kit successfully triggers notifications (nice).

        • Yeah, I’m sorry it’s a bit of extra work, but manually adding a payment is going to give you the most consistent results with your setup.

          Your case has got me thinking about the possibility of making it possible to import a record with a payment in the log…hmmm.

  • I cannot seem to locate the layout/available fields available to pass through from PayPal to PDB payment log table. I know I found it one time but can’t remember where. I’ve searched PayPal help, Google, Maybe I read it in one of your documents? Could you please refer me?

    • How this works is there is a set of data that is posted back to your site from PP. Each field of that data has a name, you use that name to add a field to the payment log. You will see this in the “attributes” setting for the payment log field.

      There is a little bit of information on this here: Advanced Payment Log Field Configuration

      One thing you can do to see what is going on behind the scenes is to turn plugin debugging on (this is in the main plugin settings under the advanced tab), then test a transaction and see what data is getting posted back to the site in the debugging log. This will tell you what fields you can add to the log.

  • Hello Roland,

    I have a number of participant entries to import into the Participants Database. How can I manually set the pdbmps_next_due_date value? I do not seem to be able to import it.

    Thanks,
    Peter

    • The next due date is calculated based on the last payment and the payment period calculation, so it’s not possible to set the value directly whe the record is imported. The way to do this is to set the “Initial Payment Status” to “paid.” When the plugin calculates the next payment due date for a record that has no payment history, it uses the “date_recorded” field to calculate when the next payment will be due.

  • I am having a challenge getting “Add to Cart” to proceed to PayPal. By accident I found that it works only after a second click of the button about 5 seconds after the first works. What’s going on?

    • You cannot use “add to cart” buttons with Member Payments, you can only use “buy now” type buttons. Member Payments does not support the PayPal cart.

    • Thank you for you assistance. Apparently the “Add to Cart” button was indeed working until the last security PayPal security upgrade was activated. A “Buy Now” button was substituted and the Member Payment is currently functioning as expected.

      • Interesting, thanks for that. There was a change to PayPal’s security that led to some people not being able to make payments, but I issued an update recently that addressed this. You may be able to go back to using the add to cart button with the most recent release, I don’t know.

        I’m going to check into that myself since you were using those buttons successfully before.

  • I see PayPal have some new buttons which would allow members to use a payment card without going through PayPal. It looks like there‚Äôs a bit more to their integration than just pasting the button html into the payment settings. See links below.

    Is it possible to use these ‚Äėsmart payment buttons‚Äô with pdb member payments? And if so how do I set them up?

    https://www.paypal.com/buttons/smart?flowloggingId=af5718b8507af

    https://developer.paypal.com/docs/business/checkout/set-up-standard-payments/#

    • Hi Patrick,

      I will need to look into this. Any button that works with “Website Payments Standard” should work in Member Payments. That is the name of the technology the plugin uses to process the payment. If they offer a button that uses that technology, it should work.

  • Paypal payments are failing to display the return page correctly. I get a page saying “There has been a critical error on your website.”

    I have replicated the error in my test site and have generated a debug log file that I can provide.

    • Hi Peter, you can email the log to me at support@xnau.com. Please include a description of the problem in the email, thanks.

    • Peter, I think I have a fix for your problem. Go to the Manage Database Fields page and check on the Payment Log field. There should be a set of values defined in the “options” setting for that field. These options are the display columns for the log. I suspect it is blank. Try using the following setting for that and test a payment.

      payment_date::Date, payment_status::Transaction Status, txn_id::Transaction ID, mc_gross::Amount

      • The Options field contains the following content

        payment_date::Date, payment_status::Transaction Status, txn_id::Transaction ID, mc_gross::Amount, pdbmps_payment_type::Payment Type

        • OK, looks good, do you still have the problem?

        • Yes, I still have the problem. Did you get the log file I sent you?

        • I did not get a log, did you email it to support@xnau.com? The field I’m talking about is named “pdbmps_payment_log” Is that the field you’re checking the options for? The problem is due to the field being missing or misconfigured. Perhaps the log will show something different. Please clear the log, then reproduce the error and send the log to me, I don’t need to wade through lines of irrelevant entries.

  • We have a situation where we want to be able to allow 2 different membership ‘types’. So a member can subscribe as either an Individual or a Business.

    Questions:
    1. How do we ensure that each type is added into the database so that we essentially have an individual member list and a business member list? Do we have to create 2 separate forms?
    2. If we want to allow individuals to ‘Pay what they want’ each year for their membership, how would you go about setting that up properly?

    Also, does PayPal handle the recurring subscription payments or does the plugin? Can you elaborate on this a bit?

    • Hi Jesse,

      Thanks for your question, I decided to post an article that explains how to manage different price options in your payment button:

      Setting up payment options in Member Payments

      So, to answer your question specifically, you can set this up as separate forms, but it is not necessary if you want to let them choose the type of membership in the payment button.

      “Pay What You Want” requires a different type of button, so you can’t offer this in the same button that has defined payment amounts. It is possible, you just need to define a payment button that works this way.

      The plugin does not support subscription payments, so although you can set up a payment button that will initiate a subscription, the plugin does not keep track of those payments as they are made automatically.

      • Thanks Roland. Because we need to allow a ‘Pay What You Want’ option for membership, we’re going to need to setup a separate form, but we cannot see a way to do that…

        • Yes, you can define the button HTML in the shortcode so you can have a different button for that one shortcode.

          Take a look at the product FAQ under “Can I use a different PayPal button on another form?”

  • Hello again, Roland!
    Our PDB form (with Member Payments) has been giving out an “Access Denied” error from PayPal. After working for a while, suddenly it quit? Not sure if this is a PayPal issue, or something related to a WP update, or a plugin update. When the PayPal button is pressed, this is what I get:

    Access Denied.
    You don’t have permission to access “/cgi-bin/webscr” on this server.
    Reference #749862f9-188d-451a-8f62-6f24b362c069
    Timestamp: 1601570117

    Any assistance is welcome!

    • You should check your button HTML code, sounds like there is a problem there. Best thing to do is to log in to your PayPal account and check the button HTML code there to make sure the button html code setting in the plugin is correct. Might be a good idea to blank it out in the plugin setting, then re-fill it with the code provided by PayPal.

      • The same issue has happened on a site I’m looking after, was working until a few days ago, no changes from what I can see. I put the button code in again, didn’t fix it. Maybe Paypal have blacklisted the site or something? Do you suggest I contact them?

        • Hi Jackson,

          You were not blacklisted, that’s very unlikely.

          Please describe exactly what you are seeing. If you have access to your php error log, that could be helpful, but you should clear it out, then test the payment so you’re only seeing the results of that operation in the log.

        • Hi Roland,
          Thanks for coming back, I enabled WP_DEBUG and then triggered the issue.
          After clicking on the paypal button I got the same paypal error screen. I checked the logs and the only entry is this (I replaced the username with ‘hidden’):

          [16-Oct-2020 22:58:53 UTC] PHP Notice: Undefined variable: prop in /home/hidden/public_html/wp-content/plugins/pdb-member_payments/pdbmps/Events.php on line 93

          I think I’ll do a backup of the current member payments version and try a newer version to see if it resolves the issue. If there’s additional logging I should be looking at please let me know.

        • No changes after updating pdb and member payments.
          Now my error log is just showing:

          [16-Oct-2020 23:29:53 UTC] PHP Notice: Undefined index: shortcode_page in /home/*hidden*/public_html/wp-content/plugins/participants-database/participants-database.php on line 1556

        • Wait…you’re getting an error on PayPal? I though the problem happened when you came back to your site from a PayPal payment. Can you clarify this point?

          There’s nothing significant in the error log.

        • Correct it’s not after a payment, it’s when a user clicks on the paypal button to either renew their membership or when they have filled out a new membership form, after clicking on the paypal button. It’s failing on both forms but was working recently.

          For renewal if a valid email address is entered, then they select the option to pay with paypal (as opposed to the offline payments option, the button shows with payment options as I have configured it, then when you click ‘pay now’ a circular loader next to the button spins for a second and then you’re taken to https://www.paypal.com/cgi-bin/webscr with: Access Denied.
          You don’t have permission to access “/cgi-bin/webscr” on this server.

          I believe this is the same issue Victoria experienced in her post above.

        • If that is the case, make certain the button code is correct. Check it against the button code that PayPal is providing, it must match exactly. If the submitted data is not what PP is expecting, they won’t let you open the page. This is not a bug with the plugin, I’ve been testing the hell out of it, trying to see what the problem with an error on returning to the site, so I know the trip to PayPal from the website is working if the button code is correct.

        • Thanks for testing. I have created a new paypl button, and copied the new code into member payments “PayPal Button HTML” field again to see if there was an issue with the button, no luck. I pasted the button code directly into the page and tested that, this works perfectly.

          Payments are rare on this site so I have put it into sandbox mode for the moment to help debug. I have made a new page with the plain button pasted into the top and the button generated by PDB below. Since it’s in sandbox mode I suspect paypal aren’t so strict so it isn’t blocking the request now when it redirects to https://www.sandbox.paypal.com/cgi-bin/webscr, but the page does say “Error detected. PayPal cannot process this transaction because of a problem with the seller’s website.”
          Any ideas? Feel free to have a look if you like.

          http://www.aaims.org.au/test-payment/
          email address for a test payment: test4@test.net

        • If you are using the sandbox, you must use the button code provided by your sandbox account. It looks like that is the problem with your test form anyway.

          The other (non-plugin) button works fine going to the real PP site, did you have a problem with that one too?

        • The top button on the page is the same code that I have pasted into the ‘PayPal Button HTML’, I did this to see if there was something wrong with the button code, but it works fine. So it seems there is nothing wrong with the button code, just that it’s not working when it’s firing from the PDB generated button.

          Sorry about that with the sandbox button code, I created a new paypal button in the sandbox account and have updated the button code and now the PDB sandbox generated button works perfectly, no errors, correct amount showing in paypal sandbox.

          So the sandbox button from PDB on the page works perfectly, but when I turn member payments off sandbox mode, the PDB generated button fails again. The code in the ‘PayPal Button HTML’ field is exactly the same as what works on the page directly so I’m not sure what’s going on there.

          I tried turning off PDT in paypal to see if it would refresh my identity token, but it always gives me the same one, so I don’t think that’s the issue either.

        • I found the issue: PayPal upped their security on their main site, but not sandbox, so I didn’t see the problem until I started testing the main site. Even then the error was inconsistently shown, and no clue as to the exact reason (well it’s a security feature, so no surprise there). Nevertheless, I acted on a hunch as to what the problem was and I managed to fix it. The new version of Member Payments should get you hooked up again.

        • Fantastic! That makes sense. Thanks so much for the support and persistance on this Roland. I can confirm it’s working now =)

  • I am using the generate member id add on and have had a strange event on each of the last 3 days where a new sign up has not been allocated a new member-id but given one that already belongs to someone else.

    The new sign up receives payment confirmation via the pdb_signup_member_payment_thanks page and notification emails but the payment is credited to someone else’s record. No new record is created.

    This does not happen for every signup. On Sep 6th it happened to 1 out of 4, on the 7th it was 1 out of 2 and to-day just 1 so far. The only pattern I can see is that the member ids affected are sequential ‚Äď 2084, 2085, 2086.

    Nothing like this has happened before and I can neither understand nor explain what is going wrong. Please can you help?

    • Also, I should have said, when I add the records manually in the back end the new id number is allocated correctly.

    • Probably server or page caching. Make sure these types of caching are not active on pages with Participants Database forms.

      • Hi Roland. I checked the server caching and it’s not that. It has been OK for a couple of days but it just happened again and allocated 2087 this time. Do you have any other ideas?

        • How about if I change the start value in the generate member id add on to what it should be? Would that cause any problems?

        • So…is the problem that a new record is not created… or is it that a new record is created, but it does not have a unique id?

          Either way, I don’t see an immediate rerason for the problem. Caching is a good place to start with problems like this, but it it’s not that, then you need to set up your php error log so you can catch any errors that are coming up.

        • Another thought: look at the configuration on your signup for with regard to matching records. Make sure you don’t have it set to look for a matching ID, then update the matching record.

  • Hello Roland! I am adding Member Payments to our website, and we are going to allow offline payments. For some reason, the form I created defaults to the offline payment radio button. Is there any way I can make the form default to the online option? I don’t see it in the settings anywhere. Thanks!

    • This is done on the Manage Database Fields page. You’re looking for the radio button field that provides the selector in the form. It will be named ‘pdbmps_payment_type’

      Set the default value of that field to what you want the default selection to be.

Got a Support Question?

You have to agree to the comment policy.

Would you like to be notified of followup comments via e-mail? You can also subscribe without commenting.