> 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/pos.md).

# Point of Sale (POS)

POS systems are the operational source for checkout and redemption events. The Wallet Crew connects those systems to Apple Wallet and Google Wallet so passes stay usable at the moment of transaction.

This matters because wallet is not just a distribution channel. At point of sale, the pass must be readable, recognized, and aligned with the latest business rules.

## How POS integrations work

In a POS integration:

1. The POS remains the source of truth for transaction and redemption data.
2. The Wallet Crew maps identifiers and pass data to wallet-compatible payloads.
3. Wallet updates reflect status changes that matter at checkout or after redemption.

This keeps operational logic in existing systems while making wallet passes reliable in-store.

<details>

<summary><strong>Real-world examples</strong></summary>

* A retailer scans a loyalty pass at checkout, then refreshes the points balance.
* A gift-card redemption changes the pass balance immediately after payment.
* A service counter validates a membership pass before applying its benefits.

</details>

### What POS integrations usually cover

Typical POS integrations include:

* pass identification at checkout or service counter
* redemption events and post-redemption status updates
* optional synchronization of balances, eligibility, or usage counters

### Available POS connectors

The available connector guides cover the following POS platforms:

* [Adyen](/connectors/pos/adyen.md)
* [Cegid](/connectors/pos/cegid.md)
* [Newstore](/connectors/pos/newstore.md)
* [Openbravo](/connectors/pos/openbravo.md)
* [Shopify POS](/connectors/pos/shopify-pos.md)
* [Square](/connectors/pos/square.md)
* [TCPOS](/connectors/pos/tcpos.md)

Each guide documents the platform-specific setup and supported behavior.

### POS systems not listed

An unlisted POS can become a standard connector. The Wallet Crew and the POS partner jointly scope that option when the integration can support multiple Brands.

For a tenant-specific POS, use a [custom connector](/connectors/custom-connector.md). Tenant scripting can call private APIs and apply proprietary mapping rules. Define the identifier, API contract, trigger model, and operational owner before implementation.

### Responsibilities

| Responsibility area              | POS or partner system                                  | The Wallet Crew                                    |
| -------------------------------- | ------------------------------------------------------ | -------------------------------------------------- |
| Transaction and redemption truth | Owns operational records and business validation rules | Does not replace POS business logic                |
| Identifier governance            | Defines stable identifiers used at scan or lookup time | Uses identifiers to resolve and update passes      |
| Wallet payload lifecycle         | Provides event/data inputs                             | Generates and updates Apple/Google wallet payloads |
| Optional custom logic            | Implements proprietary POS-specific flows              | Provides runtime hooks and wallet orchestration    |

### FAQ

<details>

<summary><strong>Does the POS remain the source of truth?</strong></summary>

Yes. The Wallet Crew extends POS data to wallet experiences, but transaction logic and redemption authority remain in the POS stack.

</details>

<details>

<summary><strong>Can we integrate if our POS is not documented here?</strong></summary>

Yes. The Wallet Crew and the POS partner can scope a standard connector. For project-specific flows, use a [custom connector](/connectors/custom-connector.md).

</details>

<details>

<summary><strong>What must be validated before a POS rollout?</strong></summary>

Validate the pass identifier, scan path, redemption authority, and pass update trigger. Test the flow with production scanner hardware before rollout.

</details>

<details>

<summary><strong>What should be decided first in a POS project?</strong></summary>

Start with identifier strategy, redemption flow ownership, and update triggers. These three decisions define most of the implementation shape.

</details>


---

# 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/pos.md?ask=<question>&goal=<endgoal>
```

`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.