The Brightwork WordPress Membership in Process Design

ByPrimary Researcher

Executive Summary

  • This is our in process design for WordPress membership software.

Introduction

These requirements described a custom development requirement for a membership functionality for the WordPress content management/publishing application. 

Three Components

There are three major components to this development.  

  1. Authorization (currently thought to be applied leveraging an OAuth online application).
  2. A custom membership application or MA, that stores data, and serves as a lookup for the OAuth for whether to grant access to articles.   
  3. Integration with Stripe for enabling subscription payments.

The activity and purpose of each component is as follows: 

  1. Authorization controls the connection between the user credentials and specific page access (every page will have an association with a membership plan, and every user an association to a membership plan).
  2. The membership application is the repository for the associations of the overall solution.  
  3. The integration with Stripe allows the members to be charged for access to the site. 

Some of the major data elements are kept in a Google Sheet, which will provide an example data set for the membership application.

Each area of data, or screen will be a different tab in this Google Sheet. The data that is contained in the various sheets is described as follows. 

Google Tab #1: The Membership Plan Table

List membership plans, price, and charging periodicity per plan.

Google Tab #2: The Member Table

List members, membership plans, and membership groups.

Google Tab #3: Partial Page Display Setting Table

Entry for the number of characters from the top of the article to show to readers, that are not members.

Google Tab #4: Protected Pages to Plan Association Table

A page that allows links to be protected, and assigned to various membership plans.

Now that we have the tables defined, we will define the screens. There are only a few screens required. One is the login screen, which also serves to protect all of the pages on the website, as well as a member profile screen, that allows the member to manage their own member profile, subscription, etc..

Password reset by AWS Cognito.

Login screen by AuthO.

Password reset by AuthO. 

Google Tab #5: Login Screen: Embeddable Login Window

Either this login screen/window launches from a button on the website, or just launches when the individual scrolls down.

  • Has a password change option button.

Google Tab #6: Member Profile Screen:

  • Allows members to cancel membership.
  • Allows members to change passwords.
  • Shows the member their plan and their monthly or yearly charge as well as their billing history.

Both screens should be mocked up.

Stripe Billing

AuthO would have to be integrated with Stripe billing service.

Messaging/Emails

Allows emails to be sent for notification of joining successfully, canceling, changing password notification, lost password.

Email can be taken care of with AWS Cognito or AuthO. 

Emails work right from within AuthO. 

General Requirements

  • Allow all content, protected or not protected to be indexed by Google.
  • Multisite compatible.
  • Have member management independent and without in any way leveraging the standard WP user functionality. (Member management would be one main screen)
  • Allow all content, protected or not protected to be indexed by Google.
  • AuthO allows authentication to be placed in front of WP, rather than within WP.

Open Questions

Question #1: How will the design interoperate with OAuth and Google Cloud Identity and Access Management? (IAM) or Amazon Cognito? 

Leverage Cloud Identity, Google Cloud’s built-in managed identity to easily create or sync user accounts across applications and projects. It’s easy to provision and manage users and groups, set up single sign-on, and configure two-factor authentication (2FA) directly from the Google Admin Console. You also get access to the Google Cloud Organization, which enables you to centrally manage projects via Resource Manager. – Google Cloud 

Question #2: How Can AuthO be integrated to Stripe? 

This topic is covered in the article An Analysis of the Best Ways to Integrate Memberships to Stripe.

Question #3: Where Should the Custom Membership Developed Application Kept? 

As AuthO is on AWS, one option is to place it out at AWS as well. 

Go to top

Conclusion

These requirements are in flux.

But to break down the requirements into categories it looks like the following.

  1. Authentication/security provided by AuthO.
  2. Protected Articles/Members/etc.. provided by custom membership application (or the MA)
  3. Payments through Stripe — which integrates with AuthO and with MA.