> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/connectors/crm-and-fidelity/comarch/setup.md). # Setup Comarch setup starts with project preparation. The team should align on the loyalty use case, the target pass content, and the operational journey before filling connector settings. This preparation helps confirm which Comarch data is needed, how the pass should behave, and how the integration will be validated. ## What to collect before setup Before opening the connector settings, align on the business scope of the integration. This usually includes the type of pass, the data that must appear on it, and the expected refresh behavior after loyalty events. Target scenarios should also be clear before setup starts. Typical scenarios include pass creation, pass refresh after a purchase, status change visibility, preferred store display, or coupon update. Test cases should be prepared at the same time. They should make it possible to validate both the expected customer experience and the data returned by Comarch during setup. Once that preparation is complete, collect the technical values below: * **Base URL** of the Comarch CLM B2B Gateway API, for example `https://clm.brand.com/` * **Client ID** and **Client secret** for OAuth 2.0 access * **Program code** for the loyalty program * **Partner code** for the business unit * Confirm The Wallet Crew outgoing IP addresses are allowed by Comarch. The current list is available in the [Infrastructure](/developers-guides/pass-architecture/infrastructure.md#outgoing-ip-addresses) page. If real-time updates will be enabled, also prepare: * **Bootstrap servers** for the Kafka cluster * **Username** and **Password** for Kafka authentication * **Topic** used by Comarch CLM events ## Configure the connector {% hint style="info" %} Ask The Wallet Crew support to enable the Comarch connector on the tenant before configuration starts. {% endhint %} {% stepper %} {% step %} #### Fill the connection settings Open **Connectors → Comarch** and complete the connection fields.
Use the values provided by the Comarch administrator. The main fields are: * **Base URL** * **Client ID** * **Client secret** * **Program code** * **Partner code** {% endstep %} {% step %} #### Configure Kafka, if required Open the Kafka section only when Comarch publishes event streams.
Fill the following fields: * **Bootstrap servers** * **Username** * **Password** * **Topic** If this section stays empty, the connector still works. Passes then refresh on pass open or scheduled refresh only. {% endstep %} {% step %} #### Link the pass template providers Ensure `comarch.customer` is enabled as a pass data provider. Ensure `comarch.store` is also enabled as a pass data provider when store data is needed on the pass. {% endstep %} {% step %} #### Validate the configuration Test with a pass that already contains `id.comarch.customerId`. Then confirm the pass refresh returns customer data. If `storeId` is present, confirm store data too. {% endstep %} {% endstepper %} ## Advanced configuration ### Review the throttling limit The default throttle is **80 API calls per second**.
This matches the usual Comarch CLM B2B Gateway tenant quota. Change it only when a different limit is confirmed. ### Retrieve customer transaction balance Enable **Retrieve customer transaction balance** when the pass needs more than the main points balance.
This option makes an additional API call to Comarch to retrieve the detailed customer transaction balance, including pending points and related balance details. Use it only when those values are required on the pass or in the validation scope. It increases the number of Comarch API calls during refresh. ## Validation checklist A valid setup usually confirms four things: * OAuth authentication succeeds * customer data loads from Comarch * store data loads when `storeId` exists * pass fields render the expected values ## FAQ
When should The Wallet Crew support be contacted? Contact The Wallet Crew support before setup starts so the Comarch connector can be enabled on the tenant.
What should be checked if authentication fails? Check the **Base URL**, **Client ID**, and **Client secret** first. Then confirm the OAuth client can access both profile and partner APIs. If the credentials are correct and authentication still fails, confirm The Wallet Crew outgoing IP addresses are allowed by Comarch. The current list is available in the [Infrastructure](https://docs.thewalletcrew.io/developers-guides/pass-architecture/infrastructure#outgoing-ip-addresses) page.
When should Retrieve customer transaction balance be enabled? Enable it when the pass needs detailed balance information such as pending points. If the pass only needs the main points balance, it is usually not necessary.
Does The Wallet Crew store Comarch loyalty data? No. The Wallet Crew reads the needed data from Comarch when a pass refresh requires it. This connector is designed to keep Comarch as the source of truth for loyalty data such as points, tier, profile, or store information.
Is Kafka required for the setup to work? No. Kafka is optional. Without it, the connector still works and passes can still refresh on pass open or scheduled refresh.
How does The Wallet Crew stay up to date with Comarch information? Kafka helps The Wallet Crew stay aligned with Comarch changes as they happen. When Comarch publishes loyalty events to Kafka, The Wallet Crew can react faster to changes such as points updates, status changes, or store updates. Without Kafka, refresh still works, but it depends on pass open or scheduled refresh timing. See [Real-time updates](/connectors/crm-and-fidelity/comarch/real-time-updates.md) for the detailed flow.
What should be validated first? Start with customer lookup. Then validate store lookup when `storeId` is part of the scenario. Real-time refresh can be validated after the base data flow works.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.thewalletcrew.io/connectors/crm-and-fidelity/comarch/setup.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.