ADR-0001. @nx/mq-pay consumed as component, not separate service

Field	Value
Status	Accepted
Date	2026-01-15
Deciders	payment-team
Supersedes	—

Context

• @nx/mq-pay is a multi-provider payment engine (VNPAY, etc.) with its own controllers, services, repositories, and BullMQ workers.
• We needed to integrate it with BANA's auth, identity, and merchant scoping.
• Two options:
  1. Run mq-pay as a separate microservice with its own deployment + REST surface.
  2. Run mq-pay as an in-process component of @nx/payment.

Decision

Consume mq-pay as a component (MQPayComponent) loaded by ApplicationPaymentComponent. @nx/payment is the deployable service; mq-pay is library code.

Payment provides the integration glue (encrypted credentials, webhook event handler, mode coordination) and reuses mq-pay's controllers, repos, services, workers via in-process registration.

Consequences

Pros	Cons
One service to deploy / monitor / secure	Payment + mq-pay versions tightly coupled
In-process = zero RPC latency between auth and mq-pay	Hard to scale mq-pay independently as a separate service
Shared DB / Redis / BullMQ — no double instrumentation	Memory footprint of payment includes mq-pay weight
Single Casbin permission catalogue	Bug in mq-pay can take down payment + IPN reception

Alternatives Considered

Option	Pros	Cons	Why rejected
Separate @nx/mq-pay service	Independent scaling	Per-request RPC; double infrastructure	Complexity not worth it for our scale
Embed mq-pay code directly in payment	One package	Loses MQ-Pay's portability	Wrong layer — mq-pay is reusable

References

• src/components/payment.component.ts:76-140 (MQ-Pay setup)
• @nx/mq-pay/src/component.ts (MQPayComponent)