HOVHANNES KHACHATRYAN

06 — CASE STUDY

Residential Access & Payment Systems Integration

A systems integration linking payment and account rules in a business application to user provisioning, activation, restriction, and reactivation in an external physical access system.

Physical access · PaymentsSystems integration & implementationConfidential operational environment

OVERVIEW

Context

A business application maintained resident or user account and payment-related state. Payment-terminal infrastructure participated in the payment workflow, while an external access-control/intercom system controlled physical access.

PROBLEM

What had to be solved

Payment and account state had to be evaluated through the application's daily calculations and activation rules before the external system received a provisioning, activation, restriction, or reactivation action. Payment activity could not be treated as a direct access command.

CONSTRAINTS

System boundaries

  • Vendor protocols, private endpoints, device identifiers, credentials, resident data, and payment configuration cannot be exposed in the public case study.
  • The business application had to remain the source of account and access decisions; the external system applied approved actions but did not determine user eligibility.

MY RESPONSIBILITY

Systems integration & implementation

  • Implemented the integration from business-application state to user provisioning, restriction, activation, and reactivation workflows in the external access system.
  • Implemented daily calculations and application rules that linked payment and account state to the required user and access status.
  • Implemented the payment-terminal-related flow that returned eligible users to active status after payment had been reflected in application state.

ARCHITECTURE

System model

Payment-to-access flowPayment information is evaluated inside the business application. Daily calculations, account state, and activation rules determine the desired access status before the integration layer sends an approved action to the external system.
Payment terminal infrastructure
Business application
Daily calculationsUser / account stateActivation rules
Integration layer
Access-control system
Provision userActivate accessRestrict / block access

ENGINEERING CHALLENGES

Where the complexity lived

  • Mapping payment and account results to the correct provisioning, activation, restriction, or reactivation action without bypassing application rules.
  • Keeping each user's provisioned identity and access status consistent across the business application and external access system throughout those lifecycle changes.
  • Keeping vendor-facing commands and responses separate from payment calculations, account rules, and user-status decisions.

APPROACH

How the solution was structured

  • Kept payment and account state, daily calculation results, and access decisions inside the business application.
  • Generated vendor-facing actions only after application rules produced an approved target access state.
  • Handled provisioning, activation, restriction, and reactivation as defined workflows rather than issuing device commands directly from payment or calculation logic.

OUTCOME

What the work established

  • A working integration through which the business application could provision users and apply activation, restriction, and reactivation in the external access system according to payment and account rules.

TECHNICAL CONTEXT

Technologies and systems

Systems integrationPayment terminal integrationAccess-control integration

Vendor identity, protocols, credentials, private endpoints, device identifiers, resident data, and payment configuration are intentionally omitted.