How to Connect a Payment Terminal to a CRM or CDP in 5 Steps

If you are working out how to connect payment terminal to CRM or customer data platform (CDP) systems, the job comes down to five steps. Confirm the terminals and the payment provider that will deploy the software, agree a non-payment customer reference, settle the UK GDPR lawful basis, map each in-store visit to your platform's event model, then pilot and scale. Throughout, the approved payment application keeps control of the payment, while a separate value-added services layer recognises returning customers and sends approved events to the CRM or CDP.

Key takeaways

• Card data never needs to reach the CRM. The connection runs on an approved non-payment reference; PIN, CVV, full card number and payment keys stay with the payment application.
• Deployment runs through the payment provider. PSPs deploy the SDK over their terminal management system (TMS), so merchants install nothing.
• The lawful basis comes before any event. UK GDPR requires a documented lawful basis before processing, and PECR normally requires consent for email or text marketing.
• Every platform ingests events differently. Design one event schema, then map it to each destination's documented API.

How we put this guide together

This guide explains how to connect payment terminal to CRM and CDP systems. We built it from Zeal's own product documentation and live connector pages, plus the public developer documentation of nine CRM, CDP and marketing platforms. We checked every source on 10 October 2026 and list them at the end. Zeal sells value-added services for payment terminals, including connections that send in-store visits to CRMs and CDPs, so we have a commercial interest. We describe what each vendor's documentation says rather than ranking the platforms, and nothing here is legal advice.

Why in-store card payments rarely reach a CRM

Online, a CRM or CDP sees logins, cookies and email clicks. In store, the payment flow carries what the acquirer needs to authorise and settle the sale, not an identity your marketing systems can use. That gap matters because most in-store customers pay by card. UK Finance reports that cards accounted for 64% of all UK payments in 2025, while the Bank of England puts cash at 8% of payments by volume.

Software on the payment terminal closes the gap. A value-added services (VAS) layer runs alongside the payment application. In the words of Zeal's connector pages, "the terminal recognises the card, enrols new customers in a couple of taps and records the visit", and each identified transaction is sent "as a profile update and an in-store event". Zeal publishes these pages for 16 destinations, including Segment, Salesforce and HubSpot.

• CRM: the system of record for contacts, communications and permissions.
• CDP: software that resolves events from many sources into one profile per customer. Twilio Segment says its Identity Graph "merges the complete history of each customer into a single profile, no matter where they interact with your business".

If your goal is to reward customers at the terminal rather than feed a CRM, see how loyalty on card machines works with Zeal.

How to connect payment terminal to CRM and CDP systems: the five steps

1. Confirm the terminal estate and deployment route.
2. Agree the customer reference, produced by card-present data tokenisation, never card data.
3. Set the lawful basis and marketing permissions.
4. Map in-store events to your CRM or CDP data model.
5. Pilot, reconcile and scale through the TMS.

Figure 1. The integration path at a glance, from SDK deployment to reconciliation.

Step 1: Confirm the payment terminal estate and deployment route

List each terminal model, operating system, payment application, Payment App Vendor, acquirer or PSP, and the TMS that manages the devices. Software reaches a payment terminal through the payment provider, not an app store the merchant browses. Adyen says its Android terminals have no connection with Google Play, and apps are uploaded and installed from its Customer Area. PCI Security Standards Council FAQ 1301 notes that a TMS may be used to manage payment terminals and update their software and configurations.

Android has made this more practical: PAX, for example, says Android products accounted for over 70% of its group revenue in 2025. The PCI SSC's PTS POI v7.0 security requirements added a new requirement to allow third-party applications, such as app stores. Our guide to smart payment terminal capabilities sets out what Android terminals can run today.

What about a PAX terminal API integration?

Merchants rarely build a PAX terminal API integration themselves. PAX says its PAXSTORE service covers centralised terminal management and application distribution, and was connected to more than 16 million payment terminals at the end of 2025. The payment provider runs that distribution, and the Payment App Vendor approves the interface through which other software receives a reference. Zeal supports the PAX A920 and A77, both deployed by TMS push.

Table 1. Terminals Zeal supports today

Source: Zeal's guide to terminal-based loyalty. Availability depends on the payment provider.

Step 2: Agree the customer reference and card-present data tokenisation

The CRM should never receive card data. EMVCo describes payment tokenisation as removing "the most valuable data to a fraudster, the primary account number (PAN)" and replacing it with "a unique alternative value". In Zeal's reference architecture, the VAS layer receives only an approved non-payment reference and limited transaction context. The recognition flow excludes the PIN, CVV, full PAN, payment cryptograms and payment keys, and Zeal's privacy policy describes a tokenised payment card identifier rather than a full card number. We explain why that reference matters for unified customer data in the payment terminal as a join key.

Agree three things with your payment provider:

• Which reference is used. It depends on the approved integration. EMVCo notes that a payment token is constrained to "a specific merchant, device or payment scenario", so one person can present different references in different contexts. Apple, for example, says Apple Pay uses a "device-specific Device Account Number", so a phone and the plastic card behind it may not match.
• What the CRM keys on. Keep the CRM or CDP keyed on its own stable profile ID. Segment's Identify spec recommends database IDs over email addresses "because database IDs never change".
• How a card becomes a known customer. A card reference recognises a returning credential, not a named person. The link to a CRM contact is made when the customer chooses to join. With Zeal Loyalty Link, an unregistered customer can enter a phone number on the terminal, receive an SMS enrolment link and be recognised on later eligible visits.

Step 3: Set the lawful basis, notices and marketing permissions

A tokenised reference does not take you outside UK GDPR. The ICO's pseudonymisation guidance says pseudonymised data "is personal data in the hands of someone who holds the additional information". Settle five points before data flows:

• A lawful basis for each purpose. The ICO's guide to lawful basis, updated for the Data (Use and Access) Act, says you "must determine your lawful basis before you start using the personal information and you must document it".
• Marketing permission. Under PECR, organisations normally need consent before sending electronic mail marketing to individuals. The soft opt-in covers only your own similar products and services, and joining a loyalty scheme is not consent to marketing.
• Objections and suppression. The ICO's legitimate interests guidance calls the right to object to direct marketing "an absolute right". An opt-out in one system must suppress journeys in every connected system.
• Roles. Record who is controller and who is processor for each flow. Zeal's joint controller arrangement, for example, says Zeal and a merchant are joint controllers for that merchant's loyalty programme, while Zeal runs card recognition across merchants as an independent controller.
• A data protection impact assessment (DPIA). The ICO's DPIA guidance requires a DPIA if you plan to "match data or combine datasets from different sources", which is what this connection does.

Figure 2. A five-point consent and UK GDPR checklist for the integration.

Step 4: Map in-store events to your CRM or CDP data model

Design one event schema, then map it to each destination. A practical in-store visit event carries:

• the event name and the time the payment completed;
• the store and terminal, mapped from the MID and TID to your location hierarchy;
• the amount and currency, plus the customer's profile ID once they have joined;
• consent flags, so downstream journeys suppress correctly.

Item-level basket data is only available where the EPOS integration exposes the basket through an approved interface. Even without a basket, a single payment carries useful context, as our piece on what every transaction can tell you about your customer explains.

Table 2. How nine CRMs and CDPs document event ingestion

Source: vendor documentation, checked 10 October 2026. Salesforce rebranded Data Cloud as Data 360 on 14 October 2025, and Treasure Data became Treasure AI on 20 April 2026.

How to sync offline transactions to CRM records

"Offline" means two things here. In-store sales are offline transactions from the CRM's point of view, so send each identified payment as its own timestamped event rather than a nightly total. HubSpot, for example, lets you backdate an event with an occurredAt value. Use real-time delivery for journeys that fire after a visit, and batch delivery for analytics.

Figure 3. Real-time webhooks or daily batch: choosing how data is delivered.

Terminals and networks also lose connection. Ask your provider how events are queued, retried or dropped, and how late events are reconciled. Zeal's architecture guidance is that a missing reference should produce no identity claim, match or reward.

Step 5: Pilot, reconcile and scale

1. Choose a representative cohort covering each terminal model, payment application and store format.
2. Set success, failure and rollback criteria before any event is sent.
3. Reconcile the numbers. Compare identified visits with the payment provider's transaction reports. Test refunds, declines, duplicates, wallet payments and reissued cards.
4. Test suppression end to end. Opt out a test customer and confirm every connected journey stops.
5. Scale by cohort through the TMS. Ingenico notes that with a terminal management system, "updates can be deployed remotely across locations without sending technicians onsite".

Zeal's connector pages say each connection "is activated on request with your team, typically in weeks rather than months".

How card-present data tokenisation keeps payment data out of the CRM

Two pieces of software share the payment terminal. The approved payment application keeps control of card reading, authorisation and payment security. The VAS layer works only with the approved reference, returns prompts such as recognition or enrolment, and sends approved events to the Merchant Dashboard, the PSP Portal and, where approved, a CRM.

That separation reduces exposure, not obligations:

• PCI DSS scope still needs assessing. PCI SSC FAQ 1326 says an EMV Payment Token used under the EMVCo specification is not considered account data for merchants and acquirers. It adds that "PCI DSS still applies anywhere Account Data is stored, processed, or transmitted", including systems connected to those that do. FAQ 1301 also says PTS-approved devices do not by themselves guarantee PCI DSS compliance or reduce the scope of a merchant's cardholder data environment.
• The reference is still personal data. The ICO says pseudonymisation "is not a way of transforming personal data to the extent the law no longer applies".
• Ask for an evidence pack: the data-flow diagram, the fields that leave the terminal, the token type and domain, retention periods, and who answers access and deletion requests.

Our guide to value-added services on payment terminals explains how this layer fits a PSP's estate.

What we have learned connecting payment terminals to customer data since 2019

I have led Zeal since I co-founded it with Belal Mohamed in 2019. In my experience, the hard part of a terminal-to-CRM connection is never the API call. It is agreeing what the terminal may share, who owns the data and what happens when something fails. We built the core technology in 2020 and 2021, then tested it for two years, through 2022 and 2023, in real-world merchant pilots, and merchant feedback from those pilots led to key improvements.

I have spent seven years on that work, and it has given us three habits:

• We confirm the terminal before anything is switched on. In my experience, supported models vary by payment provider, so Table 1 is where every conversation starts.
• We deploy through our partners' terminal management systems. Merchants never install Zeal themselves.
• We agree integration and customer-data requirements before deployment. For a CRM or CDP, the event fields, the lawful basis and the owner of suppression are written down before any event is sent.

The outcome so far: more than 30,000 merchants activated on Zeal across payment providers, seven live UK payment partners (Adyen, DNA Payments, Elavon, Lloyds Cardnet, NMI, Viva Wallet and Worldpay) and 4 million payment terminals in our partners' signed activation pipeline. We have raised $14 million in total, and the team won Team of the Year at the UK FinTech Awards 2026. Table 1 comes from Zeal's guide to terminal-based loyalty; Table 2 summarises vendor documentation.

Frequently asked questions

Can a payment terminal send data straight to a CRM?

Not on its own. The payment application exists to take payments, so a separate value-added services layer recognises the customer and sends approved events. Zeal, for example, sends a profile update and an in-store event for each identified visit.

How do you sync offline transactions to a CRM?

Send each identified in-store payment as a timestamped event, mapped to a store and a CRM profile, rather than uploading daily totals. Use the platform's documented route, such as HubSpot custom events or the Salesforce Data 360 Ingestion API, and agree how events are reconciled when a payment terminal loses its connection.

Do I need a PAX terminal API integration to connect a CRM?

Usually not as a merchant. Apps reach PAX terminals through the payment provider's management service, such as PAXSTORE. On supported PAX A920 and A77 terminals, the payment provider deploys Zeal by TMS push.

Does card-present data tokenisation make CRM data anonymous?

No. Tokenisation keeps the card number out of the CRM, but the ICO treats pseudonymised data as personal data for anyone who can link it back to a person. PCI SSC guidance also says PCI DSS still applies wherever account data is stored, processed or transmitted.

Which CRMs and CDPs can Zeal send in-store visits to?

Zeal lists 16 destinations: Adobe Experience Platform, Amperity, Bloomreach, Braze, Dotdigital, Emarsys, HubSpot, Klaviyo, mParticle, Ometria, Optimove, Salesforce, Segment, Tealium, Treasure Data and Zeotap. Each is activated on request.

Sources

• Vendor documentation: Twilio Segment Track, Identify and Identity Resolution; Salesforce Ingestion API and Data 360 guide; HubSpot custom events; Adobe streaming ingestion; Tealium Collect HTTP API; mParticle Events API; Amperity identity resolution; Treasure AI Postback API v2 and rebrand (20 April 2026); Dotdigital Insight data and bulk import.
• EMVCo, EMV Payment Tokenisation.
• PCI Security Standards Council, FAQ 1326 on EMV Payment Tokens (May 2015), FAQ 1301 on payment terminals (August 2023) and PTS POI v7.0 announcement (29 May 2025).
• Information Commissioner's Office, A guide to lawful basis (updated 2 April 2026), Legitimate interests, Pseudonymisation, PECR electronic mail marketing rules and Data protection impact assessments.
• Apple, Apple Pay security and privacy overview; Adyen, How can I use apps with my Android terminal?; PAX Technology, 2025 annual results (25 March 2026).
• Ingenico, terminal management systems (14 April 2026).
• UK Finance, UK Payment Markets 2026 summary (19 August 2026); Bank of England, The promise to pay (17 September 2026).

About the author

Omar Ebeid is Co-founder and CEO of Zeal, which he founded with Belal Mohamed in 2019. He holds an MSc in Entrepreneurship from the University of Bath and won the Vice-Chancellor's Award at the University of Surrey. Under his leadership Zeal won Team of the Year at the UK FinTech Awards 2026 and Platinum at the Juniper Research Future Digital Awards 2023, and has raised $14 million in total, including a $10 million pre-Series A round announced on 9 September 2026. Connect with Omar on LinkedIn.

Related reading

• The Payment Terminal as a Join Key: Why Card Tokens Are the Secret to Unified Customer Data
• How Can a Supermarket Recognise Returning Card Customers at Checkout?
• How Can PSPs and Acquirers Use Real-Time Payment-Terminal Insights?
• How Can QSRs Add App-Free Customer Recognition at the Payment Terminal?