Website and Membership Configuration Validation

1. Overview

This document defines the validation procedures required to confirm that a Registration Portal tenant and its associated Membership configuration are correctly set up. The validation covers:

  • Registration Website — Tenant hostname, Registration System, Organisation linkage, and WordPress plugin configuration.

  • Membership — Membership Type, Period, Criteria, Products, cross-sell linkage, and enrolment process steps.

These procedures serve as both manual validation checklists and requirements for automated validation in admin-service.

2. Parameters

Before starting validation, gather the following configuration parameters.

2.1. Registration Website Parameters

Parameter Description

Tenant Hostname

The DNS hostname configured in the Registration Portal

Organisation

The Organisation entity that owns the Registration System

WordPress Site URL

The WordPress site hosting the WooCommerce payment plugin

Expected Plugin Version

The version of the Event Payment Plugin for WooCommerce expected to be deployed

Payment Methods

The payment method codes configured on the Registration System (O, E, M, or a combination)

2.2. Membership Parameters

Parameter Description

Membership Type

The type of membership being offered

Membership Period

The validity period, with validFrom and validTo dates

Membership Criteria

The pricing criteria (age, gender, type selector) within the period

Products

The WooCommerce Products linked via external_id to each criteria

Cross-sell Type

The Membership Type linked for cross-selling

Enrolment Process

The ProcessDefinition driving the registration portal form questions

3. Registration Website Validation

3.1. Step 1: Verify Tenant Exists

Confirm that the Registration Portal has a Tenant record matching the expected hostname.

Manual Check

Navigate to the Registration Portal admin and verify the Tenant record exists with the correct domain field.

SQL Verification
-- Run on the registration-portal database via the mysql-client pod in the mysql namespace
SELECT t.id, t.name, t.domain, t.registration_system_id,
       t.issuer_url, t.client_id, t.theme
FROM tenant t
WHERE t.domain = :hostname;
Expected Result
  • Exactly one row is returned.

  • The domain matches the expected hostname.

  • The registration_system_id is not null.

3.2. Step 2: Verify Registration System

Using the registration_system_id from Step 1, confirm the Registration System exists and is correctly configured.

SQL Verification
-- Run on the admin-service database via the mysql-client pod in the mysql namespace
SELECT rs.id, rs.name, rs.type, rs.base_url, rs.auth_key, rs.payment_methods,
       o.id AS org_id, o.name AS org_name
FROM registration_system rs
JOIN organisation o ON rs.organisation_id = o.id
WHERE rs.id = :registration_system_id;
Expected Result
  • One row is returned.

  • The organisation matches the expected Organisation.

  • The base_url points to the WordPress WooCommerce REST API endpoint (typically ending in /wp-json/payment-api/v1). Required when payment_methods includes O (Online). May be null for Manual-only systems.

  • The type is WP for WordPress-based registration systems.

  • payment_methods is configured (see 2a: Verify Payment Methods).

  • auth_key is not null and matches the WordPress plugin’s Callback API Key. Required when payment_methods includes O (Online). May be null for Manual-only systems.

3.2.1. 2a: Verify Payment Methods

The payment_methods column stores a comma-separated list of payment method codes. Valid codes are:

Code Method Description

O

Online

Payment via WooCommerce payment gateway. Requires a configured payment processor.

E

EFT

Electronic Funds Transfer. Requires banking details configured on the Registration System (bank_name, account_name, account_number, branch_code).

M

Manual

Pay-at-counter. Generates a reference code for manual reconciliation.

SQL Verification
SELECT rs.id, rs.name, rs.payment_methods,
       rs.bank_name, rs.account_name, rs.account_number, rs.branch_code
FROM registration_system rs
WHERE rs.id = :registration_system_id;
Expected Result
  • payment_methods is not null and contains at least one valid code.

  • If E (EFT) is included, banking details columns must be populated.

  • The available payment methods determine what options the registration portal presents to the user during checkout.

3.2.2. 2b: Multi-Tenant Payment Method Configuration

When the same Organisation requires different payment methods for different audiences, create a separate Registration System for each payment configuration. Each Registration System is linked to the same Organisation but has its own payment_methods value, and each is referenced by a distinct Tenant with a unique hostname.

Table 1. Example: Organisation with Credit Card and Pay-at-Counter tenants
Tenant Hostname Registration System Payment Methods Description

hnr.example.com

HNR

O

Credit card payments via WooCommerce gateway

hnr-vc.example.com

HNR VC

M

Pay-at-counter with reference code for manual reconciliation

Key rules
  • Each Tenant resolves to exactly one Registration System via registration_system_id.

  • Multiple Registration Systems may reference the same Organisation.

  • The payment_methods value determines the checkout options presented to the user.

  • Registration Systems configured with only M (Manual) do not require base_url or auth_key, as no external payment gateway is involved.

  • Registration Systems configured with O (Online) require base_url and auth_key for the WooCommerce payment plugin callback.

  • Registration Systems configured with E (EFT) require banking detail columns (bank_name, account_name, account_number, branch_code).

SQL Verification
-- Verify all Registration Systems for an Organisation and their Tenants
SELECT t.domain, rs.name AS registration_system, rs.payment_methods,
       o.name AS organisation
FROM registration_system rs
JOIN organisation o ON rs.organisation_id = o.id
LEFT JOIN tenant t ON t.registration_system_id = rs.id
WHERE o.name = :organisation_name
ORDER BY t.domain;
This query must be run as a cross-database join or as two separate queries — tenant is in the registration-portal database and registration_system is in the admin-service database. The registration_system_id foreign key on tenant references the registration_system.id in the admin-service database by convention (shared ID space), not by a database-level constraint.

3.2.3. 2c: Legacy Registration Flow

Tenants using the legacy /register route (e.g., WCSC) do not enforce payment_methods during session creation. Payment method configuration is only evaluated during order checkout via the PaymentResource endpoint. For legacy tenants, payment_methods may be set proactively for when they migrate to the new flow.

3.3. Step 3: Verify WordPress Plugin Configuration

Confirm that the Event Payment Plugin for WooCommerce is correctly installed and configured on the WordPress site.

3.3.1. 3a: Verify Plugin Version

Check that the expected version of the plugin is deployed.

Manual Check

Log in to the WordPress admin panel at the configured WordPress site URL. Navigate to Plugins > Installed Plugins and locate "Event Payment Plugin for WooCommerce". Verify the version number matches the expected plugin version.

3.3.2. 3b: Verify Plugin Settings

Navigate to Settings > Event Payment API in the WordPress admin.

Setting Expected Value Verification

Admin API URL

The admin-service URL for the target environment

Must be reachable from WordPress

Admin API Key

A valid API key for the admin-service

Use Test Connection button to verify

Entry Portal URL

The Registration Portal URL matching the tenant hostname

Must match Tenant domain with correct protocol

Callback API URL

Auto-generated WordPress REST endpoint

Read-only; verify it ends with /wp-json/payment-api/v1/order/event/create/

Callback API Key

Auto-generated key used by admin-service

Must match the auth_key in the Registration System record

Default Product

A valid WooCommerce product ID

Must exist as a published WooCommerce product

3.3.3. 3c: Verify API Connectivity

  1. Click the Test Connection button on the plugin settings page.

  2. Confirm the success message indicating connectivity to admin-service.

  3. If the test fails, verify:

    • The Admin API URL is correct and accessible.

    • The Admin API Key is valid.

    • Network connectivity exists between WordPress and admin-service.

3.4. Step 4: Verify Registration System Callback Credentials

The Registration System record in admin-service must have credentials that match the WordPress plugin’s callback configuration.

SQL Verification
SELECT rs.id, rs.name, rs.auth_key, rs.base_url
FROM registration_system rs
WHERE rs.id = :registration_system_id;
Expected Result
  • The auth_key matches the Callback API Key displayed in the WordPress plugin settings.

  • The base_url matches the Callback API URL displayed in the WordPress plugin settings.

3.5. Step 5: Verify Kubernetes Deployment (Stage)

For the stage environment, verify that the Registration Portal and admin-service are correctly deployed.

K8s Verification
# Use the appropriate kubeconfig for the target environment
export KUBECONFIG=/path/to/kubeconfig.yaml

# Verify Registration Portal deployment in the target namespace
kubectl -n <namespace> get deployment registration-portal

# Verify admin-service deployment
kubectl -n <namespace> get deployment admin-service

# Check ingress or service for the tenant hostname
kubectl -n <namespace> get ingress -o wide
Expected Result
  • Both deployments show the expected number of ready replicas.

  • An ingress rule routes the tenant hostname to the registration-portal service.

3.6. Website Validation Summary

At the end of website validation, confirm and document:

Item Value

Tenant Hostname

(verified hostname)

Tenant ID

(from database)

Registration System ID

(linked to tenant)

Organisation

(name and ID)

Payment Methods

(configured codes: O, E, M)

WordPress Site URL

(verified URL, or N/A for Manual-only)

Plugin Version

(verified version, or N/A for Manual-only)

API Connectivity

Pass / Fail

K8s Deployment

Pass / Fail

4. Membership Validation

4.1. Step 6: Verify Membership Type

Confirm the Membership Type exists and is linked to the correct Organisation.

SQL Verification
SELECT mt.id, mt.name,
       o.id AS org_id, o.name AS org_name,
       mt.enrol_process_id,
       mt.cross_sell_membership_type_id
FROM membership_type mt
JOIN organisation o ON mt.organisation_id = o.id
WHERE o.name = :organisation_name
ORDER BY mt.name;
Expected Result
  • The expected Membership Type(s) exist for the Organisation.

  • The enrol_process_id is not null (links to a ProcessDefinition).

  • The cross_sell_membership_type_id is set where applicable.

4.2. Step 7: Verify Cross-Sell Linkage

Confirm the cross-sell relationship between Membership Types (e.g., Annual linked to Early Riser).

SQL Verification
SELECT mt.id, mt.name AS membership_type,
       cs.id AS cross_sell_id, cs.name AS cross_sell_type
FROM membership_type mt
LEFT JOIN membership_type cs ON mt.cross_sell_membership_type_id = cs.id
WHERE mt.organisation_id = :organisation_id
ORDER BY mt.name;
Expected Result
  • The expected cross-sell relationship exists between the specified Membership Types.

  • The linkage direction (one-directional or bidirectional) matches the expected configuration.

4.3. Step 8: Verify Membership Period

Confirm the Membership Period exists for the correct type, with valid date ranges.

SQL Verification
SELECT mp.id, mp.name, mp.valid_from, mp.valid_to,
       mt.name AS membership_type,
       mp.enrol_process_id,
       mp.default_criteria_id
FROM membership_period mp
JOIN membership_type mt ON mp.membership_type_id = mt.id
WHERE mt.organisation_id = :organisation_id
  AND mp.valid_from >= :period_start
ORDER BY mt.name, mp.valid_from;
Expected Result
  • A period exists matching the expected date range.

  • enrol_process_id is set if the period overrides the type-level process.

  • default_criteria_id is set if a default criteria applies.

4.4. Step 9: Verify Membership Criteria and Products

Confirm each criteria within the period is linked to the correct Product.

SQL Verification
SELECT mc.id, mc.name AS criteria_name,
       mc.min_age, mc.max_age, mc.gender, mc.type_selector,
       p.id AS product_id, p.name AS product_name,
       p.external_id, p.price, p.sales_price
FROM membership_criteria mc
JOIN membership_period mp ON mc.period_id = mp.id
JOIN membership_type mt ON mp.membership_type_id = mt.id
LEFT JOIN product p ON mc.product_id = p.id
WHERE mt.organisation_id = :organisation_id
  AND mp.name = :period_name
ORDER BY mc.name;
Expected Result
  • Each criteria has a linked Product (product_id is not null).

  • Each Product has an external_id that maps to a WooCommerce product.

  • The price matches the expected membership fee.

  • Age ranges (min_age, max_age), gender, and type_selector are correctly configured.

4.5. Step 10: Verify WooCommerce Products

For each Product linked to a Membership Criteria, confirm the corresponding WooCommerce product exists.

Manual Check

For each external_id from Step 9:

  1. Log in to the WordPress admin at the configured WordPress site URL.

  2. Navigate to Products and search for the product by ID.

  3. Verify:

    • The product exists and is published.

    • The product price matches the EMS Product price.

    • The product is set to the correct type (Simple Product).

SQL Verification (WooCommerce database)
-- Run on the WordPress database
SELECT p.ID, p.post_title, p.post_status,
       pm_price.meta_value AS price,
       pm_sale.meta_value AS sale_price
FROM wp_posts p
LEFT JOIN wp_postmeta pm_price ON p.ID = pm_price.post_id AND pm_price.meta_key = '_price'
LEFT JOIN wp_postmeta pm_sale ON p.ID = pm_sale.post_id AND pm_sale.meta_key = '_sale_price'
WHERE p.ID IN (:external_ids)
  AND p.post_type = 'product';
Expected Result
  • Each external_id maps to a published WooCommerce product.

  • Prices are consistent between the EMS Product and the WooCommerce product.

4.6. Step 11: Verify Enrolment Process Definition

Confirm the ProcessDefinition linked to the Membership Type (or Period) contains the expected form questions.

SQL Verification
SELECT pd.id, pd.name AS process_name, pd.type,
       ps.id AS step_id, ps.seq, ps.name AS step_name,
       ps.type AS step_type, ps.description,
       ps.jhi_require AS required,
       ps.person_data_key,
       ps.skip_if_set,
       ps.list_options
FROM process_definition pd
JOIN process_step ps ON ps.definition_id = pd.id
WHERE pd.id = :enrol_process_id
ORDER BY ps.seq;
Expected Result
  • The ProcessDefinition exists and has type M (Membership).

  • Steps are ordered by seq and match the expected form questions.

  • Each step has the correct type code (e.g., TXT for text input, DRP for dropdown, CHK for checkbox, IND for indemnity).

  • Required steps have require = true.

4.7. Step 12: Verify Process Resolves from Membership Type

Confirm that the enrolment process is reachable from the Membership Type, either directly or via the Period.

SQL Verification
-- Check type-level process
SELECT mt.id, mt.name, mt.enrol_process_id AS type_process_id,
       pd.name AS type_process_name
FROM membership_type mt
LEFT JOIN process_definition pd ON mt.enrol_process_id = pd.id
WHERE mt.id = :membership_type_id;

-- Check period-level override
SELECT mp.id, mp.name, mp.enrol_process_id AS period_process_id,
       pd.name AS period_process_name
FROM membership_period mp
LEFT JOIN process_definition pd ON mp.enrol_process_id = pd.id
WHERE mp.membership_type_id = :membership_type_id;
Expected Result
  • At least one of the Membership Type or Period has a non-null enrol_process_id.

  • If both have a process, the Period-level process takes precedence at runtime.

4.8. Membership Validation Summary

At the end of membership validation, confirm and document:

4.8.1. Membership Type Summary

Item Value

Membership Type

(name and ID)

Organisation

(name and ID)

Cross-sell Target

(linked type name and ID, or N/A)

Enrolment Process

(process name and ID)

4.8.2. Membership Period Summary

Item Value

Period Name

(name)

Valid From

(date)

Valid To

(date)

Default Criteria

(criteria name and ID, or N/A)

Process Override

(process name and ID, or inherited from type)

4.8.3. Membership Criteria and Product Summary

Criteria Age Range Gender Product Price WooCommerce ID

(name)

(min - max)

(M/F/Any)

(product name)

(price)

(external_id)

4.8.4. Enrolment Process Steps Summary

Seq Step Name Description Type Required

1

(name)

(description)

(type code)

Yes/No