This documentation is currently under development. Certain sections are not yet complete and will be added shortly.
Ctrlk
HomeDocumentation
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Real-time updates

Use Comarch Kafka events to refresh wallet passes when customer data changes.

Real-time updates keep the pass aligned with Comarch between two pass opens. This is useful when loyalty changes must appear quickly after a purchase, a tier update, or a coupon assignment.

How Kafka refresh works

The connector can subscribe to a Comarch CLM Kafka topic.

When a supported event arrives, The Wallet Crew identifies the affected pass and starts a refresh.

This reduces the delay between a change in Comarch and the visible update on the wallet pass.

Supported event types

The connector refreshes passes for the event families below:

  • Customer

  • Account point type balance

  • Counter balance

  • Coupon

These events cover common loyalty changes such as profile updates, point balance changes, counter changes, and coupon activity.

Kafka settings

Use the Kafka section in Connectors → Comarch to configure:

  • Bootstrap servers

  • Username

  • Password

  • Topic

Kafka authentication uses SCRAM-SHA-512.

When Kafka is not configured

The connector still works without Kafka.

In that mode, passes refresh when the pass is opened or when a scheduled refresh runs. The difference is timing, not connector capability.

Validation steps

A Kafka setup is usually validated in three steps:

  1. Publish or wait for a known Comarch loyalty change.

  2. Confirm the event reaches the configured topic.

  3. Confirm the related pass refreshes shortly after.

FAQ

What should be checked if a Comarch event does not refresh a pass?

Check the topic name and Kafka credentials first.

Then confirm Comarch publishes one of the supported event types listed on this page.

What if pass refresh is delayed?

Check Kafka connectivity before checking the pass template.

If Kafka is unavailable, refresh falls back to the next pass open or scheduled refresh.

What if Kafka triggers too many refreshes?

Review the event stream design and the expected event volume.

Some projects publish many events for the same customer in a short time. In that case, rollout should start in staging and be monitored closely before production activation.

Last updated