Skip to main content
Version: v2

Kafka Entity Change Event Processing

The EIMP event processing strategy uses the event payload fields and eventType to determine the operation type. The target enterprise identifier is determined by the masterIndividualIdentifier, and only this customer is updated if found in Customer Service.

The logic to identify whether the operation is a Split, Split and Merge, Merge, or Delete is determined by the records and oldRecords arrays populated in the entityChange object.

Event Types Evaluation in Migration Service​

Split​

A merchant customer identifier is split and moved to another enterprise identifier. The oldRecords array will show which record was migrated.

  • EventType: SPLIT

Merge​

A merchant customer identifier is combined into an existing enterprise identifier. The records array will contain the record being added.

  • EventType: MERGE

Split and Merge​

Occurs when enterprise identifiers have both split and merged in a single operation. The oldRecords and records arrays will contain several updates. New merchant customer identifiers are added to the enterprise identifier, and some other records may be migrated to another enterprise identifier.

  • EventType: SPLIT_AND_MERGE

Delete​

This event indicates that a merchant customer identifier has been deleted from an enterprise identifier.

  • EventType: DELETE

EIMP Event Processing in Customer Service​

SPLIT / SPLIT_AND_MERGE (eimpDeleted = false)​

  • Payment Methods: All customer payment methods are requested for deletion via DeleteAllCustomerPaymentMethodsCommandHandler. Verification attempts to confirm each is marked as DELETED. Failures are logged and ignored (flow continues).
  • Merchant Customer Identifiers: All removed via merchantCustomerHandler.deleteAllMerchantCustomerIdentifiers.
  • Demographics / HSID: Refreshed from the Identity Service (if the enterpriseId resolves). The stored HSID is nulled first if it is no longer present among current Identity HSIDs.
  • Customer isActive: Remains true.
  • EnterpriseCustomer: Demographics (and HSID if present) updated; enterpriseId remains unchanged.

SPLIT / SPLIT_AND_MERGE (eimpDeleted = true)​

  • Branch short-circuits to deletion handling: No payment method purge or merchant identifier deletion.
  • Customer: Marked inactive; enterpriseId overridden with an inactive form.
  • EnterpriseCustomer: enterpriseId overridden similarly.
  • Demographics / HSID: Not refreshed.
  • Customer isActive: Set to false.

MERGE (eimpDeleted flag ignored)​

  • Payment Methods: Unchanged (no deletion).
  • Merchant Customer Identifiers: All removed.
  • Demographics / HSID: Refreshed from the Identity Service (same HSID nulling rule applies).
  • Customer isActive: Remains true.
  • EnterpriseCustomer: Demographics and HSID updated.

DELETE (reason = DELETE, eimpDeleted = false)​

  • Payment Methods: Unchanged.
  • Merchant Customer Identifiers: Unchanged.
  • Demographics / HSID: Not refreshed (reason path short-circuits).
  • Customer isActive: Remains true.
  • EnterpriseCustomer: Unchanged.

DELETE (reason = DELETE, eimpDeleted = true)​

  • Customer: Marked inactive; enterpriseId overridden with a synthetic inactive form.
  • EnterpriseCustomer: enterpriseId overridden similarly.
  • Payment Methods: Not deleted.
  • Merchant Customer Identifiers: Not deleted.
  • Demographics / HSID: HSID will be deleted if the HSID of the event matches the wallet HSID.
  • Customer isActive: Set to false (only mutation path identical to the SPLIT/SPLIT_AND_MERGE hard delete branch).

Other Event Types​

  • Ignored: No customer mutations.
  • Customer isActive: Unchanged.

HSID Handling​

Applied only for SPLIT, SPLIT_AND_MERGE, and MERGE when eimpDeleted = false:

  • If the stored HSID (UUID form) is absent from current Identity HSID identifiers, it is nulled before applying updated demographics.
  • This prevents retaining stale HSID associations after identity reshaping.

HSID Deletion on Customer Inactivation​

  • When a customer is inactivated (i.e., any event is received with isActive = false in the payload), the system must also delete the associated HSID. This ensures that no stale HSID remains for inactive or deleted customers. Inactivation is not limited to DELETE events; it applies to any event type where the payload sets isActive to false. See event payload examples above.

Conditional HSID Deletion on Delete Events (December 2025 Update)​

  • Previously, no action was taken on DELETE events. Now, when a DELETE event is received that is related to the deletion of an HSID for a given EID, the system will:
    • Delete the HSID only if the HSID being deleted matches the HSID currently stored in the system for the given EID.
    • If the HSID does not match, no action is performed, as the HSID may have already been updated or replaced.
  • This logic prevents accidental removal of updated or unrelated HSIDs and ensures data integrity during event-driven deletions.

Effect of eimpDeleted Flag (Summary)​

Event CategoryeimpDeleted = falseeimpDeleted = true
SPLIT / SPLIT_AND_MERGEPurge payment methods + merchant identifiers; refresh demographics/HSIDSkip purge; inactivate customer; override enterprise identifiers; no demographic refresh
MERGERemove merchant identifiers; refresh demographics/HSID(Same as false) — flag not used in merge path
DELETERemove HSID if applicableInactivate + override enterprise identifiers

isActive Changes​

  • Remains true for: SPLIT, SPLIT_AND_MERGE, MERGE, DELETE (eimpDeleted = false), and ignored reasons.
  • Set to false only for: DELETE with eimpDeleted = true.

Processing Status Tracking​

  1. Persist an EimpMasterIndividualDetails record in PROCESSING state.
  2. Apply reason-specific (and eimpDeleted-specific) side effects.
  3. Optionally refresh demographics (only for SPLIT, SPLIT_AND_MERGE, MERGE with eimpDeleted = false).
  4. Mark the record as COMPLETED or FAILED (errors during side-effect phases update status to FAILED and stop further mutations).