Best Practices for Modeling POS Payment Services, Merchant Identifiers, and Serialized Peripherals

[luis huallpa]

Hello Community,

We are designing a POS management solution using ServiceNow CSM for a payment processor that supports merchants on behalf of financial institutions.

We have reviewed the OOTB documentation for Accounts, Sold Products, Product Models, Install Base Items (IBIs), IBI Characteristics, Assets, and Hardware Model Components. Before finalizing our architecture, we would appreciate guidance on a few specific modeling decisions.

1. Business context and current assumptions

Our business structure is:

• Financial Institution: Parent Account, identified by its FIID.
• Merchant: Child Account, identified by its MID.
• POS terminal: A physical device installed at a merchant location, identified by its TID, serial number, and internal property number.
• Payment services: Services such as Visa, Mastercard, AMEX, EBT, Debit, and other payment solutions.
• Peripherals: Devices such as PIN pads that may be delivered with a POS terminal and have their own serial numbers and inventory records.

Our current assumptions are that the Merchant will be modeled as a Child Account of the Financial Institution and that each TID will have its own parent IBI linked to the corresponding physical POS Asset.

We are not looking to revisit these assumptions. Our questions focus on modeling payment services and their merchant-specific identifiers, as well as serialized peripherals.

2. IBI Characteristics vs. Child IBIs for payment services

A POS terminal may support multiple payment methods and functionalities, including Visa, Mastercard, AMEX, EBT, Debit, ATH Móvil, tips, cashback, and refunds.

We understand that IBI Characteristics can represent configurable values or capabilities, while Child IBIs can represent separate installed product or service instances.

• What criteria should we use to decide whether a payment service or functionality should be modeled as an IBI Characteristic, a Child IBI, or another OOTB entity? For example, should Visa, Mastercard, AMEX, and EBT enabled on a terminal be characteristics of the POS IBI or separate Child IBIs?
• Would the recommendation change if a service has its own activation or suspension lifecycle, requires independent troubleshooting, or needs to be managed separately from the physical terminal?
• How should we represent a service that is available to a merchant but is not tied to a specific physical POS terminal?

We want to avoid creating Child IBIs for simple configuration values, while still supporting independent service management where appropriate.

3. Merchant-specific identifiers assigned by payment networks

In addition to the merchant's MID and the terminal's TID, a merchant may have separate identifiers or affiliation numbers assigned by payment networks or programs for services such as AMEX, Discover, and EBT.

These identifiers are associated with the merchant's relationship with a particular payment service and should not be confused with the MID or TID.

• What is the recommended OOTB entity for storing and relating these identifiers to the merchant and the corresponding payment service? Should they be fields on the Merchant Account, IBI Characteristics, attributes of a Child IBI, or managed through another entity or relationship?
• If the same payment service is enabled on multiple TIDs, should its identifier be maintained once at the merchant/service level and referenced by the terminal instances, or should it be stored separately for each terminal?
• How should we handle scenarios where an identifier has its own status, effective dates, or changes over time?

We want to avoid duplicating merchant-level information across multiple terminal IBIs while maintaining traceability to the corresponding payment service.

4. POS + PIN pad and other serialized peripherals

Some POS terminals are delivered with PIN pads or other peripherals that have their own serial numbers and may require inventory tracking, warranty management, replacement, and support.

We noticed that the Hardware Product Model form (cmdb_hardware_product_model) provides a Model Components related list, where component models can be associated with a bundle and marked as mandatory or optional.

• Is Model Components the recommended OOTB mechanism for defining a POS hardware bundle that includes a PIN pad, and how does this model composition translate into actual Asset records when the equipment is deployed?
• When a PIN pad has its own serial number, inventory record, warranty, and replacement lifecycle, should it have a separate Hardware Product Model and Asset? What OOTB relationship should connect its Asset to the POS Asset?
• Under what circumstances should the PIN pad also have its own IBI, potentially as a Child IBI of the POS IBI?

• How should we distinguish between serialized peripherals that require inventory and lifecycle tracking, and simple accessories such as a POS stand that do not have their own serial number or independent lifecycle?

We want to understand how Hardware Model Components, Assets, and IBIs should work together without unnecessarily representing every physical component as a separate customer-facing installed product.

5. CSM impact

The solution must support cases involving a merchant, payment service, TID, POS Asset, or peripheral, as well as field service activities such as diagnosis, repair, installation, and replacement.

We would appreciate any relevant OOTB considerations for maintaining relationships and traceability across these records throughout the service lifecycle.

Are there any OOTB capabilities, relationships, or recommended design patterns that we may have overlooked and that could help us address these scenarios without unnecessary customization?

Any practical examples, documentation references, or lessons learned from similar implementations would be greatly appreciated.

Thank you for your guidance.

[Kailash Bhange]

Hi @luis huallpa,

Great level of detail. Here's how I'd approach each point, trying to stay as close to OOTB as possible.

1. Characteristic vs Child IBI (payment services)
A simple rule that works well in practice: make it a Child IBI only if at least one of these is true, otherwise keep it as a characteristic of the TID IBI.
- It has its own lifecycle (activate / suspend / terminate independently of the terminal).
- Agents need to raise or route a case against it specifically ("AMEX not working on TID 123" while Visa is fine).
- It has its own entitlement, SLA, contract line or billing.
- It needs its own history/audit.
For most processors this means: Visa, Mastercard, AMEX, EBT, Debit = Child IBIs of the TID IBI (they get enabled, suspended and troubleshot separately). Tips, cashback, refunds = characteristics on the TID IBI (they're on/off settings of the terminal).

A service available to the merchant but not tied to any terminal should not be an IBI under a TID. Represent it as a Sold Product on the Merchant account (one per payment service). Terminal-level Child IBIs can then relate back to that Sold Product.

2. Network-assigned merchant identifiers (AMEX SE number, Discover, EBT/FNS, etc.)
Keep them once at the merchant + service level, not per terminal:
- Store the identifier on the merchant's Sold Product for that payment service (a field or characteristic on the Sold Product).
- Child IBIs on each TID reference that Sold Product, so the identifier is read through the relationship and not copied onto every terminal.
- If you need status, effective-from/to dates and history of identifier changes, Sold Product fields alone get awkward. That's the one place where a small custom table (Merchant network identifier: account, sold product, identifier, status, valid from/to) is justified. Keep it a related list on the Sold Product rather than adding fields to the Account.
- Only put an identifier on the TID's Child IBI if the network really issues it per terminal.

3. POS + PIN pad (serialized peripherals)
- Yes, Model Components on the POS hardware product model is the OOTB way to define the bundle (mark the PIN pad as mandatory or optional).
- Give the PIN pad its own Hardware Product Model so it can have its own Asset with serial number, warranty, stockroom and replacement lifecycle. When you receive or deploy the bundle, the PIN pad Asset should end up as a child (Parent field) of the POS Asset. Swapping a PIN pad then only means changing that child asset.
- Give the PIN pad its own Child IBI (under the TID IBI) only if customers or agents raise cases against it, or it has its own warranty/entitlement visible to the customer. If it's only an inventory and logistics concern, the Asset is enough and the IBI stays at TID level.
- Simple accessories (stand, cables) with no serial number or lifecycle: model them as consumables or non-tracked components of the bundle, with no Asset and no IBI.

4. CSM / FSM traceability
- Case: set Account (merchant), Product, Sold Product and Install Base Item (TID IBI, or the payment-service Child IBI when the issue is service-specific). Asset can be shown on the case through the IBI.
- Work orders created from the case carry the IBI and Asset, so field techs see the right terminal and peripherals. On replacement, update the Asset (and IBI if needed), not the case record.
- Contracts/entitlements can be tied to Sold Products, which lines up nicely with the merchant + service level above.
- Order Management (if you use it) can create the Sold Products and IBIs automatically when a merchant onboarding order is fulfilled, which helps keep this structure consistent.

Main caveat: be strict about not creating Child IBIs for configuration values. Once agents have 15 IBIs per terminal, case creation gets painful.

Which release are you on, and are you using Field Service Management and/or Order Management alongside CSM? That changes a couple of the details above.

If this helps, please mark it helpful or accept it as the solution.

[sanjaygupta]

I would recommend separating payment services, POS configurations and physical hardware based on how independently they need to be managed.

• Use IBI Characteristics for simple capabilities such as Visa, Mastercard, AMEX and EBT when they are just terminal configurations.

• Use Child IBIs when a payment service has its own activation, suspension or troubleshooting lifecycle.

• Manage merchant-level payment services and network identifiers separately rather than duplicating them across multiple TIDs.

• Use Hardware Model Components to define POS bundles with PIN pads and other peripherals.

• Track serialized PIN pads as separate Assets with their own warranty and lifecycle.

• Link peripheral Assets to the POS Asset using the parent-child Asset relationship.

• Create separate IBIs for peripherals only when they require independent customer-facing service management.

For CSM, link Cases to the relevant Account, IBI and Asset to maintain traceability during support and field service activities.

I'd suggest reviewing the OOTB Asset and Install Base synchronization capabilities before introducing custom relationships. Also, avoid creating separate IBIs for simple configurations or accessories.

Hope you find this helpful.