[es-ES] concepts/payment-types

[es-ES] concepts/payment-types

@i18n/es-ES/docs/concepts/payment-types/bouncing-payments.md

@@ -0,0 +1,19 @@
+---
+html: bouncing-payments.html
+parent: payment-types.html
+seo:
+    description: Cuando el propósito de un pago no esté claro, devuélvelo al remitente.
+labels:
+  - Tokens
+---
+# Devolver pagos
+
+Cuando una de tus direcciones recibe un pago cuyo propósito no está claro, te recomendamos que intentes devolver el dinero a su remitente. Si bien esto requiere más trabajo que quedarse con el dinero, demuestra buena fe hacia los clientes. Puedes hacer que un operador rechace los pagos manualmente o crear un sistema para hacerlo automáticamente.
+
+El primer requisito para devolver pagos es [monitorizar de manera robusta los pagos entrantes](robustly-monitoring-for-payments.md). ¡No querrás devolver accidentalmente a un cliente más de lo que te ha enviado! (Esto es particularmente importante si tu proceso de devolución está automatizado.) Usuarios maliciosos pueden tomar ventaja de una integración inocente al enviar [pagos parciales](partial-payments.md#exploit-de-pagos-parciales).
+
+En segundo lugar, deberías enviar los pagos devueltos como Pagos Parciales (partial payments). Dado que terceras partes pueden manipular el coste de los caminos entre direcciones, los Pagos Parciales te permiten desprenderte de la cantidad completa sin preocuparte por los tipos de cambio dentro del XRP Ledger. Deberías publicar tu política de devolución de pagos como parte de tus términos de uso. Envía el pago devuelto desde una dirección operacional o una dirección de reserva.
+
+Para enviar un Pago Parcial, activa el [flag `tfPartialPayment`](../../references/protocol/transactions/types/payment.md#flags-de-pago) en la transacción. Introduce la cantidad en el campo `Amount` con la cantidad que recibiste y omite el campo `SendMax`. Deberías utilizar el valor `SourceTag` del pago entrante como el `DestinationTag` de tu pago de devolución.
+
+Para prevenir que dos sistemas estén devolviendo pagos uno al otro indefinidamente, puedes establecer un nuevo Source Tag para el pago de devolución saliente. Si recibes un pago inesperado cuyo Destination Tag coincide con el Source Tag de una devolución que enviaste, no lo rechaces nuevamente.

@i18n/es-ES/docs/concepts/payment-types/checks.md

@@ -0,0 +1,67 @@
+---
+html: checks.html
+parent: payment-types.html
+seo:
+    description: Los cheques permiten a los usuarios a crear pagos diferidos que pueden ser cancelados o cobrados por los destinatarios deliberados.
+labels:
+  - Cheques
+  - Pagos
+  - Tokens
+---
+# Cheques
+
+
+La función de Cheques permite a los usuarios crear pagos aplazados similares a cheques en papel. A diferencia de un depósito en garantía (escrow) o canal de pago (payment channel), los fondos no se reservan cuando se crea un cheque, por lo que el dinero solo se mueve cuando se cobra el cheque. Si el remitente no tiene los fondos en el momento en que se cobra un cheque, la transacción falla; los destinatarios pueden intentar nuevamente las transacciones fallidas hasta que el cheque expire.
+
+Los Cheques del XRP Ledger pueden tener tiempos de vencimiento después de los cuales ya no pueden ser cobrados. Si el destinatario no cobra con éxito el Cheque antes de que expire, el Cheque ya no se podrá cobrar, pero el objeto permanece en el XRP Ledger hasta que alguien lo cancele. Cualquiera puede cancelar el Cheque después de que expire. Solo el remitente y el destinatario pueden cancelar el Cheque antes de que expire. El objeto del Cheque se elimina del ledger cuando el remitente cobra con éxito el cheque o alguien lo cancela.
+
+## Casos de uso
+
+- Los Cheques permiten a las personas intercambiar fondos utilizando un proceso familiar y aceptado por la industria bancaria.
+
+- Si tu destinatario previsto utiliza autorización de deposito, [Deposit Authorization](../accounts/depositauth.md) para bloquear pagos directos de extraños, un cheque es una buena alternativa.
+
+- Cobros de cheques flexibles. El destnatario puede canjear el Cheque entre un nínimo y un máximo.
+
+
+## Ciclo de vida de un cheque
+
+1. El remitente envía una [transacción CheckCreate][], que define:
+    - El destinatario.
+    - Una fecha de caducidad.
+    - La cantidad máxima que se puede cargar de su cuenta.
+
+2. Cuando una transacción es procesada, el XRP Ledger crea un objeto `Check`. El cheque puede ser cancelado por el destinatario o el remitente con una  [transacción CheckCancel][].
+
+3. El destinatario envía una [transacción CheckCash][] que transfiere los fondos y destruye el objeto `Check`. Los destinatarios tienen dos opciones para cobrar los cheques:
+    -  Cantidad exacta: Se especifica la cantidad exacta de dinero a cobrar que no puede exceder el máximo del cheque.
+    - Cantidad flexible: Se especifica una cantidad mínima para cobrar y el XRP Ledger manda tanto como sea posible hasta el máximo del cheque. Si el remitente no tiene fondos para cumplir al menos el mínimo específicado, la transacción falla.
+
+4. Si el cheque vence antes de que el destinatario lo cobre, el objeto `Check` permanece hasta que alguien lo cancele.
+
+
+
+## Ver también
+
+Para más información sobre Cheques en el XRP Ledger, ver:
+
+- [Referencia transacción](../../references/protocol/transactions/types/index.md)
+    - [CheckCreate][]
+    - [CheckCash][]
+    - [CheckCancel][]
+- [Tutoriales de cheques](../../tutorials/how-tos/use-specialized-payment-types/use-checks/use-checks.md)
+    - [Enviar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/send-a-check.md)
+    - [Buscar cheques por dirección del remitente](../../tutorials/how-tos/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md)
+    - [Buscar cheques por dirección del destinatario](../../tutorials/how-tos/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md)
+    - [Canjear un cheque por la cantidad exacta](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-an-exact-amount.md)
+    - [Canjear un cheque por una cantidad flexible](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md)
+    - [Cancelar un cheque](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cancel-a-check.md)
+- [Enmienda Cheques][]
+
+Para más información sobre funciones relacionadas, ver:
+
+* [Autorización de deposito](../accounts/depositauth.md)
+* [Escrow](escrow.md)
+* [Tutorial de canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@i18n/es-ES/docs/concepts/payment-types/cross-currency-payments.md

@@ -0,0 +1,42 @@
+---
+html: cross-currency-payments.html
+parent: payment-types.html
+seo:
+    description: Los pagos entre divisas entregan atómicamente una moneda diferente a la que envían mediante la conversión a través de rutas y libros de pedidos.
+labels:
+  - Entre divisas
+  - Pagos
+---
+# Pagos entre divisas
+
+El XRP Ledger te permite realizar pagos entre divisas de XRP y tokens. Los pagos entre divisas dentro del XRP Ledger son complétamente atómicos, lo que quiere decir que el pago se ejecuta por completo o no se ejecuta en absoluto.
+
+Por defecto, los pagos entre divisas entregan una cantidad fija a su destino a un coste variable para su origen. Los pagos entre divisas también pueden ser [pagos parciales](partial-payments.md) que entregan una cantidad variable dentro de un límite de envío establecido.
+
+
+## Prerrequisitos
+
+- Por definición, un pago entre divisas implica al menos dos monedas, lo que significa que al menos una fivisa involucrada debe ser un [token](../tokens/index.md) que no sea XRP.
+- Debe existir al menos una ruta o [Path](../tokens/fungible-tokens/paths.md) entre el remitente y el receptor, y la liquidez total a lo largo de todas las rutas debe ser suficiente para ejecutar el pago. Los pagos entre divisas se convierten de una divisa a otra consumiendo ofertas u [Offers](../tokens/decentralized-exchange/offers.md) en el [exchange descentralizado](../tokens/decentralized-exchange/index.md) del XRP Ledger.
+
+
+## Auto-puente
+
+Los pagos entre divisas que intercambian un token por otro token pueden utilizar automáticamente XRP como puente entre los tokens, cuando esto reduce el coste del pago. Por ejemplo, un pago que envía de USD a MXN convierte automáticamente USD a XRP y luego XRP a MXN si hacerlo es más barato que convertir USD a MXN diréctamente. Operaciones más grandes pueden utilizar una combinación de conversiones directas (USD-MXN) y puentes automáticos (USD-XRP-MXN).
+
+Para más información, ver auto-puente o [Auto-Bridging](../tokens/decentralized-exchange/autobridging.md).
+
+
+## Ver también
+
+- **Conceptos:**
+    - [Tokens](../tokens/index.md)
+    - [Exchange descentralizado](../tokens/decentralized-exchange/index.md)
+    - [Paths](../tokens/fungible-tokens/paths.md)
+- **References:**
+    - [Tipos de transacciones de pago][Payment transaction]
+    - [método path_find][]
+    - [método ripple_path_find][]
+    - [Interpretando metadatos de pagos entre divisas](../transactions/finality-of-results/look-up-transaction-results.md#token-payments)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@i18n/es-ES/docs/concepts/payment-types/direct-xrp-payments.md

@@ -0,0 +1,49 @@
+---
+html: direct-xrp-payments.html
+parent: payment-types.html
+seo:
+    title: Pagos directos en XRP
+    description: Los pagos directos en XRP son la forma más rápida y sencilla de enviar valor en el XRP Ledger. Conoce ahora los conceptos básicos del ciclo de vida de pago directo en XRP.
+labels:
+  - XRP
+  - Pagos
+---
+# Pagos directos en XRP
+
+La base de cualquier sistema financiero es la transferencia de valor. El método más rápido y sencillo en el XRP Ledger es un pago directo en XRP de una cuenta a otra. A diferencia de otros métodos de pago que requieren múltiples transacciones para completarse, un pago directo en XRP se ejecuta en una sola transacción sin intermediarios, y típicamente se completa en 8 segundos o menos. Solo puedes hacer pagos directos cuando XRP es la moneda enviada y recibida.
+
+
+
+## Ciclo de vida de pagos XRP directos
+
+1. El remitente crea una [transacción Payment][], que define los parámetros del pago. La transacción es un pago directo en XRP si XRP es la divisa enviada y recibida.
+
+2. El procesamiento de la transacción verifica los parámetros y circunstancias de la transacción; si la comprobación falla, el pago falla.
+
+    - Todos los campos están formateados correctamente.
+    - La dirección de envío es una cuenta activada en el XRP Ledger.
+    - Todas las firmas proporcionadas son válidas para la dirección de envío.
+    - La dirección de destino es diferente que la dirección de envío.
+    - El remitente tiene suficiente XRP en balance para enviar el pago.
+
+2. El procesamiento del pago comprueba la dirección de destino; si alguna comprobación falla, el pago falla.
+
+    - Si la dirección de recepción está activada, el motor hace comprobaciones adicionales basados en sus configuraciones, como la autorización de depósito o [Deposit Authorization](../accounts/depositauth.md).
+    - Si la dirección de recepción no está activada, comprueba si el pago enviará suficiente XRP para cumplir con el mínimo del requisito de la [reserva de cuenta](../accounts/reserves.md). Si la reserva se cumple, una nueva cuenta es creada para la dirección y el balance inicial es la cantidad recibida.
+
+4. El ledger quita y acredita a las correspondientes cuentas.
+    
+    **Nota:** Al remitente también se le carga el [coste de transacción](../transactions/transaction-cost.md) en XRP.
+    
+
+## Ver también
+
+- **Tutoriales:**
+    - [Enviar XRP (Tutorial interactivo)](../../tutorials/how-tos/send-xrp.md)
+    - [Monitorizar pagos entrantes con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
+- **Referencias:**
+    - [Transacción Payment][]
+    - [Resultados de Transaction](../../references/protocol/transactions/transaction-results/index.md)
+    - [método account_info][] - para comprobar balances en XRP
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@i18n/es-ES/docs/concepts/payment-types/escrow.md

@@ -0,0 +1,96 @@
+---
+html: escrow.html
+parent: payment-types.html
+seo:
+    description: El Escrow retiene fondos hasta que las condiciones específicas se cumplan.
+labels:
+  - Escrow
+---
+# Escrow
+
+Tradicionalmente, un escrow es un contrato entre dos partes para facilitar transacciones financieras. Un tercero imparcial recibe y retiene los fondos, y solo los libera al destinatario previsto cuando se cumplen las condiciones especificadas en el contrato. Este método asegura que ambas partes cumplan con sus obligaciones.
+
+El XRP Ledger lleva el escrow un paso más allá, reemplazando al tercero con un sistema automatizado integrado en el ledger. Un escrow bloquea el XRP, que no puede ser utilizado o destruido hasta que se cumplan las condiciones.
+
+## Tipos de escrow
+
+El XRP Ledger soporta tres tipos de escrow:
+
+- **Escrow basado en el tiempo:** Los fondos solo están disponibles después de que haya pasado cierta cantidad de tiempo.
+- **Escrow condicional:** Este escrow se crea con una condición correspondiente y un cumplimiento. La condición sirve como un bloqueo en los fondos y no se liberará hasta que se proporcione la clave de cumplimiento correcta.
+- **Escrow combinado:** Este escrow combina las características de un escrow basado en el tiempo y uno condicional. El escrow es completamente inaccesible hasta que pase el tiempo especificado, después de lo cual los fondos pueden ser liberados proporcionando el cumplimiento correcto.
+
+## Ciclo de vida de un escrow
+
+1. El remitente crea un escrow utilizando la transacción `EscrowCreate`. Esta transacción define:
+
+    - Una cantidad de XRP para bloquear.
+    - Las condiciones para liberar el XRP.
+    - El destinatario del XRP.
+
+2. Cuando se procesa la transacción, el XRP Ledger crea un objeto `Escrow` que retiene el XRP en el escrow.
+
+3. El destinatario envía una transacción `EscrowFinish` para entregar el XRP. Si las condiciones se han cumplido, esto destruye el objeto `Escrow` y entrega el XRP al destinatario.
+
+    **Nota:** Si el escrow tiene una fecha de caducidad y no se completa con éxito antes de este tiempo, el escrow se caduca. Un escrow caducado permanece en el ledger hasta que una transacción `EscrowCancel` lo cancele, destruyendo el objeto `Escrow` y devuelve el XRP al remitente.
+
+## Estados del escrow
+
+El siguiente diagrama muestra los estados por los que puede pasar un escrow:
+
+[![El diagrama de estados muestra al escrow pasar desde  Retenido → Preparado/Condicionalmente preparado → Caducado](/docs/img/escrow-states.png)](/docs/img/escrow-states.png)
+
+El diagrama muestra tres casos diferentes para tres posibles combinaciones de los escrows de tiempo "terminar trás" (campo `FinishAfter`), cripto-condición (campo `Condition`), y tiempo de caducidad (campo `CancelAfter`):
+
+- **Escrow basado en el tiempo (izquierda):** Con solo un tiempo de finalización, el escrow se crea en el estado **Retenido**. Después de que haya pasado un tiempo especificado, se convierte en **Preparado** y cualquiera puede finalizarlo. Si el escrow tiene una fecha de caducidad y nadie finaliza el escrow antes de que el tiempo pase, entonces el escrow pasa a estar **Caducado**. En el estado de caducado, un escrow no puede finalizarse, y cualquiera puede cancelarlo. Si el escrow no tiene un campo `CancelAfter`, nunca caduca y nunca puede cancelarse.
+
+- **Escrow combinado (centro):** Si el escrow especifica tanto como una criptocondición (campo `Condition`) _y_ una fecha "terminar tras" (campo `FinishAfter`), el escrow es **Retenido** hasta que la fecha "terminar-tras" ha pasado. Luego se convierte en **Condicionalmente preparado**, y puede finalizarlo si se suministra el cumplimiento correcto de la criptocondición. Si el escrow tiene una fecha de caducidad (campo `CancelAfter`), y nadie lo completa antes de que pase ese tiempo, entonces el escrow se convierte en **Caducado**. En el estado de caducado, un escrow no se puede finalizar, y cualquiera puede cancelarlo. Si el escrow no tiene un campo `CancelAfter`, nunca caducará y no podrá ser cancelado.
+
+- **Escrow condicional (derecha):** Si el escrow especifica una criptocondición (campo `Condition`) y no por una fecha "terminar trás", el escrow se convierte en **Condicionalmente preparado** inmediatamente cuando se crea. Durante este tiempo, cualquiera puede finalizar el escrow, pero solo si suministran el cumplimiento correcto a la criptocondición. Si nadie finaliza el escrow antes de la fecha de caducidad (campo `CancelAfter`), el escrow se convierte en **Caducado**. (Un escrow sin una fecha de "finalizar-tras" _debe_ tener una fecha de caducidad.) En el estado de caducado, el escrow no puede ser finalizado, y cualquiera puede cancelarlo.
+
+
+## Limitaciones
+
+- El escrow solo funciona con XRP, no con tokens.
+- Los costes pueden hacerlo poco práctico para cantidades pequeñas.
+    - El escrow requiere de dos transacciones: una para crear el escrow, y una para finalizarlo o cancelarlo. Las criptocondiciones incurren en un [coste de transacción](../transactions/transaction-cost.md) mayor al usual.
+    - Mientras que el escrow no se completa, el remitente es responsable del [requisito de reserva](../accounts/reserves.md) del objeto del `Escrow`.
+- No puedes crear un escrow con valores de fechas pasados.
+- Las liberaciones y caducidad se resuelven en [tiempos de cierre de ledgers](../ledgers/ledger-close-times.md). En la práctica, los tiempos de liberaciones o caducidad pueden variar en 5 segundos respecto a los cierres de ledgers.
+- El único tipo de criptocondición aceptado es PREIMAGE-SHA-256.
+
+
+## Coste de la transacción EscrowFinish
+
+Cuando uses criptocondiciones, la transacción EscrowFinish debe pagar un [mayor coste de transacción](../transactions/transaction-cost.md#special-transaction-costs) por la carga de procesamiento involucrada en la verificación de la criptocondición introducida.
+
+El coste de transacción adicional requerido es proporcional al tamaño de la condición introducida. Si la transacción es multi-firma o [multi-signed](../accounts/multi-signing.md), el coste de la multi-firma es añadido al coste de la introducción de la condición.
+
+Actualmente, un EscrowFinish con introducción requiere un mínimo de coste de transacción de **330 [drops de XRP](../../references/protocol/data-types/basic-data-types.md#specifying-currency-amounts) más 10 drops por cada 16 bytes del tamaño de la introducción**.
+
+**Nota:** La fórmula de arriba está basada en la asunción de que el coste de referencia de la transacción es 10 drops de XRP.
+
+Si el [coste de votar](../consensus-protocol/fee-voting.md) cambia el valor de `reference_fee`, la fórmula escala basado en el nuevo coste de referencia. La fórmula general de una transacción EscrowFinish con un crypto-cumplimiento es como sigue:
+
+```
+reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
+```
+
+
+
+## Ver también
+
+Para más información sobre Escrow en el XRP Ledger, consulta lo siguiente:
+
+- [Tutoriales Escrow](../../tutorials/how-tos/use-specialized-payment-types/use-escrows/index.md)
+- [Referencia de transacciones](../../references/protocol/transactions/index.md)
+    - [Transacción EscrowCreate][]
+    - [Transacción EscrowFinish][]
+    - [Transacción EscrowCancel][]
+- [Referencia Ledger](../../references/protocol/ledger-data/index.md)
+    - [Objeto Escrow](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)
+
+
+Para más información sobre el bloqueo de 55 mil millones de Ripple, consulta [Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/).
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@i18n/es-ES/docs/concepts/payment-types/index.md

@@ -0,0 +1,16 @@
+---
+html: payment-types.html
+parent: concepts.html
+metadata:
+  indexPage: true
+seo:
+    title: Point-to-Point & Specialized Ledger Payment Types
+    description: Mientras que el XRP Ledger admite pagos XRP de punto a punto, también es compatible con tipos de pago más especializados. Descubre qué métodos de pago del ledger aquí.
+---
+# Ledger Payment Types
+
+
+El XRP Ledger admite pagos de XRP de punto a punto junto con otros tipos de pago más especializados.
+
+
+{% child-pages /%}

@i18n/es-ES/docs/concepts/payment-types/partial-payments.md

@@ -0,0 +1,140 @@
+---
+html: partial-payments.html
+parent: payment-types.html
+seo:
+    description: Los pagos parciales restan costes a la cantidad enviada, entregando una cantidad flexible. Los pagos parciales son útiles para devolver pagos no deseados sin incurrir en costes adicionales.
+labels:
+  - Pagos
+  - Seguridad
+---
+# Pagos parciales
+
+El remitente de cualquier [transacción de pago][] puede habilitar el [flag de"Partial Payment"](../../references/protocol/transactions/types/payment.md#payment-flags) y enviar un pago que entregue menos de lo que indica el campo `Amount`. Al procesar cualquier Pago, utiliza el campo de metadatos `delivered_amount`, no el campo `Amount`. El `delivered_amount` es la cantidad que un pago realmente entregó.
+
+Si un Pago no habilita el flag de Pago Parcial, el campo `Amount` de una [transacción Payment][] en el XRP Ledger especifica la cantidad a entregar después de cobrar por tasas de cambio y [costes de transferencia](../tokens/transfer-fees.md). El flag de Pago Parcial ([`tfPartialPayment`](../../references/protocol/transactions/types/payment.md#payment-flags)) permite que un pago tenga éxito al reducir la cantidad recibida en lugar de aumentar la cantidad enviada. Los pagos parciales son útiles para [devolver pagos](bouncing-payments.md) sin incurrir en costos adicionales para uno mismo.
+
+La cantidad de XRP utilizada para el [coste de transacción](../transactions/transaction-cost.md) siempre se deduce de la cuenta del remitente, independientemente del tipo de transacción. Este coste de transacción, o comisión, no se incluye en la `Amount`.
+
+Los pagos parciales se pueden utilizar para explotar integraciones ingenuas con el XRP Ledger para robar dinero de exchanges y gateways. La sección [Explotación de Pagos Parciales](#exploit-de-pagos-parciales) de este documento describe cómo funciona esta explotación y cómo puedes evitarla.
+
+## Semántica
+
+### Sin pagos parciales
+
+Al enviar un Pago que no utiliza el flag de Pago Parcial, el campo `Amount` de la transacción especifica la cantidad exacta a entregar, y el campo `SendMax` especifica la cantidad máxima y la divisa a enviar. Si un pago no puede entregar la cantidad completa de `Amount` sin exceder el parámetro `SendMax`, o si la cantidad completa no se puede entregar por cualquier otro motivo, la transacción falla. Si el campo `SendMax` se omite de las instrucciones de la transacción, se considera igual a la `Amount`. En este caso, el pago solo puede tener éxito si la cantidad total de las tarifas es 0.
+
+En otras palabras:
+
+```
+Cantidad + (costes) = (cantidad enviada) ≤ SendMax
+```
+
+En esta fórmula, "costes" o fees se refiere a [costes de transferencia](../tokens/transfer-fees.md) y tipos de cambio de las divisas. La "cantidad enviada" y la cantidad enviada (`Amount`) pueden estar denominadas en distintas divisas y convertirse por la consumición de Ofertas en el exchange descentralizado del XRP Ledger.
+
+**Nota:** El campo `Fee` de la transacción se refiere al [coste de transacción](../transactions/transaction-cost.md) en XRP, que se destruye para enviar la transacción a la red. El coste de transacción exacto especificado se carga siempr al remitente y se separa completamente de los cálculos de costes para cualquier tipo de pago.
+
+### Con pagos parciales
+
+Cuando se envía un Pago que tiene habilitado el flag de Pago Parcial, el campo `Amount` de la transacción especifica una cantidad máxima a entregar. Los pagos parciales pueden tener éxito al enviar _parte_ del valor previsto a pesar de limitaciones que incluyen costes, falta de liquidez, falta de espacio en las líneas de confianza (trustlines) de la cuenta receptora, u otras razones.
+
+El campo opcional `DeliverMin` especifica una cantidad mínima a entregar. El campo `SendMax` funciona de la misma manera que con los pagos no parciales. La transacción de pago parcial tiene éxito si entrega cualquier cantidad igual o mayor que el campo `DeliverMin` sin exceder la cantidad `SendMax`. Si el campo `DeliverMin` no está especificado, un pago parcial puede tener éxito al entregar cualquier cantidad positiva.
+
+En otras palabras:
+
+```
+Cantidad ≥ (Cantidad enviada) = SendMax - (Costes) ≥ DeliverMin > 0
+```
+
+### Limitaciones de los pagos parciales
+
+Los pagos parciales tienen las siguientes limitaciones:
+
+- Un pago parcial no puede proporcionar el XRP para crear una dirección; en este caso se devuelve el [código de resultado][] `telNO_DST_PARTIAL`.
+- Pagos directoss de XRP a XRP no pueden ser pagos parciales; este caso devuelve el [código de resultado][] `temBAD_SEND_XRP_PARTIAL`.
+    - Sin embargo, los pagos entre divisas que involucran a XRP como una de las divisas _pueden_ ser pagos parciales.
+
+[código de resultado]: ../../references/protocol/transactions/transaction-results/index.md
+
+### El campo `delivered_amount`
+
+Para ayudar a entender cuánto entregó realmente un pago parcial, los metadatos de una transacción de Pago exitosa incluyen un campo `delivered_amount`. Este campo describe la cantidad realmente entregada, en el [mismo formato](../../references/protocol/data-types/basic-data-types.md#specifying-currency-amounts) que el campo `Amount`.
+
+Para pagos no parciales, el campo `delivered_amount` de los metadatos de la transacción es igual al campo `Amount` de la transacción. Cuando un pago entrega [tokens](../tokens/index.md), el campo `delivered_amount` puede ser ligeramente diferente al campo `Amount` debido al redondeo.
+
+La cantidad entregada **no está disponible** para transacciones que cumplen **ambos** de los siguientes criterios:
+
+- Es un pago parcial
+- Está incluido en un ledger validado anterior al 20 de enero de 2014
+
+Si ambas condiciones son verdaderas, entonces `delivered_amount` contiene el valor del string `unavailable` en lugar de una cantidad real. Si esto ocurre, solo puedes determinar la cantidad entregada real leyendo los `AffectedNodes` en los metadatos de la transacción. Si la transacción entregó tokens y el `issuer` del `Amount` es la misma cuenta que la dirección `Destination`, la cantidad entregada puede dividirse entre varios miembros de `AffectedNodes` que representan líneas de confianza (trustlines) con distintas contrapartes.
+
+Puedes encontrar el campo `delivered_amount` en los siguientes lugares:
+
+| API | Método | Campo |
+|-----|--------|-------|
+| [JSON-RPC / WebSocket][] | [método account_tx][] | `result.transactions` miembros del array `meta.delivered_amount` |
+| [JSON-RPC / WebSocket][] | [método tx][] | `result.meta.delivered_amount` |
+| [JSON-RPC / WebSocket][] | [método transaction_entry][] | `result.metadata.delivered_amount` |
+| [JSON-RPC / WebSocket][] | [método ledger][] (con las transacciones ampliadas) | `result.ledger.transactions` miembros del array `metaData.delivered_amount` |
+| [WebSocket][] | [subscripciones Transaction](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#transaction-streams) | Mensajes de subscripción de `meta.delivered_amount` |
+| ripple-lib v1.x | método `getTransaction` | `outcome.deliveredAmount` |
+| ripple-lib v1.x | método `getTransactions` | miembros del array `outcome.deliveredAmount` |
+
+[WebSocket]: ../../references/http-websocket-apis/index.md
+[JSON-RPC / WebSocket]: ../../references/http-websocket-apis/index.md
+
+## Exploit de pagos parciales
+
+Si la integración de una institución financiera con el XRP Ledger asume que el campo `Amount` de un Pago es siempre la cantidad completa entregada, actores maliciosos podrían aprovechar esa suposición para robar dinero de la institución. Este exploit puede utilizarse contra pasarelas, exchanges o comerciantes siempre que el software de esas instituciones no procese los pagos parciales correctamente.
+
+**La forma correcta de procesar las transacciones de Pago entrantes es utilizar [el campo `delivered_amount` de los metadatos](#the-delivered_amount-field),** no el campo `Amount`. De este modo, una institución nunca se equivocará sobre cuanto recibe _realmente_.
+
+
+### Pasos del escenario del Exploit
+
+Para realizar un exploit a una institución financiera vulnerable, un actor malicioso puede hacer lo siguiente:
+
+1. El actor malicioso envía una transacción de Pago a la institución. Esta transacción tiene un campo  `Amount` grande y tiene el flag de **`tfPartialPayment`** activado.
+2. El pago parcial tiene éxito (código de resultado `tesSUCCESS`) pero en realidad entrega una cantidad muy pequeña de la divisa especificada.
+3. La institución vulnerable lee el campo `Amount` sin mirar el campo `Flags` o el campo de metadatos `delivered_amount`.
+4. La institutución vulnerable acredita al actor malicioso en un sistema externo, como el propio ledger de la institución, por el `Amount` completo, a pesar de recibir solo un `delivered_amount` pequeño en el XRP Ledger.
+5. El actor malicioso retira tanto saldo como sea posible antes de que la institución vulnerable note la discrepancia.
+    - Los actores maliciosos suelen preferir convertir el saldo a otra criptomoneda como Bitcoin, porque las transacciones de blockchain suelen ser irreversibles. Con un retiro a un sistema de moneda fiduciaria, la institución financiera podría revertir o cancelar la transacción varios días después de que se ejecute inicialmente.
+    - En el caso de un exchange, el actor malicioso también puede retirar un saldo de XRP directamente de nuevo al XRP Ledger.
+
+En el caso de un comerciante, el orden de las operaciones es ligeramente diferente, pero el concepto es el mismo:
+
+1. El actor malicioso solicita comprar una gran cantidad de bienes o servicios.
+2. El comerciante vulnerable factura al actor malicioso por el precio de esos bienes o servicios.
+3. El actor malicioso envía una transacción de Pago al comerciante. Esta transacción tiene un campo `Amount` grande y tiene el flag **`tfPartialPayment`** activado.
+4. El pago parcial tiene éxito (código de resultado `tesSUCCESS`) pero entrega solo una cantidad muy pequeña de la divisa especificada.
+5. El comerciante vulnerable lee el campo `Amount` de la transacción sin mirar el campo `Flags` o el campo de los metadatos `delivered_amount`.
+6. El comerciante vulnerable trata la factura como pagada y proporciona los bienes o servicios al actor malicioso, a pesar de recibir solo una mucho menor `delivered_amount` en el XRP Ledger.
+7. El actor malicioso utiliza, revende, o se marcha con los bienes y servicios antes de que el comerciantes note la discrepancia.
+
+### Mitigaciones adicionales
+
+Utilizar [el campo `delivered_amount`](#the-delivered_amount-field) al procesar transacciones entrantes es suficiente para evitar este exploit. Aún así, prácticas de negocio proactivas adicionales también pueden evitar o mitigar la probabilidad de esta o exploits similares. Por ejemplo:
+
+- Añade chequeos adicionales a la lógica de tu negocio para procesar los retiros. Nunca proceses un retiro si el balance total que tienes en el XRP Ledger no coincide con tus activos y obligaciones esperados.
+- Sigue las directrices "Know Your Customer" y verifica estrictamente las identidades de tus clientes. Puede que reconozcas y bloquees usuarios maliciosos de antemano, o emprender acciones legales contra el actor malicioso que genera exploits a tu sistema.
+
+
+## Ver también
+
+- **Herramientas:**
+    - [Remitente de la transacción](/resources/dev-tools/tx-sender)
+- **Conceptos:**
+    - [Transacciones](../transactions/index.md)
+- **Tutoriales:**
+    - [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md)
+    - [Monitorear pagos recibidos con WebSocket](../../tutorials/http-websocket-apis/build-apps/monitor-incoming-payments-with-websocket.md)
+    - [Usar tipos de pagos especializados](../../tutorials/how-tos/use-specialized-payment-types/index.md)
+    - [Listar XRP en un Exchange](../../use-cases/defi/list-xrp-as-an-exchange.md)
+- **Referencias:**
+    - [Transacción de Pago][]
+    - [Metadatos de transacción](../../references/protocol/transactions/metadata.md)
+    - [método account_tx][]
+    - [método tx][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@i18n/es-ES/docs/concepts/payment-types/payment-channels.md

@@ -0,0 +1,52 @@
+---
+html: payment-channels.html
+parent: payment-types.html
+seo:
+    description: Los canales de pago que activan pagos XRP asíncronos rápidos que pueden dividirse en incrementos muy pequeños y liquidarse más después.
+labels:
+  - Canales de pago
+  - Smart Contracts
+---
+# Canales de pago
+
+Los Canales de Pago son una función avanzada para enviar pagos de XRP "asíncronos" que pueden dividirse en incrementos muy pequeños y liquidarse más tarde.
+
+El XRP para un canal de pago se reserva temporalmente. El remitente crea reclamaciones o _Claims_ contra el canal, que el destinatario verifica sin enviar una transacción al XRP Ledger o esperar a que se apruebe una nueva versión del ledger por [consenso](../consensus-protocol/index.md). (Este es un proceso _asíncrono_ porque ocurre separado del patrón habitual de obtener transacciones aprobadas por consenso). En cualquier momento, el destinatario puede _canjear_ una reclamación (Claim) para recibir una cantidad de XRP autorizada por esa _Claim_. Liquidar una _Claim_ de esta manera utiliza una transacción estándar del XRP Ledger, como parte del proceso de consenso habitual. Esta única transacción puede abarcar cualquier cantidad de transacciones garantizadas por _Claims_ más pequeñas.
+
+Debido a que las reclamaciones pueden verificarse individualmente pero liquidarse en bloque más adelante, los canales de pago hacen posible realizar transacciones a una velocidad limitada solo por la capacidad de los participantes para crear y verificar las firmas digitales de esas Reclamaciones. Este límite se basa principalmente en la velocidad del hardware de los participantes y la complejidad de los algoritmos de firma. Para obtener la máxima velocidad, utiliza firmas Ed25519, que son más rápidas que las firmas ECDSA secp256k1 predeterminadas del XRP Ledger. La investigación ha [demostrado la capacidad de crear más de 100.000 firmas Ed25519 por segundo y verificar más de 70.000 por segundo](https://ed25519.cr.yp.to/ed25519-20110926.pdf) en hardware estándar en 2011.
+
+
+## ¿Por qué usar canales de pago?
+
+El proceso de usar un canal de pago siempre implica dos partes, un pagador y un beneficiario. El pagador es una persona o institución que utiliza el XRP Ledger y es cliente del beneficiario. El beneficiario es una persona o empresa que recibe XRP como pago por bienes o servicios.
+
+Los Canales de Pago no especifican intrínsecamente nada sobre lo que puedes comprar y vender con ellos. Sin embargo, los tipos de bienes y servicios que son adecuados para los canales de pago son:
+
+- Cosas que pueden transmitirse casi instantaneamente, como artículos digitales
+- Cosas baratas, donde el coste de procesar una transacción es una parte no trivial del precio
+- Cosas que normalmente se compran en bloque, donde la cantidad exacta deseada no se conoce de antemano
+
+
+## Ciclo de vida de un canal de pago
+
+El siguiente diagrama resume el ciclo de vida de un canal de pago:
+
+[{% inline-svg file="/docs/img/paychan-flow.svg" /%}](/docs/img/paychan-flow.svg "Diagrama de flujo de un canal de pago")
+
+
+## Ver también
+
+- **Conceptos relacionados:**
+    - [Escrow](escrow.md), una función similar para pagos XRP condicionales de mayor valor y menor velocidad.
+- **Tutoriales y casos de uso:**
+    - [Utilizar canales de pago](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md), un tutorial que guía a través del proceso de utilizar un canal de pago.
+    - [Abrir un canal de pago para activar una red de intercambio](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/open-a-payment-channel-to-enable-an-inter-exchange-network.md)
+- **Referencias:**
+    - [Método channel_authorize][]
+    - [Método channel_verify][]
+    - [Objeto PayChannel](../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)
+    - [Transacción PaymentChannelClaim][]
+    - [Transacción PaymentChannelCreate][]
+    - [Transacción PaymentChannelFund][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

@i18n/es-ES/docs/concepts/payment-types/robustly-monitoring-for-payments.md

@@ -0,0 +1,27 @@
+---
+html: robustly-monitoring-for-payments.html
+parent: payment-types.html
+seo:
+    description: Recomendaciones para monitorizar pagos entrantes de una variedad e posibles irregularidades.
+labels:
+  - Tokens
+---
+# Monitoreo robusto de pagos
+
+Para verificar robustamente los pagos entrantes, los emisores deberían hacer lo siguiente:
+
+* Mantener un registro de la transacción y el ledger más recientemente procesados. De esta manera, si pierdes temporalmente la conectividad, sabrás hasta dónde retroceder.
+* Verificar el código de resultado de cada pago entrante. Algunos pagos ingresan al ledger para cobrar una tarifa contra el spam, incluso si fallan. Solo las transacciones con el código de resultado `tesSUCCESS` pueden cambiar saldos que no sean de XRP. Solo las transacciones de un ledger validado son definitivas.
+* Mirar los [pagos parciales](partial-payments.md). Los pagos con el flag de pago parcial activado pueden ser condierados "exitosos" si se entrega cualquier cantidad distinta a cero, incluso cantidades minúsculas.
+    * Comprobar la transacción en busca del [campo `delivered_amount`](partial-payments.md#el-campo-delivered_amount). Si está presente, el campo indica cuanto dinero _realmente_ se envió a la dirección `Destination`.
+    * En xrpl.js, puedes usar el [método `xrpl.getBalanceChanges()`](https://js.xrpl.org/modules.html#getBalanceChanges) para ver cuánto recibió cada dirección. En algunos casos, esto puede dividirse en varias partes en diferentes líneas de confianza (trustlines).
+* Algunas transacciones cambian tus balances sin ser pagos directos hacia o desde una de tus direcciones.
+
+Para simplificar las cosas para tus clientes, te recomendamos aceptar pagos tanto en tu dirección operacional como en tus direcciones de emisoras.
+
+Como precaución adicional, te recomendamos comparar los balances de tus direcciones emisoras con los fondos de garantía en tu sistema de contabilidad interna en cada nueva versión del ledger del XRP Ledger. Los saldos negativos de la dirección emisora deben coincidir con los activos que has asignado al XRP Ledger fuera de la red. Si ambos no coinciden, deberías suspender el procesamiento de pagos hacia y desde el XRP Ledger hasta que hayas resuelto la discrepancia.
+
+* Utiliza el método `gateway_balances` para comprobar tus balances.
+* Si tienes un coste de transferencia (transfer fee) establecido, entonces tus obligaciones dentro del XRP Ledger disminuyen ligeramente cada vez que otras direcciones del XRP Ledger transfieran tus tokens entre sí.
+
+Para más detalles en cómo se leen los detalles de transacciones entrantes, visita [Buscar resultados de transacciones](../transactions/finality-of-results/look-up-transaction-results.md).

@i18n/es-ES/docs/concepts/payment-types/sending-payments-to-customers.md

@@ -0,0 +1,24 @@
+---
+html: sending-payments-to-customers.html
+parent: payment-types.html
+seo:
+    description: Construye los pagos con cuidado para frustrar a los actores maliciosos.
+labels:
+  - Tokens
+---
+# Enviar pagos a clientes
+
+Cuando construyes un sistema automatizado para enviar pagos al XRP Ledger para tus clientes, debes asegurarte de que construyes los pagos cuidadosamente. Los actores maliciosos están constantemente tratando de encontrar formas de engañar a un sistema para que les pague más dinero del que debería.
+
+Generalmente, al enviar stablecoins, utilizas una [transacción Payment][]. Algunos detalles son diferentes dependiendo de si estás emitiendo tokens por primera vez o transfiriéndolos desde una cartera activa a un cliente. Cosas a tener en cuenta incluyen:
+
+- Siempre especifica tu dirección emisora como el emisor del token. De lo contrario, podrías usar accidentalmente rutas (paths) que entreguen la misma divisa emitida por otras direcciones.
+- Antes de enviar un pago al XRP Ledger, comprueba el coste del pago. Un pago desde tu dirección operacional a un cliente no debe costar más que la cantidad de destino más cualquier coste de transferencia que hayas establecido.
+- Cuando emites nuevos tokens desde tu dirección emisora, debes omitir el campo `SendMax`. De lo contrario, los usuarios malintencionados pueden configurar sus ajustes para que emitas la cantidad completa de `SendMax` en lugar de solo la `Amount` de destino prevista.
+- Cuando envías tokens _desde una cartera caliente_, debes especificar `SendMax` si tienes un coste de transferencia distinto de cero. En este caso, establece el campo `SendMax` en la cantidad especificada en el campo `Amount` más el coste de transferencia. (Puede que desees redondear ligeramente hacia arriba, en caso de que la precisión de tus cálculos no coincida exactamente con la del XRP Ledger). Por ejemplo, si envías una transacción cuyo campo `Amount` especifica 99.47 USD, y tu coste de transferencia es del 0.25%, deberías establecer el campo `SendMax` en 124.3375, o 124.34 USD si redondeas hacia arriba.
+- Omitir el campo `Paths`. Este campo es innecesario cuando se envía directamente desde el emisor, o desde una cartera caliente siempre y cuando los tokens que se envían y los que se reciben tengan el mismo código de divisa y emisor, es decir, sean la misma stablecoin. El campo `Paths` está destinado a [Pagos entre divisas](cross-currency-payments.md) y a pagos multi-salto (rippling) más largos. Si realizas una búsqueda de rutas (paths) de manera ingenua y adjuntas las rutas a tu transacción, tu pago puede tomar un camino indirecto más costoso en lugar de fallar si el camino directo no está disponible; los usuarios malintencionados incluso pueden configurar esto.
+- Si recibes un código de resultado `tecPATH_DRY`, esto suele indicar que el cliente no tiene configurada la línea de confianza (trustline) necesaria, o que los ajustes de rippling de tu emisor no están configurados correctamente.
+
+Para un tutorial detallado sobre cómo emitir un token en el XRP Ledger, ya sea una stablecoin u otro tipo, visita [Emitir un token fungible](../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md).
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}