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 ( |
2.2. Membership Parameters
| Parameter | Description |
|---|---|
Membership Type |
The type of membership being offered |
Membership Period |
The validity period, with |
Membership Criteria |
The pricing criteria (age, gender, type selector) within the period |
Products |
The WooCommerce Products linked via |
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.
Navigate to the Registration Portal admin and verify the Tenant record exists with the correct domain field.
-- 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;
-
Exactly one row is returned.
-
The
domainmatches the expected hostname. -
The
registration_system_idis 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.
-- 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;
-
One row is returned.
-
The
organisationmatches the expected Organisation. -
The
base_urlpoints to the WordPress WooCommerce REST API endpoint (typically ending in/wp-json/payment-api/v1). Required whenpayment_methodsincludesO(Online). May be null for Manual-only systems. -
The
typeisWPfor WordPress-based registration systems. -
payment_methodsis configured (see 2a: Verify Payment Methods). -
auth_keyis not null and matches the WordPress plugin’s Callback API Key. Required whenpayment_methodsincludesO(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 |
|---|---|---|
|
Online |
Payment via WooCommerce payment gateway. Requires a configured payment processor. |
|
EFT |
Electronic Funds Transfer. Requires banking details configured on the Registration System ( |
|
Manual |
Pay-at-counter. Generates a reference code for manual reconciliation. |
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;
-
payment_methodsis 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.
| Tenant Hostname | Registration System | Payment Methods | Description |
|---|---|---|---|
|
HNR |
|
Credit card payments via WooCommerce gateway |
|
HNR VC |
|
Pay-at-counter with reference code for manual reconciliation |
-
Each Tenant resolves to exactly one Registration System via
registration_system_id. -
Multiple Registration Systems may reference the same Organisation.
-
The
payment_methodsvalue determines the checkout options presented to the user. -
Registration Systems configured with only
M(Manual) do not requirebase_urlorauth_key, as no external payment gateway is involved. -
Registration Systems configured with
O(Online) requirebase_urlandauth_keyfor the WooCommerce payment plugin callback. -
Registration Systems configured with
E(EFT) require banking detail columns (bank_name,account_name,account_number,branch_code).
-- 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.
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 |
Callback API Key |
Auto-generated key used by admin-service |
Must match the |
Default Product |
A valid WooCommerce product ID |
Must exist as a published WooCommerce product |
3.3.3. 3c: Verify API Connectivity
-
Click the Test Connection button on the plugin settings page.
-
Confirm the success message indicating connectivity to admin-service.
-
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.
SELECT rs.id, rs.name, rs.auth_key, rs.base_url
FROM registration_system rs
WHERE rs.id = :registration_system_id;
-
The
auth_keymatches the Callback API Key displayed in the WordPress plugin settings. -
The
base_urlmatches 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.
# 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
-
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.
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;
-
The expected Membership Type(s) exist for the Organisation.
-
The
enrol_process_idis not null (links to a ProcessDefinition). -
The
cross_sell_membership_type_idis 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).
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;
-
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.
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;
-
A period exists matching the expected date range.
-
enrol_process_idis set if the period overrides the type-level process. -
default_criteria_idis 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.
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;
-
Each criteria has a linked Product (
product_idis not null). -
Each Product has an
external_idthat maps to a WooCommerce product. -
The
pricematches the expected membership fee. -
Age ranges (
min_age,max_age),gender, andtype_selectorare correctly configured.
4.5. Step 10: Verify WooCommerce Products
For each Product linked to a Membership Criteria, confirm the corresponding WooCommerce product exists.
For each external_id from Step 9:
-
Log in to the WordPress admin at the configured WordPress site URL.
-
Navigate to Products and search for the product by ID.
-
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).
-
-- 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';
-
Each
external_idmaps 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.
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;
-
The ProcessDefinition exists and has type
M(Membership). -
Steps are ordered by
seqand match the expected form questions. -
Each step has the correct
typecode (e.g.,TXTfor text input,DRPfor dropdown,CHKfor checkbox,INDfor 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.
-- 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;
-
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) |