CSA Integration

1. Overview

The Event Registration workflow integrates with Cycling South Africa (CSA) to validate rider membership and racing licenses. This validation is performed via three sequential FormField types during the registration question workflow:

StepCode FormField Class Purpose

CSI

CsaIdentificationFormField

Capture CSA membership number and identification details — only from riders who are not already resolvable (see Rule: Conditional prompt)

CSM

CsaMembershipCheckFormField

Validate CSA membership status via CSA external API

CSL

CsaLicenseCheckFormField

Validate CSA racing license via CSA external API

These steps form a dependent chain: CSI captures the identifier, CSM validates membership using that identifier, and CSL validates the racing license.

2. ProcessData Flow

The CSA steps follow the standard ProcessData staging pattern. Each step reads data from prior steps and stores its result:

Step Reads From Stores

CSI

(user input)

CSA membership number, ID number, ID country

CSM

CSI ProcessData (CSA number or ID number)

Membership validation result, CSA member ID, membership status

CSL

CSI ProcessData (CSA number or ID number)

License validation result, membership status, license status

Both CSM and CSL gate form progression — the participant cannot advance to the next question if validation fails, unless an alternative action is chosen (day license, defer, exempt).

3. CSA API

The CSA API is hosted by Cycling South Africa at cyclingsa-events.co.za. It provides two endpoints for checking a rider’s membership and racing license status.

Official API documentation: https://documenter.getpostman.com/view/28907025/2sAYdkFoEm

This section documents the v1 API surface, retained for the legacy WordPress plugin and historical batch back-fills (club / team-roster enrichment). admin-service’s CsaApiClient now uses the v2 API — see CSA API V2 (current — used by admin-service). The same API key works on both; only the transport and response shape change.

3.1. Authentication

Authentication is via an API key passed in the JSON request body (not as an HTTP header).

Parameter Description

key

A unique API key assigned to the organisation. Must be included in every request body.

The API key must be stored as an application property (csa.api.key), never hardcoded.

3.2. Base URL

https://www.cyclingsa-events.co.za/api/v1/exec.php

3.3. Endpoints

3.3.1. Check Membership Status

Checks whether a rider has an active CSA membership on a given date.

URL: ?c=Member&fn=checkMembershipStatus

Method: POST

Content-Type: application/json

Request body:

{
  "key": "<API_KEY>",
  "idNumber": "8501015009086",
  "date": "2026-06-15"
}
Field Type Description

key

String (required)

API authentication key

idNumber

String (conditional)

South African ID number. Much better suited for ZA citizens as it is a unique national identifier. Cannot be used for foreign riders.

csaId

String (conditional)

CSA’s internal member reference number. Can be used for any rider (local or foreign), but idNumber is preferred for ZA citizens.

date

String (optional)

Date to check in YYYY-MM-DD format. Defaults to current date if omitted.
Either idNumber or csaId must be provided. When the person’s ID country is ZA and an ID number is available, prefer idNumber as it is the stronger identifier. For foreign riders, csaId is the only option.

Response body:

{
  "ok": true,
  "memberFound": true,
  "active": true,
  "date": "2026-06-15"
}
Field Type Description

ok

Boolean

true if the API call executed successfully. false if an error occurred.

error

String

Error description. Only present when ok is false.

memberFound

Boolean

true if the rider was found on the CSA system.

active

Boolean

true if the rider has an active membership on the given date.

date

String

The date that was checked (YYYY-MM-DD).

3.3.2. Check Racing License Status

Checks the rider’s membership status AND racing license status in a single call. This is the more comprehensive endpoint.

URL: ?c=Member&fn=checkRacingLicenceStatus

Method: POST

Content-Type: application/json

Request body: Same structure as membership check.

{
  "key": "<API_KEY>",
  "idNumber": "8501015009086",
  "date": "2026-06-15"
}

Response body:

{
  "ok": true,
  "memberFound": true,
  "memberCsaId": "12345",
  "membershipStatus": "ACTIVE",
  "licenceStatus": "ACTIVE",
  "date": "2026-06-15"
}
Field Type Description

ok

Boolean

true if the API call executed successfully.

error

String

Error description. Only present when ok is false.

memberFound

Boolean

true if the rider was found on the CSA system.

memberCsaId

String

The CSA ID of the cyclist (returned by CSA, useful for cross-referencing).

membershipStatus

String

Membership status on the given date (see status codes below).

licenceStatus

String

Racing license status on the given date (see status codes below).

date

String

The date that was checked (YYYY-MM-DD).

3.4. Status Codes

3.4.1. Membership Status Values

Value Meaning

ACTIVE

The cyclist has an active membership on the checked date.

EXPIRED

The cyclist’s membership has expired.

SUSPENDED

The cyclist’s membership is suspended.

NONE

The cyclist is not a CSA member.

NO MEMBERSHIP

The cyclist is not a CSA member (alternative phrasing of NONE).

3.4.2. License Status Values

Value Meaning

ACTIVE

The cyclist has an active racing license on the checked date.

INACTIVE

The license is inactive. This occurs when the cyclist has a racing license but their membership has expired — the license becomes inactive because it depends on active membership.

SUSPENDED

The cyclist’s racing license has been suspended.

NONE

The cyclist does not have a racing license.

NO LICENSE

The cyclist does not have a racing license (alternative phrasing of NONE).

The INACTIVE license status is distinct from EXPIRED. An INACTIVE license means the underlying membership has lapsed, making the license inactive even though the license itself has not expired. Renewing the membership would reactivate the license.

3.5. Key API Observation

The checkRacingLicenceStatus endpoint returns both membership and license status in a single response. The legacy implementation exploits this by calling only checkRacingLicenceStatus for both the membership check and the license check. This avoids making two separate API calls.

The new Java implementation no longer uses these v1 function endpoints. See CSA API V2 (current — used by admin-service) below, which the CsaApiClient now targets.

4. CSA API V2 (current — used by admin-service)

CSA introduced a v2 API that supersedes the v1 surface above. admin-service’s CsaApiClient uses v2. The same API key works on both APIs unchanged — only the transport and response shape differ.

4.1. Base URL and Endpoints

https://www.cyclingsa-events.co.za
Endpoint Method Purpose

/api/v2/members/status

POST

Single call returning membership, racing-licence, day-licence, UCI and geographic/club data.

/api/v2/day_licenses

POST

Create a day licence for a rider at a CSA event.

4.2. Authentication

For /api/v2/members/status the API key is sent in the Authorization HTTP header (v1 sent it in the body). For /api/v2/day_licenses the key is sent in the request body (key), as in v1 — this asymmetry is intentional on the CSA side.

4.3. Member Status Request

POST /api/v2/members/status with Authorization: <API_KEY> and Content-Type: application/json. Field names are snake_case.

{
  "csa_id": "12345",
  "id_number": "8501015009086",
  "csa_event_id": "<event-uuid>",
  "date": "2026-06-15"
}
Field Type Description

id_number

String (conditional)

SA ID number. Preferred for ZA citizens (stronger identifier).

csa_id

String (conditional)

CSA member reference. The only option for foreign riders.

csa_event_id

String (optional)

CSA’s id for the event the check is for, taken from event.csa_event_id (ADO #877). Omitted when the event has none, and outside an event flow (membership registration).

date

String (optional)

Check date (YYYY-MM-DD). Defaults to today. Use the event start date.

At least one of id_number / csa_id must be provided.

4.4. Member Status Response

{
  "member_found": true,
  "member_csa_id": "12345",
  "membership_status": true,
  "racing_license_status": true,
  "day_license_status": false,
  "csa_id_match_member_record_id_number": true,
  "uci_id": "10017823025",
  "uci_code": "RSA12345",
  "uci_category": "Master Men 45-49",
  "date": "2026-06-15",
  "country": { "id": "...", "name": "SOUTH AFRICA" },
  "region":  { "id": "...", "name": "Gauteng" },
  "city":    { "id": "...", "name": "..." },
  "club":    { "id": "<uuid>", "name": "..." }
}
Field Type Description

member_found

Boolean

Rider exists on the CSA system.

member_csa_id

String

The rider’s CSA ID. Persist this for future lookups when the rider was found by SA ID.

membership_status

Boolean

true if membership is active on the check date (v1 returned a string).

racing_license_status

Boolean

true if the racing licence is active on the check date.

day_license_status

Boolean

Whether a day licence already exists / is applicable for the rider.

csa_id_match_member_record_id_number

Boolean

Trust signal. true when the supplied csa_id’s member record carries the supplied `id_number. When false, the result must NOT be trusted as the right person — require correction or an admin override.

uci_id / uci_code / uci_category

String

UCI enrichment.

country / region / city / club

Object {id,name}

Geographic and club affiliation. The nested club drives the WPCA club / team-roster back-fill runbooks.

4.5. Deriving the internal status from v2 booleans

v2 collapses v1’s string status codes into booleans. admin-service derives its internal CsaCheckStatus as follows:

Condition Internal status

member_found = false

NOT_FOUND

membership_status = true

membership ACTIVE

membership_status = false (member found)

membership EXPIRED

racing_license_status = true

licence ACTIVE

racing_license_status = false AND membership_status = false

licence INACTIVE (membership lapse deactivated the licence)

racing_license_status = false AND membership_status = true

licence EXPIRED

(HTTP / connection error)

OFFLINE

4.6. Day Licence Creation

POST /api/v2/day_licenses with the key in the body:

{ "key": "<API_KEY>", "csa_id": "12345", "event_id": "<event-uuid>" }

Returns the created day-licence id, validity dates, and price. The day licence should be issued after the participant’s payment is confirmed, not at form completion.

event_id is the csa_event_id of the participant’s event (ADO #877). There is no global fallback: CSA’s event id identifies one specific race, so a deployment-wide value would issue every licence against the same event. An event with no CSA event id gets no licence — see the lifecycle in Rule: Day License.

4.7. V1 to V2 mapping

Aspect V1 V2

Endpoint(s)

exec.php?c=Member&fn=checkMembershipStatus and …&fn=checkRacingLicenceStatus

single /api/v2/members/status

Auth

key in JSON body

Authorization header (members/status); key in body (day_licenses)

Field case

camelCase (idNumber, csaId)

snake_case (id_number, csa_id)

Status type

Strings (ACTIVE, EXPIRED, NONE…)

Booleans (membership_status, racing_license_status)

Enrichment

none

UCI ids, country/region/city/club, ID-number match flag

5. Java Implementation: CsaApiClient

The CsaApiClient Spring service in admin-service implements the CSA v2 integration (see CSA API V2 (current — used by admin-service)). It supports a mock mode (csa.api.mock=true, the default) for development/testing and real v2 calls when mock=false. The request factory is pinned to Apache HttpClient5 to avoid a JDK HttpClient connection-reuse race.

5.1. Configuration Properties

Property Default Description

csa.api.base-url

https://www.cyclingsa-events.co.za

CSA API host (the client appends /api/v2/…​ paths)

csa.api.key

(none — required)

API authentication key (Authorization header for /members/status; body for /day_licenses)

csa.api.timeout

10000

HTTP request timeout in milliseconds

csa.api.mock

true

Use mock responses for development/testing

There is deliberately no csa.api.csa-event-id. CSA’s event id belongs to each event and is set on event.csa_event_id — for now over REST with PATCH /api/events/{id} (csaEventId), until an event setup screen exists (ADO #877). The former global property was blank in every environment and has been removed.

5.2. Implementation Notes

  1. HTTP client: Use Spring RestTemplate or WebClient to POST JSON to the CSA API.

  2. Request construction: Build a JSON object with csa_id or id_number, and date (snake_case). Add csa_event_id only when the event being registered for has one (event.csa_event_id); omit it when the event has none and in membership registration, which has no event. The API key goes in the Authorization header for /members/status (in the body for /day_licenses).

  3. SSL: The legacy implementation disables SSL verification. The new implementation must NOT disable SSL verification. If certificate issues arise, add the CSA certificate to the Java truststore.

  4. Error handling:

    • cURL/HTTP errors → return CsaMembershipResponse.offline() or CsaLicenseResponse.offline()

    • ok=false in response → log the error message, return offline status

    • memberFound=false → return NOT_FOUND status

  5. Lookup preference: When the person’s ID country is ZA and an ID number is available, send idNumber (stronger identifier). For foreign riders, send csaId (the only option). Both can be used for any rider, but idNumber is preferred for ZA citizens.

5.3. Suggested CsaApiClient Method Signatures

/**
 * Check membership status using the checkMembershipStatus endpoint.
 * Use when only membership status is needed.
 */
public CsaMembershipResponse checkMembership(String idNumber, String csaId, LocalDate date);

/**
 * Check both membership and license status using checkRacingLicenceStatus.
 * Preferred method -- returns both statuses in one call.
 */
public CsaLicenseResponse checkLicense(String idNumber, String csaId, LocalDate date);

6. Validation Workflow

6.1. Business Rules Hierarchy

CSA requirements are determined at two levels, with category overriding event:

csa-requirement-hierarchy

6.1.1. Rule: License Requires Membership

When a racing license is required, CSA membership is always implicitly required. A rider cannot hold an active license without an active membership (CSA enforces this — an expired membership causes the license status to become INACTIVE).

6.1.2. Rule: Requirement Inheritance

Requirements cascade: Series → Event → Category. A category-level setting overrides the event-level setting. An event-level setting overrides the series-level setting. If no value is set at a level, it inherits from the parent.

6.1.3. Rule: Strict vs Lenient Registration

  • Strict (strictRegistration=true): The rider must have valid membership/license at the time of registration. The form blocks progression if validation fails.

  • Lenient (strictRegistration=false): The rider can register even without valid status. The compliance state is recorded and can be enforced closer to event day.

6.1.4. Rule: Day License

When a rider does not hold a valid license, they may purchase a day license — unless the event explicitly disallows it (dayLicenseDisallow=true).

Lifecycle of a day licence:

  1. The decision is recorded per person as a DAY_LICENSE action in the CSM/CSL ComplianceAnswer (or implied by choosing "None" at CSI), and collapsed at form completion into EventParticipant.complianceStatus = DAY_LICENSE.

  2. A second OrderLineItem is created on the same EventParticipant, billed against the day-licence product resolved as Event.productDayLicense falling back to Series.productDayLicense. If neither is configured, no line item is added and a warning is logged.

  3. In the WooCommerce payload the day-licence line is a separate eventParticipant[] entry (same participant id, day-licence product) that deliberately omits category and raceTypes — the plugin skips blank meta values, so the line renders on the order, invoice and e-mail as the day-licence product name with the rider’s name and date of birth only. Each day licence is a named, quantity-1 line item, which distinguishes day licences issued to multiple people on one order.

  4. After the order is paid, DayLicenseIssuanceService calls CSA v2 POST /api/v2/day_licenses against the participant’s event’s csa_event_id — gated by the csa.api.day-license-issuance-enabled property (default off; riders are billed regardless, issuance fires only when enabled).

  5. The outcome is recorded on the participant (ADO #875, #876). An issued licence stores CSA’s day-licence id and the issue time. A licence that was not issued — no CSA number on file, no CSA event id on the event, CSA rejected the request, the call failed, or issuance switched off — raises the admin review flag (adminReviewReason = DAY_LICENSE_NOT_ISSUED) and records the cause in dayLicenseFailure, so billed-but-unissued riders are listed by GET /api/event-participants?adminReviewReason.equals=DAY_LICENSE_NOT_ISSUED.

Declining the day licence (remove-on-cancel): when the buyer picks "None" at CSI, the portal explains that a Day Licence will be added to the order and offers three choices: Continue with Day Licence, Remove <name> from registration (they can register again later on their own), or Cancel. Choosing removal submits the CSI answer with action: "REMOVE"; the backend whitelists exactly this action, marks the person removed (mirroring the CSM/CSL REMOVE handling), skips them for all remaining steps and excludes them from EventParticipant and order creation. Re-selecting CSA/UCI before submitting the step clears the pending removal.

Cancel is a no-op: the toggle keeps whichever option was selected before "None" was clicked, and any partially typed CSA/UCI number is preserved. It exists because the dialog is a hard modal (no close button, no escape key, no backdrop dismiss) — without it, merely clicking "None" to read what it means forces the buyer into one of two consequential outcomes with no way back.

6.2. Identification (CSI)

CSI exists solely to obtain an identifier for the downstream CSM/CSL lookups. It is not shown unconditionally — prompting a rider who is already identifiable is noise, and worse, it invites them to answer "None" and be billed a day licence they do not need.

6.2.1. Rule: Conditional prompt

A rider is resolvable when any of the following holds:

Resolvable by Condition

SA ID number

The rider’s identity number passes SA ID checksum validation (IDNumberValidatorUtility.validate). CSM/CSL send id_number to CSA v2, which is the stronger identifier — there is nothing CSI could add.

Persisted UCI ID

A PersonExternalReference of system type UCI exists. There is no live UCI verification, so the stored value is trusted and CSL handles it.

Persisted CSA ID

A PersonExternalReference of system type CSA exists and a CSA v2 pre-check returns ACTIVE. A persisted-but-lapsed number still prompts, so the rider can correct it.

Riders who are not resolvable are prompted for a CSA number, a UCI number, or "None".

6.2.2. Rule: Step visibility

Resolvability gates the step, not just the person, because FormPersonMapper omits skipped people from the response payload entirely:

  • No rider needs input — the whole CSI step is skipped; the form advances straight to CSM. This is the common single-rider case.

  • At least one rider needs input — CSI renders, and resolvable riders stay on the screen in a read-only state showing how they were resolved (e.g. "Verified via SA ID number — nothing needed here"). They are not hidden.

Keeping resolvable riders visible is deliberate and mirrors CSM/CSL, which keep CSI="None" riders visible with a status banner. Silently dropping a person from a multi-rider screen reads as a bug to the buyer ("where did Alex go?").

6.2.3. Rule: Resolved answers are not "None"

A resolvable rider’s pre-filled answer carries an explicit resolvedBy discriminator:

{"csaId":"","uciId":"","resolvedBy":"SA_ID"}

This matters because {"csaId":"","uciId":""} — blanks with no discriminator — is the wire shape for "None", which EventFormController.isCsiNone reads as opted into a day licence. Without the discriminator a rider resolved by SA ID would be indistinguishable from one who declined to supply a number, and would be billed a day licence despite holding valid membership.

isCsiNone therefore returns false whenever resolvedBy is set, and additionally returns false when the rider has a usable SA ID — a "None" answer must never suppress a lookup that would have succeeded on the SA ID alone.

6.3. Membership Validation (CSM)

The CSM step calls the CSA API to check whether the rider’s membership is current and valid for the event.

Validation logic:

  1. Read the CSA ID (or ID number) from the CSI step’s ProcessData

  2. Call checkRacingLicenceStatus with the ID and the event start date as the check date

  3. Map the membershipStatus response to an internal status code

  4. Determine available actions based on the status

Status mapping:

CSA API membershipStatus Internal Status Available Actions

ACTIVE

ACTIVE

Proceed (auto-advance)

EXPIRED

EXPIRED

Renew membership, purchase day license (if allowed), defer, remove person

SUSPENDED

SUSPENDED

Remove person from registration

NONE / NO MEMBERSHIP

NOT_FOUND

Purchase day license (if allowed), defer, remove person

(API unreachable)

OFFLINE

Defer (allow registration, check later)

When status is ACTIVE: The CSM step auto-fills the answer as valid and can be configured to auto-advance (skip=true) so the user sees no interruption.

6.4. License Validation (CSL)

The CSL step calls the CSA API to check the rider’s racing license status.

Validation logic:

  1. Read the CSA ID from CSI ProcessData (same as CSM)

  2. Call checkRacingLicenceStatus with the ID and the event start date

  3. Map the licenceStatus response to an internal status code

  4. Determine available actions based on the status

Status mapping:

CSA API licenceStatus Internal Status Available Actions

ACTIVE

ACTIVE

Proceed (auto-advance)

INACTIVE

INACTIVE

Renew membership first (license becomes active when membership is renewed), defer, remove person

SUSPENDED

SUSPENDED

Remove person from registration

NONE / NO LICENSE

NOT_FOUND

Purchase day license (if allowed), defer, remove person

(API unreachable)

OFFLINE

Defer (allow registration, check later)

The INACTIVE license status specifically means the rider’s membership has expired, causing the license to become inactive. The resolution is to renew the membership, not the license. The UI should communicate this clearly.

6.5. User Actions on Validation Failure

When CSM or CSL validation fails, the user is presented with action options:

Action Description

PROCEED

Only available when status is ACTIVE. Advances to the next step.

RENEW

Directs the rider to renew their CSA membership. The rider must renew externally and then retry.

DAY_LICENSE

Adds a day license to the order. Only available if the event allows day licenses. A day license covers the rider for the specific event date only.

DEFER

Allows the registration to continue with a compliance status of DEFERRED. The rider must resolve the issue before the event. Useful when the API is offline or the rider intends to renew before event day.

REMOVE

Removes this person from the registration. Used when the rider cannot or will not resolve the compliance issue.

7. Caching Strategy

The legacy implementation uses a caching strategy to avoid redundant API calls:

  1. Active status: Cache the result until the event start date. An active membership/license checked for the event date will not change, so the result is stable.

  2. Non-active status: Cache for 5 minutes only. The rider may renew their membership at any time, so we retry after a short interval.

  3. Within 1 minute: Always return the cached result to prevent rapid repeated calls (e.g., page refreshes).

The new implementation should use Spring’s @Cacheable with a TTL-based eviction policy. Cache keys should include the CSA ID and the check date.

8. Admin-Service Wrapper API

The admin-service exposes its own REST endpoints that wrap the CSA API. Frontends (registration-portal, admin-ui) call the admin-service endpoints instead of calling CSA directly. This avoids CORS issues and keeps the API key server-side.

8.1. Endpoint: Check Membership and License

POST /api/csa/check

Request body:

{
  "idNumber": "8501015009086",
  "csaId": "12345",
  "date": "2026-06-15"
}
Field Type Description

idNumber

String (optional)

South African ID number. Preferred for ZA citizens.

csaId

String (optional)

CSA member ID. Used for foreign riders or when ID number is unavailable.

date

String (optional)

Date to check (YYYY-MM-DD). Defaults to current date if omitted.
At least one of idNumber or csaId must be provided.

Response body:

{
  "ok": true,
  "memberFound": true,
  "memberCsaId": "12345",
  "membershipStatus": "ACTIVE",
  "licenceStatus": "ACTIVE",
  "date": "2026-06-15"
}

The response DTO mirrors the CSA checkRacingLicenceStatus response. For now the admin-service wrapper shares the same DTO structure as the upstream CSA API, keeping the integration simple. If the wrapper needs to diverge (e.g., enriching with internal compliance data), the DTOs can be separated later.

8.2. Endpoint: Check Membership Only

POST /api/csa/check-membership

Same request body. Returns the simpler membership-only response (mirrors checkMembershipStatus).

{
  "ok": true,
  "memberFound": true,
  "active": true,
  "date": "2026-06-15"
}

8.3. Design Rationale

  • No CORS: Frontends call admin-service on the same origin. Admin-service calls CSA server-side.

  • API key security: The CSA API key is never exposed to the browser.

  • Caching: Admin-service can cache CSA responses (see Caching Strategy) to reduce external API load.

  • Resilience: Admin-service handles timeouts, retries, and circuit breaking. Frontends get a consistent error response regardless of CSA API behaviour.

  • Shared DTOs (for now): The admin-service response mirrors the CSA API response structure. This avoids unnecessary mapping layers while the integration is straightforward. If admin-service needs to enrich or transform the response in future, the DTOs can be separated without breaking the upstream CSA contract.

9. ComplianceStatus on EventParticipant

The EventParticipant entity has a complianceStatus field (enum ComplianceStatus) that records the outcome of CSA validation:

Value Meaning

VALID

Membership and license checks passed with ACTIVE status.

EXEMPT

The rider is exempt from CSA requirements (manually set by admin).

DAY_LICENSE

The rider purchased a day license for this event.

DEFERRED

The rider deferred resolution. Must be resolved before event day.

PENDING

Checks have not yet been completed (initial state).

This field is set by the CSM and CSL FormFields when saving their ProcessData, and is also available for onDone() to read when creating the final EventParticipant entity.

10. Configuration

Events that require CSA validation include CSI, CSM, and CSL steps in their ProcessDefinition. Events that do not require CSA validation simply omit these steps — the ProcessDefinition is configurable per event.

The CSA requirement flags on Event and EventCategory entities control the business rules (see Business Rules Hierarchy).

11. Source Code

11.1. Legacy WordPress Implementation (Reference)

File Purpose

wpca-members/controllers/CSAController.php

API client — HTTP calls to CSA endpoints via cURL

wpca-members/controllers/CSAEventEntryController.php

Business logic — requirement hierarchy, status mapping, caching, validation rules

wpca-members/controllers/CSACheckMembershipStatusResponse.php

DTO for checkMembershipStatus response

wpca-members/controllers/CSACheckRacingLicenseStatusResponse.php

DTO for checkRacingLicenceStatus response

wpca-members/public/templates/EventCSACheck.php

UI for individual rider CSA status and day license purchase

wpca-members/public/templates/EventEntryReviewCSA.php

Review page showing all entrants' CSA status

11.2. New Java Implementation

File Purpose

admin-service/…​/csa/CsaApiClient.java

Spring service — CSA v2 API client (mock + real)

admin-service/…​/csa/CsaCheckStatus.java

Enum: ACTIVE, EXPIRED, OFFLINE, NOT_FOUND, SUSPENDED

admin-service/…​/csa/CsaMembershipResponse.java

DTO for membership check response

admin-service/…​/csa/CsaLicenseResponse.java

DTO for license check response

admin-service/…​/csa/CsaApiException.java

RuntimeException for API failures

admin-service/…​/csa/CsaMemberStatusApiRequest.java / CsaMemberStatusApiResponse.java

v2 wire DTOs for POST /api/v2/members/status (snake_case, boolean statuses, nested CsaNamedEntity for country/region/city/club)

admin-service/…​/csa/CsaCheckResponse.java

admin-service wrapper response for POST /api/csa/check (membership + licence + enrichment)

admin-service/…​/csa/CsaApiProperties.java

csa.api.* configuration binding

admin-service/…​/csa/CsaDayLicenseApiRequest.java / CsaDayLicenseResponse.java

v2 day-licence creation DTOs for POST /api/v2/day_licenses

admin-service/…​/form/CsaIdentificationFormField.java

CSI step — captures CSA ID and UCI ID

admin-service/…​/form/CsaMembershipCheckFormField.java

CSM step — validates membership, presents action options

admin-service/…​/form/CsaLicenseCheckFormField.java

CSL step — validates license, presents action options

admin-service/…​/form/answer/CsaIdentificationAnswer.java

JSON answer for CSI step

admin-service/…​/form/answer/ComplianceAnswer.java

JSON answer for CSM/CSL steps

database/…​/enumeration/ComplianceStatus.java

Enum: VALID, EXEMPT, DAY_LICENSE, DEFERRED, PENDING

database/…​/domain/EventParticipant.java

Entity with complianceStatus field

database/…​/age/CSAAgeCalculator.java

Age calculator per CSA regulation (age on 31 December of current year)

12. Related Documentation