diff --git a/concept-partial-payments.html b/concept-partial-payments.html
index 3f47ba980f..2f4f54775d 100644
--- a/concept-partial-payments.html
+++ b/concept-partial-payments.html
@@ -165,7 +165,7 @@
Partial payments can be used to exploit naive integrations with the Ripple Consensus Ledger to steal money from exchanges and gateways. The Partial Payments Exploit section of this document describes how this exploit works and how you can avoid it.
Semantics
Without Partial Payments
-When sending a Payment that does not use the Partial Payment flag, the Amount field of the transaction specifies the exact amount to deliver, and the SendMax field specifies the maximum amount and currency to send. If payment cannot deliver the full Amount without exceeding the SendMax parameter, or the full amount cannot be delivered for any other reason, the transaction fails. If the SendMax field is omitted from the transaction instructions, it is considered to be equal to the Amount. In this case, the payment can only succeed if the total amount of fees is 0.
+When sending a Payment that does not use the Partial Payment flag, the Amount field of the transaction specifies the exact amount to deliver, and the SendMax field specifies the maximum amount and currency to send. If a payment cannot deliver the full Amount without exceeding the SendMax parameter, or the full amount cannot be delivered for any other reason, the transaction fails. If the SendMax field is omitted from the transaction instructions, it is considered to be equal to the Amount. In this case, the payment can only succeed if the total amount of fees is 0.
In other words:
Amount + (fees) = (sent amount) ≤ SendMax
@@ -188,7 +188,7 @@
The delivered_amount Field
To help understand how much a partial payment actually delivered, the metadata of a successful Payment transaction includes a delivered_amount field. This field describes the amount actually delivered, in the same format as the Amount field.
-For non-partial payments, the delivered_amount field of the transaction metadata is equal to the Amount field of the transaction. When a payment delivers an issued currency, the delivered_amount may be slightly differently than the Amount field due to rounding.
+For non-partial payments, the delivered_amount field of the transaction metadata is equal to the Amount field of the transaction. When a payment delivers an issued currency, the delivered_amount may be slightly different than the Amount field due to rounding.
The delivered amount is not available for transactions that meet both of the following criteria:
- Is a partial payment
diff --git a/content/concept-partial-payments.md b/content/concept-partial-payments.md
index 80681090f5..8a75b3260d 100644
--- a/content/concept-partial-payments.md
+++ b/content/concept-partial-payments.md
@@ -10,7 +10,7 @@ Partial payments can be used to exploit naive integrations with the Ripple Conse
### Without Partial Payments
-When sending a Payment that does not use the Partial Payment flag, the `Amount` field of the transaction specifies the exact amount to deliver, and the `SendMax` field specifies the maximum amount and currency to send. If payment cannot deliver the full `Amount` without exceeding the `SendMax` parameter, or the full amount cannot be delivered for any other reason, the transaction fails. If the `SendMax` field is omitted from the transaction instructions, it is considered to be equal to the `Amount`. In this case, the payment can only succeed if the total amount of fees is 0.
+When sending a Payment that does not use the Partial Payment flag, the `Amount` field of the transaction specifies the exact amount to deliver, and the `SendMax` field specifies the maximum amount and currency to send. If a payment cannot deliver the full `Amount` without exceeding the `SendMax` parameter, or the full amount cannot be delivered for any other reason, the transaction fails. If the `SendMax` field is omitted from the transaction instructions, it is considered to be equal to the `Amount`. In this case, the payment can only succeed if the total amount of fees is 0.
In other words:
@@ -44,7 +44,7 @@ Partial Payments have the following limitations:
To help understand how much a partial payment actually delivered, the metadata of a successful Payment transaction includes a `delivered_amount` field. This field describes the amount actually delivered, in the [same format](reference-rippled.html#specifying-currency-amounts) as the `Amount` field.
-For non-partial payments, the `delivered_amount` field of the transaction metadata is equal to the `Amount` field of the transaction. When a payment delivers an issued currency, the `delivered_amount` may be slightly differently than the `Amount` field due to rounding.
+For non-partial payments, the `delivered_amount` field of the transaction metadata is equal to the `Amount` field of the transaction. When a payment delivers an issued currency, the `delivered_amount` may be slightly different than the `Amount` field due to rounding.
The delivered amount is **not available** for transactions that meet **both** of the following criteria:
diff --git a/content/reference-transaction-format.md b/content/reference-transaction-format.md
index 8c0521c25a..fa788fd23a 100644
--- a/content/reference-transaction-format.md
+++ b/content/reference-transaction-format.md
@@ -816,7 +816,7 @@ Transactions of the Payment type support additional values in the [`Flags` field
### Partial Payments
-A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for [returning payments](tutorial-gateway-guide.html#bouncing-payments) without incurring additional costs to oneself, but can also be used to exploit integrations that naively assume the `Amount` field of a successful transaction always describes the exact amount delivered.
+A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for [returning payments](tutorial-gateway-guide.html#bouncing-payments) without incurring additional costs to oneself. However, partial payments can also be used to exploit integrations that naively assume the `Amount` field of a successful transaction always describes the exact amount delivered.
A partial payment is any [Payment transaction][] with the **tfPartialPayment** flag enabled. A partial payment can be successful if it delivers any positive amount greater than or equal to its `DeliverMin` field (or any positive amount at all if `DeliverMin` is not specified) without sending more than the `SendMax` value.
diff --git a/reference-transaction-format.html b/reference-transaction-format.html
index a3af0866ab..1b6249ba2a 100644
--- a/reference-transaction-format.html
+++ b/reference-transaction-format.html
@@ -1343,7 +1343,7 @@
Partial Payments
-A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for returning payments without incurring additional costs to oneself, but can also be used to exploit integrations that naively assume the Amount field of a successful transaction always describes the exact amount delivered.
+A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for returning payments without incurring additional costs to oneself. However, partial payments can also be used to exploit integrations that naively assume the Amount field of a successful transaction always describes the exact amount delivered.
A partial payment is any Payment transaction with the tfPartialPayment flag enabled. A partial payment can be successful if it delivers any positive amount greater than or equal to its DeliverMin field (or any positive amount at all if DeliverMin is not specified) without sending more than the SendMax value.
The delivered_amount field of a payment's metadata indicates the amount of currency actually received by the destination account.
For more information, see the full article on Partial Payments.