Updated Journey Webhook

You are an expert backend engineer integrating the IDWise Updated Journey Webhook.

Before writing any code, ask me which backend stack, language, and framework I am using. Examples: Node.js with Express, Python with FastAPI, Python with Django, C# with ASP.NET, Java with Spring Boot, PHP with Laravel, Ruby on Rails, or another stack.

After I answer, generate a complete webhook handler for that stack.

This webhook is triggered after a journey is completed when there is a system decision change or a compliance-driven update, including manual review, AML updates, ban list changes, and step updates.

The webhook handler must:

1. Expose an HTTP POST endpoint that receives the IDWise Updated Journey webhook payload.
2. Parse the JSON payload without failing if IDWise adds extra fields in the future.
3. Read these fields from the payload:
   - event
   - body.eventId
   - body.journeyId
   - body.referenceNo
   - body.systemDecision
   - body.manualDecision
   - body.finalDecision
   - body.action
   - body.manualReviewDetails, when present
4. Validate that the event value is Updated Journey before processing the payload.
5. Log that the Updated Journey webhook was triggered, including:
   - eventId
   - journeyId
   - referenceNo
   - systemDecision
   - manualDecision
   - finalDecision
   - action
6. Use eventId as an idempotency key so duplicate delivery attempts do not update the customer system more than once.
7. Return HTTP 200 to IDWise as soon as the payload is accepted and basic validation is complete.
8. Do not fetch journey details, fetch images, update the customer system, send notifications, or run compliance workflows before returning HTTP 200.
9. After returning HTTP 200, invoke an asynchronous method or background job named processUpdatedJourney or an equivalent name for the selected stack.
10. In the asynchronous method, route each supported action to a separate sub-handler. Do not implement all actions in one large function.

Create separate sub-handlers for these actions:

- handleStepUpdate
- handleAMLAmend
- handleAMLOGMUpdate
- handleAMLMatchUpdate
- handleManualReview
- handleAddedToBanList
- handleBanOverrideApplied
- handleUnknownUpdatedJourneyAction

Each sub-handler must receive a normalized event object that includes eventId, journeyId, referenceNo, systemDecision, manualDecision, finalDecision, action, and manualReviewDetails when available.

Action-specific behavior:

1. Step Update:
   - Fetch the latest journey details if needed.
   - Update the customer system with the step update.
   - Record an audit log.

2. AML Amend:
   - Fetch the latest AML or journey details if needed.
   - Update compliance records.
   - Record an audit log.

3. AML OGM Update:
   - Treat this as an ongoing AML monitoring update.
   - Fetch updated AML information if needed.
   - Update compliance alerts or AML status in the customer system.

4. AML Match Update:
   - Fetch the latest AML match information if needed.
   - Update match status, whitelist status, or review status in the customer system.

5. Manual Review:
   - Read manualReviewDetails.journeyReviewDecision.
   - Read manualReviewDetails.journeyReviewReasonCode, manualReviewDetails.comment, and manualReviewDetails.reviewedSteps.
   - Update the customer system with the manual review result.
   - If journeyReviewDecision is Approved, mark the user or case as approved according to the customer workflow.
   - If journeyReviewDecision is Rejected, mark the user or case as rejected according to the customer workflow.
   - If journeyReviewDecision is Resubmission Requested, call a dedicated sub-handler named handleManualReviewResubmissionRequested.

6. Added to Ban List:
   - Update the customer system to reflect that the journey or applicant was added to the ban list.
   - Trigger any internal risk or compliance workflows.

7. Ban Override Applied:
   - Update the customer system to reflect that the ban was overridden or removed.
   - Trigger any internal risk or compliance workflows.

Manual Review Resubmission Requested behavior:

Implement handleManualReviewResubmissionRequested as a separate method.

This method must:

1. Confirm that manualReviewDetails.reviewedSteps exists and is an array.
2. Iterate through each item in reviewedSteps.
3. For each reviewed step where decision is Resubmit, read:
   - stepId
   - reasonCode
   - any available step metadata from fetched journey details, if needed
4. Generate a user-facing message for each resubmitted step based on reasonCode.
5. Treat reasonCode values as platform-level configurable codes, not hard-coded universal IDWise values. Examples may include document_expired, document_quality_bad, face_not_clear, or missing_information.
6. Implement a configurable reason-code-to-message mapping with safe fallback text for unknown reason codes.
7. Example messages:
   - document_expired: Your document appears to be expired. Please upload a valid, unexpired document.
   - document_quality_bad: We could not clearly read your document. Please retake the photo in good lighting and make sure all edges are visible.
   - face_not_clear: Your selfie was not clear enough. Please retake the selfie with your face fully visible.
   - missing_information: Some required information was missing. Please review the requested step and submit it again.
   - unknown fallback: We need you to resubmit this verification step. Please review the instructions and try again.
8. Combine the step-level messages into a resubmission notification payload for the end user.
9. Determine which notification method the customer backend should use based on the customer's existing system configuration. Support at least:
   - Email notification
   - Push notification
   - Both email and push notification
   - No direct notification, only update internal state
10. Implement a notification dispatch method named notifyUserAboutResubmission or an equivalent name for the selected stack.
11. The notification dispatch method must not assume a specific vendor. Use adapter interfaces or placeholder methods for the customer's email provider and push notification provider.
12. Record an audit log containing eventId, journeyId, referenceNo, journeyReviewDecision, reviewed step IDs, reason codes, and notification method used.

Asynchronous processing requirements:

1. processUpdatedJourney must fetch journey details from IDWise using journeyId when a sub-handler needs current journey state, reviewed step metadata, documents, images, AML details, or ban status.
2. Any image, document, AML, or journey-detail fetching must happen asynchronously after HTTP 200 is returned to IDWise.
3. Add error handling and logging inside processUpdatedJourney and inside each action sub-handler so failures are recorded without causing IDWise webhook delivery to time out.
4. Keep IDWise API credentials out of source code by using environment variables or the stack's secret-management approach.

Return:

1. A short implementation checklist.
2. Complete runnable webhook handler code for the selected stack.
3. The asynchronous processUpdatedJourney method or background job code.
4. Separate sub-handler methods for each action.
5. A dedicated handleManualReviewResubmissionRequested method.
6. A configurable reason-code-to-message mapping with fallback handling.
7. A notification dispatch abstraction that can support email, push notification, both, or internal-state-only handling.
8. Required environment variables.
9. Example log output for a successful Updated Journey webhook trigger.
10. Example log output for a Manual Review Resubmission Requested event with reviewedSteps.
11. Notes explaining why the handler returns HTTP 200 before fetching journey details, updating the customer system, or notifying the end user.

Do not build this as a frontend handler. The webhook endpoint must run on a trusted backend.