> ## Documentation Index > Fetch the complete documentation index at: https://docs.therius.io/llms.txt > Use this file to discover all available pages before exploring further. # Cobra tarjetas guardadas usando credenciales almacenadas y MIT > Usa credenciales almacenadas para cobrar a clientes sin que estén presentes — facturación recurrente, cuotas y pagos MIT no programados con Therius. Las credenciales almacenadas — también llamadas Merchant Initiated Transactions (MIT) — te permiten cobrar la tarjeta guardada de un cliente en cualquier momento después de que te haya autorizado explícitamente a hacerlo. Los casos de uso comunes incluyen renovaciones de suscripción, planes de cuotas y cobros no programados como la facturación por uso. Las reglas de las banderas de tarjeta (Visa, Mastercard y otras) requieren que declares el tipo de uso de la credencial tanto en el cobro inicial como en cada cobro posterior. Therius pasa esta información directamente a las redes de tarjetas en tu nombre, pero tú debes suministrar los campos correctos. ## CIT vs. MIT Toda relación de credencial almacenada comienza con una **Customer Initiated Transaction (CIT)**, durante la cual el cliente está presente y autoriza explícitamente los cobros futuros. El cliente está completando activamente el checkout. Recolectas la tarjeta vía un nonce fresco (o número de tarjeta sin procesar) y estableces `cardOnFile.usage: "first"`. La respuesta devuelve `card.networkTransactionId` y `card.networkReferenceId` — **guarda ambos valores** en tu base de datos. Los necesitarás para cada MIT posterior. El cliente no está presente. Pasas el vault token guardado más los campos de credencial almacenada, incluidos el `networkTransactionId` y el `networkReferenceId` de la CIT original. Las redes de tarjetas usan estas referencias para enlazar el cobro con el mandato autorizado. *** ## El objeto `cardOnFile` Agrega un bloque `cardOnFile` dentro del objeto `card` tanto en la CIT como en cada MIT. `cardOnFile` en sí es opcional (Therius deriva un valor predeterminado según el contexto — un `tokenize` nuevo frente a una reutilización de `tokenData` — cuando se omite), pero una vez que lo envías, `usage`, `initiatedBy` y `type` son los tres campos que juntos clasifican el cobro ante las redes de tarjetas. | Campo | Valores | Requerido en | | ----------------- | ----------------------------------------------------------------------------------------------- | ------------------------------- | | `initiatedBy` | `"cardholder"` \| `"merchant"` | CIT + MIT | | `type` | `"recurring"` \| `"installment"` \| `"unscheduled"` | CIT + MIT | | `usage` | `"first"` \| `"subsequent"` | CIT + MIT | | `exceptionReason` | `"resubmission"` \| `"incremental"` \| `"reauthorization"` \| `"delayed_charge"` \| `"no_show"` | Solo MIT, y solo cuando aplique | `initiatedBy` usa `"cardholder"`, no `"customer"` — respeta el valor exacto del enum. `exceptionReason` es **opcional** y se sitúa en un eje propio, independiente de `type` — no reemplaza a `type`, añade una etiqueta de excepción de negocio encima. La mayoría de los cobros MIT posteriores nunca lo envían; establécelo solo cuando el cobro específico caiga en una de estas categorías definidas por la bandera: | Valor | Significado | Ejemplo | | ----------------- | --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | `resubmission` | Reintento de un cobro previamente rechazado de forma suave (fondos insuficientes, no honrar) por el mismo monto | Una renovación de suscripción reintentada al día siguiente tras un rechazo `51` | | `incremental` | Un incremento de autorización sobre un mandato existente | Un folio de hotel añade un cargo de servicio a la habitación antes del checkout | | `reauthorization` | Una nueva autorización porque la original expiró antes de la captura | Mercancía aún no enviada cuando vence la ventana de autorización inicial | | `delayed_charge` | El monto final difiere de una estimación o retención previa | Kilometraje extra de alquiler de auto; una propina agregada después de la comida | | `no_show` | El titular de la tarjeta no se presentó a una reserva garantizada | Una tarifa de no presentación de hotel | *** ## Ejemplo de CIT inicial Recolecta la tarjeta de forma normal (usando un nonce del SDK o datos de tarjeta sin procesar en un servidor que cumple PCI), tokenízala estableciendo `tokenize: true`, e incluye el bloque `cardOnFile`. ```json theme={"dark"} POST /payment/purchase { "merchantCode": "MERCHANT_001", "orderCode": "ORDER-CIT-001", "amount": { "currency": "USD", "value": 1999, "exponent": 2 }, "card": { "cardData": { "cardNumber": "4111111111111111", "expiryMonth": "12", "expiryYear": "2027", "cvv": "123", "tokenize": true }, "cardOnFile": { "initiatedBy": "cardholder", "type": "recurring", "usage": "first" } }, "shopper": { "id": "customer-42" } } ``` De la respuesta, guarda estos dos campos en tu base de datos — enlazados al vault token del cliente: ```json theme={"dark"} { "card": { "token": "vt_a1b2c3d4e5", "networkTransactionId": "016153570XXXXXX", "networkReferenceId": "MCC000XXXXXXXXXXXX" } } ``` *** ## Guardar una tarjeta sin conocer el patrón de cobro futuro Si estás guardando en el vault una tarjeta y aún no sabes si se convertirá en una suscripción recurrente, un plan de cuotas o un cargo único no programado, decláralo como `"type": "unscheduled"` — la categoría que las redes de tarjetas destinan a "uso futuro autorizado por el titular, patrón aún no determinado". Guarda igualmente el `networkTransactionId`/`networkReferenceId` devueltos; los necesitarás para cualquier MIT que termines enviando. ```json theme={"dark"} POST /payment/purchase { "merchantCode": "MERCHANT_001", "orderCode": "ORDER-SAVE-003", "amount": { "currency": "USD", "value": 1999, "exponent": 2 }, "card": { "cardData": { "cardNumber": "4111111111111111", "expiryMonth": "12", "expiryYear": "2027", "cvv": "123", "tokenize": true }, "cardOnFile": { "initiatedBy": "cardholder", "type": "unscheduled", "usage": "first" } }, "shopper": { "id": "customer-42" } } ``` Si la tarjeta solo se reutilizará en un **futuro checkout con el cliente presente** — el cliente la elige entre sus métodos guardados y confirma el cobro él mismo, nunca cobrada sin presencia por ti — no necesitas ningún bloque `cardOnFile`. Solo envía `tokenize: true` con `shopper.id`. `cardOnFile` solo importa cuando ocurrirá una MIT. *** ## Ejemplo de MIT posterior — renovación recurrente En cada cobro posterior — una renovación, una cuota, un cargo adicional no programado — pasa el vault token más los campos de credencial almacenada y las referencias de red de la CIT original. Este ejemplo muestra una renovación recurrente (estilo suscripción); cambia `type` por `installment` o `unscheduled` para que coincida con el mandato que estableciste en la CIT. ```json theme={"dark"} POST /payment/purchase { "merchantCode": "MERCHANT_001", "orderCode": "ORDER-MIT-002", "amount": { "currency": "USD", "value": 1999, "exponent": 2 }, "card": { "tokenData": { "token": "vt_a1b2c3d4e5" }, "cardOnFile": { "initiatedBy": "merchant", "type": "recurring", "usage": "subsequent" }, "networkTransactionId": "016153570XXXXXX", "networkReferenceId": "MCC000XXXXXXXXXXXX" } } ``` El motor de suscripciones de Therius administra las credenciales almacenadas internamente para todas las renovaciones de suscripción. Nunca necesitas suministrar `cardOnFile` ni campos de referencia de red al usar la API de suscripciones — esta guía solo es relevante si estás construyendo tu propia lógica de facturación fuera del motor de suscripciones. Si tu CIT inicial pasa por el Checkout Widget en lugar de una llamada directa a la API, no necesitas construir este bloque `cardOnFile` a mano — pásalo una vez al crear la sesión del SDK (`POST /sdk/session`'s `cardOnFile`). El widget entonces muestra un aviso de "la tarjeta se guardará" y el servidor aplica el etiquetado de credencial almacenada y la tokenización por ti. Ver [Suscripciones gestionadas por el comercio](/es/sdk/session-bootstrap#suscripciones-gestionadas-por-el-comercio). *** ## Tipos de credencial Usa `"type": "recurring"` para cobros de monto fijo que se repiten en un calendario predecible — cuotas mensuales de SaaS, renovaciones anuales, cuotas de membresía. Usa `"type": "installment"` cuando un cliente autoriza un pago dividido en una cantidad fija de cobros — por ejemplo, tres pagos mensuales por una sola compra. Usa `"type": "unscheduled"` para cobros que se autorizan por adelantado pero se disparan por un evento definido por el comercio — facturación por uso, recargas de cuenta, tarifas de conveniencia, o una tarjeta guardada para uso futuro antes de conocer su patrón definitivo. Ver [Razones de excepción](#el-objeto-cardonfile) arriba para `exceptionReason` — un eje separado y opcional de `type`, usado solo cuando una MIT específica cae en una categoría de excepción definida por la bandera. *** Las reglas de las banderas de tarjeta requieren una declaración CIT/MIT precisa en cada transacción. Clasificar mal un cobro — por ejemplo, enviar un MIT sin el `networkTransactionId` original — puede resultar en tasas de rechazo más altas, contracargos o penalidades del adquirente. Ante la duda, contacta al soporte de Therius antes de salir a producción con un nuevo modelo de facturación.