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.