> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Conectar el Fees Engine a Midaz

> Cómo el Fees Engine se conecta a Midaz — qué lee del ledger y la configuración de deploy que los une.

El **Fees Engine** forma parte de Midaz, desplegado como un servicio independiente, y funciona por **cálculo**: tu aplicación le pide calcular las comisiones de una transacción y devuelve el resultado. Tu aplicación luego envía la transacción — ya con las comisiones — a Midaz. El Fees Engine **lee** de Midaz para hacer su trabajo, pero nunca escribe en el ledger; registrar la transacción es un paso de tu aplicación.

Para ver dónde encaja en el panorama general, mira [Construir un core banking completo](/es/building-a-complete-core-banking).

## Para qué usa Midaz el Fees Engine

***

El Fees Engine **lee** de Midaz para dos cosas — no postea nada de vuelta:

* **Resolver las cuentas** — busca las cuentas involucradas, por alias, a través de la **Onboarding API** de Midaz, para que la comisión apunte a cuentas reales.
* **Billing por volumen** — cuenta las transacciones por ruta a través de la **Transaction API** de Midaz, lo que alimenta el billing por período y por volumen.

La comisión en sí se **calcula y se devuelve al llamador**. Tu aplicación la registra en el ledger cuando envía la transacción — el Fees Engine no escribe en Midaz.

## Configuración de la conexión

***

La conexión se define con variables de entorno cuando el Fees Engine se despliega (en su ConfigMap) — no por tu aplicación. Tu app solo llama a la API del propio Fees Engine.

| Variable                | Default / Requerida       | Descripción                                                                                                                                                     |
| ----------------------- | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `MIDAZ_ONBOARDING_URL`  | **Requerida**             | URL base de la Onboarding API de Midaz, usada para resolver cuentas por alias. En setups locales: `http://midaz-ledger:3002/v1/`.                               |
| `MIDAZ_TRANSACTION_URL` | **Requerida**             | URL base de la Transaction API de Midaz, usada para contar transacciones por ruta en el billing por volumen. En setups locales: `http://midaz-ledger:3002/v1/`. |
| `CLIENT_ID`             | Usada en la auth          | Client ID que el plugin usa para autenticarse en Midaz (machine-to-machine).                                                                                    |
| `CLIENT_SECRET`         | Usada en la auth          | Client secret emparejado con `CLIENT_ID`.                                                                                                                       |
| `PLUGIN_AUTH_ENABLED`   | `false`                   | Habilita la autenticación vía Access Manager. Usa `true` en producción.                                                                                         |
| `PLUGIN_AUTH_ADDRESS`   | `http://plugin-auth:4000` | URL del servicio Access Manager (`plugin-auth`) que emite los tokens.                                                                                           |

<Note>
  Ambas variables `MIDAZ_ONBOARDING_URL` y `MIDAZ_TRANSACTION_URL` son requeridas — el plugin no arranca sin ellas. En setups locales, ambas apuntan al mismo host de Midaz (`midaz-ledger:3002`); en producción, apuntan a tus APIs de Midaz desplegadas.
</Note>

## Autenticación

***

El Fees Engine se autentica en Midaz a través del **Access Manager**. Intercambia su `CLIENT_ID` / `CLIENT_SECRET` por un application token y llama a Midaz con ese token — el mismo patrón machine-to-machine que se usa en toda la plataforma.

En deployments **multi-tenant**, las credenciales por tenant vienen del **AWS Secrets Manager** en lugar del `CLIENT_ID` / `CLIENT_SECRET` estáticos; el Access Manager luego emite el token a partir de esas credenciales, para que las llamadas de cada tenant lleguen al ledger correcto. El modo multi-tenant requiere la autenticación habilitada.

→ [Access Manager](/es/platform/access-manager/access-manager)

## Míralo en Lerian

***

* El recorrido completo de integración entre las piezas: [Construir un core banking completo](/es/building-a-complete-core-banking)
* Qué hace el Fees Engine: [¿Qué es Fees Engine?](/es/midaz/fees/fees-engine-overview)
* Despliega el stack: [Helm charts](/es/platform/helm/helm-overview)