Merge pull request #626 from mDuo13/payments_article

Direct XRP Payments article

content/concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md

@@ -0,0 +1,46 @@
+# Source and Destination Tags
+
+_Source tags_ and _destination tags_ are a feature of XRP Ledger [payments](payment-types.html) that can indicate specific purposes for payments from and to multi-purpose addresses. Source and destination tags do not have direct on-ledger functionality; source and destination tags merely provide information about how off-ledger systems should process a payment. In transactions, both source and destination tags are formatted as 32-bit unsigned integers.
+
+Destination tags indicate the beneficiary or destination for a payment. For example, a payment to an [exchange](list-xrp-in-your-exchange.html) or [gateway](become-an-xrp-ledger-gateway.html) address can use a destination tag to indicate which customer to credit for the amount of the payment in that business's own systems. A payment to a merchant could indicate what item or cart the payment is buying.
+
+Source tags indicate the originator or source of a payment. Most commonly, a Source Tag is included so that the recipient of the payment knows where to send a return, or "bounced", payment. When returning an incoming payment, you should use the source tag from the incoming payment as the destination tag of the outgoing (return) payment.
+
+The practice of giving customers the ability to send and receive transactions from your XRP Ledger address using another interface is called providing _hosted accounts_. Hosted accounts typically use source and destination tags for each customer.
+
+## Rationale
+
+In other distributed ledgers, it is common to use different deposit addresses for each customer. In the XRP Ledger, an address must be a funded, permanent [account](accounts.html) to receive payments. Using this approach in the XRP Ledger wastefully consumes resources of all servers in the network, and is costly because the [reserve](reserves.html) amount must be set aside indefinitely for each address.
+
+Source and destination tags provide a more lightweight way to map deposits and payments to individual customers.
+
+## Use Cases
+
+A business may want to use source and destination tags for several purposes:
+
+- Direct mappings to customer accounts.
+- Matching return payments to the outgoing payments that prompted them.
+- Mapping payments to quotes that expire.
+- Providing disposable tags that customers can generate for specific deposits.
+
+To prevent overlap while protecting privacy, a business can divide the total range of tags available into sections for each purpose, then assign tags in an unpredictable order within the range. For example, use a cryptographic hash function like [SHA-256](https://en.wikipedia.org/wiki/SHA-2), then use the [modulo operator](https://en.wikipedia.org/wiki/Modulo_operation) to map the output to the size of the relevant section. To be safe, check for collisions with old tags before using a new tag.
+
+Assigning tags in numerical order provides less privacy to customers. Since all XRP Ledger transactions are public, assigning tags in this way can make it possible to guess which tags correspond to various users' addresses or to derive information about users' accounts based on the tags used.
+
+
+## Requiring Tags
+
+For an XRP Ledger address that may receive payments intended for several customer accounts, receiving a payment _without_ a destination tag can be a problem: it is not immediately obvious which customer to credit, which can require a manual intervention and a discussion with the sender to figure out who was the intended recipient. To reduce cases like this, you can [enable the RequireDest setting](require-destination-tags.html). That way, if a user forgets to include a destination tag in a payment, the XRP Ledger rejects their payment instead of giving you money you don't know what to do with. The user can then send the payment again, using the tag as they should have.
+
+
+## See Also
+
+- [Require Destination Tags](require-destination-tags.html)
+- [XRP Ledger Businesses](xrp-ledger-businesses.html)
+- [Payment Types](payment-types.html)
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/concepts/payment-types/direct-xrp-payments.md

@@ -0,0 +1,85 @@
+# Direct XRP Payments
+
+The basis of any financial system is _transferring value_: or, in one word, payments. The simplest type of payment in the XRP Ledger is a direct XRP-to-XRP payment, which transfers XRP directly from one account in the XRP Ledger to another.
+
+## About Direct XRP-to-XRP Payments
+
+Generally, any address in the XRP Ledger can send XRP directly to any other address. The address on the receiving side is often called the _destination address_, and the address on the sending side is called the _source address_. To send XRP directly, the sender uses a [Payment transaction][], which can be as concise as the following:
+
+```json
+{
+  "TransactionType": "Payment",
+  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+  "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
+  "Amount": "13000000"
+}
+```
+
+These transaction instructions mean: Send a payment from rf1Bi... to ra5nK... delivering exactly 13 XRP. If the transaction is successfully processed, it does exactly that. Since it usually takes about 4 seconds for each new ledger version to become [validated](consensus.html), a successful transaction can be created, submitted, executed, and have a final outcome in 8 seconds or less, even if gets queued for the ledger version after the current in-progress one.
+
+**Caution:** The [Payment transaction type][Payment] can also be used for some more specialized kinds of payments, including [cross-currency payments](cross-currency-payments.html) and [partial payments](partial-payments.html). In the case of partial payments, it is possible that the `Amount` shows a large amount of XRP even if the transaction only delivered a very small amount. See [partial payments exploit](partial-payments.html#partial-payments-exploit) for how to avoid crediting a customer for the wrong amount.
+
+Direct XRP-to-XRP payments cannot be partial payments, but partial payments can deliver XRP after converting from a different source currency.
+
+
+## Funding Accounts
+
+Any mathematically-valid address can receive a payment, even if the XRP Ledger has no record of that address existing beforehand, as long as the payment delivers enough XRP to meet the minimum [account reserve](reserves.html). If the payment would not deliver enough XRP, it fails.
+
+For more information, see [Accounts](accounts.html#creating-accounts).
+
+
+## Address Reuse
+
+In the XRP Ledger, addresses where you can receive payments are permanent, and have a non-trivial [reserve requirement](reserves.html) of XRP that they cannot spend. This means that, contrary to some other blockchain systems, it is not a good idea to use a different, disposable address for every transaction. The best practice for the XRP Ledger is to reuse the same address for multiple transactions. If you use the address regularly (especially if it's managed by an internet-connected service), you should set a [regular key](cryptographic-keys.html) and proactively change keys on a regular basis to reduce the risk of a key compromise.
+
+As a sender, it is best not to assume that your intended recipient is using the same address from the last time you sent them a payment. Inevitably, sometimes security compromises happen and a person or business has to change addresses. Before sending money, you should ask the recipient for their current receiving address, so you don't accidentally send money to a malicious user who has taken control of a compromised old address.
+
+
+## How Direct XRP Payments Are Processed
+
+From a relatively high level, the XRP Ledger's transaction processing engine applies a direct XRP payment as follows:
+
+1. It validates the parameters of the [Payment transaction][]. If the transaction is structured to send and deliver XRP, the transaction processing engine recognizes it as a direct XRP-to-XRP payment. Validation checks include:
+
+    - Checking that all fields are formatted correctly. For example, for direct XRP payments, the `Amount` field must be [drops of XRP][].
+    - Checking that the sending address is a funded [account](accounts.html) in the XRP Ledger.
+    - Checking that all provided signatures are valid for the sending address.
+    - Confirming that the destination address is different than the sender address. (It is not sufficient to send to the same address with a different [destination tag](source-and-destination-tags.html).)
+    - Confirming that the sender has a high enough XRP balance to send the payment.
+
+    If any check fails, the payment fails.
+
+2. It checks whether the receiving address is a funded account.
+
+    - If the receiving address is funded, it checks whether the receiving address has any limitations on receiving payments, such as [DepositAuth](depositauth.html) or [RequireDest](source-and-destination-tags.html#requiring-tags). If the payment does not meet any such limitations, the payment fails.
+    - If the receiving address is not funded, it checks whether the payment would deliver enough XRP to meet the minimum [account reserve](reserves.html). If not, the payment fails.
+
+3. It debits the sending account by an amount of XRP specified by the `Amount` field plus the XRP to be destroyed for the [transaction cost](transaction-cost.html) and credits the receiving account for the same amount.
+
+    If necessary, it creates a new account ([AccountRoot object](accountroot.html)) for the receiving address. The new account's starting balance is equal to the `Amount` of the payment.
+
+    The engine adds a `delivered_amount` field to the [transaction's metadata](transaction-metadata.html) to indicate how much was delivered. You should always use `delivered_amount`, **not** the `Amount` field, to avoid being tricked about how much XRP you received. (Cross-currency "Partial Payments" can deliver less XRP than stated in the `Amount` field.) For more information, see [Partial Payments](partial-payments.html).
+
+
+## Comparison to Other Payment Types
+
+- **Direct XRP Payments** are the only way to both send and receive XRP in a single transaction. They are a good balance of speed, simplicity, and low cost.
+- [Cross-currency payments](cross-currency-payments.html) also use the [Payment][] transaction type, but can send any combination of XRP and non-XRP [issued currencies](issued-currencies.html) except XRP-to-XRP. They can also be [partial payments](partial-payments.html). Cross-currency payments are good for payments not denominated in XRP or for taking arbitrage opportunities in the [decentralized exchange](decentralized-exchange.html).
+- [Checks](checks.html) :not_enabled: let the sender set up an obligation without transferring any money immediately. The recipient can cash it any time before it expires, but the amount is not guaranteed. Checks can send either XRP or issued currencies. Checks are good for giving the recipient the autonomy to claim the payment.
+- [Escrow](escrow.html) sets aside XRP which can be claimed by its intended recipient when certain conditions are met. The XRP amount is fully guaranteed and cannot be otherwise used by the sender unless the Escrow expires. Escrow is good for smart contracts in large amounts.
+- [Payment Channels](payment-channels.html) set aside XRP. The recipient can claim XRP from the channel in bulk using signed authorizations. Individual authorizations can be verified without sending a full XRP Ledger transaction. Payment channels are good for extremely high-volume micropayments or "streaming" payments.
+
+
+## See Also
+
+- [Payment System Basics](payment-system-basics.html)
+- [Payment transaction type][Payment transaction]
+- [Transaction Results](transaction-results.html)
+- [Send XRP (Interactive Tutorial)](send-xrp.html)
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/references/rippled-api/transaction-formats/transaction-types/payment.md

@@ -1,7 +1,7 @@
 # Payment
 [[Source]<br>](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/transactors/Payment.cpp "Source")
 
-A Payment transaction represents a transfer of value from one account to another. (Depending on the path taken, this can involve additional exchanges of value, which occur atomically.)
+A Payment transaction represents a transfer of value from one account to another. (Depending on the path taken, this can involve additional exchanges of value, which occur atomically.) This transaction type can be used for several [types of payments](#types-of-payments).
 
 Payments are also the only way to [create accounts](#creating-accounts).
 
@@ -37,6 +37,24 @@ Payments are also the only way to [create accounts](#creating-accounts).
 | SendMax        | [Currency Amount][]  | Amount            | _(Optional)_ Highest amount of source currency this transaction is allowed to cost, including [transfer fees](transfer-fees.html), exchange rates, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). Does not include the [XRP destroyed as a cost for submitting the transaction](transaction-cost.html). For non-XRP amounts, the nested field names MUST be lower-case. Must be supplied for cross-currency/cross-issue payments. Must be omitted for XRP-to-XRP payments. |
 | DeliverMin     | [Currency Amount][]  | Amount            | _(Optional)_ Minimum amount of destination currency this transaction should deliver. Only valid if this is a [partial payment](partial-payments.html). For non-XRP amounts, the nested field names are lower-case. |
 
+## Types of Payments
+
+The Payment transaction type is a general-purpose tool that can represent several different types of abstract actions. You can identify the transaction type based on the transaction's fields, as described in the table below:
+
+| Payment type                              | `Amount`                        | `SendMax`                       | `Paths`          | `Address` = `Destination`? | Description |
+|:------------------------------------------|:--------------------------------|:--------------------------------|:-----------------|:--|
+| [Direct XRP-to-XRP Payment][]             | String (XRP)                    | Omitted                         | Omitted          | No | Transfers XRP directly from one account to another. Always delivers the exact amount. No fee applies other than the basic [transaction cost](transaction-cost.html). |
+| [Creating or redeeming issued currency][] | Object                          | Object (optional)               | Optional         | No | Increases or decreases the amount of a non-XRP currency or asset tracked in the XRP Ledger. [Transfer fees](transfer-fees.html) and [freezes](freezes.html) do not apply when sending and redeeming directly. |
+| [Cross-currency Payment][]                | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Usually required | No | Send issued currency from one holder to another. The `Amount` and `SendMax` cannot _both_ be XRP. These payments [ripple through](rippling.html) the issuer and can take longer [paths](paths.html) through several intermediaries if the transaction specifies a path set. [Transfer fees](transfer-fees.html) set by the issuer(s) apply to this type of transaction. These transactions consume offers in the [decentralized exchange](decentralized-exchange.html) to connect between different currencies, or possibly even between currencies with the same currency code and different issuers. |
+| [Partial payments][]                      | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Usually required | No | Sends _up to_ a specific amount of any currency. Uses the [tfPartialPayment flag](#payment-flags). May include a `DeliverMin` amount specifying the minimum that the transaction must deliver to be successful; if the transaction does not specify `DeliverMin`, it can succeed by delivering _any positive amount_. |
+| Currency conversion                       | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Required         | Yes | Consumes offers in the [decentralized exchange](decentralized-exchange.html) to convert one currency to another, possibly taking [arbitrage](https://en.wikipedia.org/wiki/Arbitrage) opportunities. The `Amount` and `SendMax` cannot both be XRP. Also called a _circular payment_ because it delivers money to the sender. The [Data API](data-api.html) tracks this type of transaction as an "exchange" and not a "payment". |
+
+[Direct XRP-to-XRP Payment]: direct-xrp-payments.html
+[Creating or redeeming issued currency]: issued-currencies-overview.html
+[Cross-currency Payment]: cross-currency-payments.html
+[Partial payments]: partial-payments.html
+
+
 ## Special issuer Values for SendMax and Amount
 
 Most of the time, the `issuer` field of a non-XRP [Currency Amount][] indicates a financial institution's [issuing address](issuing-and-operational-addresses.html). However, when describing payments, there are special rules for the `issuer` field in the `Amount` and `SendMax` fields of a payment.

content/tutorials/manage-account-settings/require-destination-tags.md

@@ -0,0 +1,70 @@
+# Require Destination Tags
+
+The `RequireDest` setting (`requireDestinationTag` in RippleAPI) is designed to prevent customers from sending payments to your address if they forgot the [destination tag](source-and-destination-tags.html) that identifies who should be credited for the payment. When enabled, the XRP Ledger rejects any payment to your address that does not specify a destination tag.
+
+The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the `RequireDest` flag:
+
+Request:
+
+```
+POST http://localhost:5005/
+Content-Type: application/json
+{
+    "method": "submit",
+    "params": [
+        {
+            "secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
+            "tx_json": {
+                "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                "Fee": "15000",
+                "Flags": 0,
+                "SetFlag": 1,
+                "TransactionType": "AccountSet"
+            }
+        }
+    ]
+}
+```
+
+{% include '_snippets/secret-key-warning.md' %}
+<!--{#_ #}-->
+
+Response:
+
+```
+200 OK
+
+{
+   "result" : {
+      "deprecated" : "Signing support in the 'submit' command has been deprecated and will be removed in a future version of the server. Please migrate to a standalone signing tool.",
+      "engine_result" : "tesSUCCESS",
+      "engine_result_code" : 0,
+      "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
+      "status" : "success",
+      "tx_blob" : "12000322000000002400000179202100000001684000000000003A98732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB7446304402201C430B4C29D0A0AB94286AE55FB9981B00F84C7985AF4BD44570782C5E0C5E290220363B68B81580231B32176F8C477B822ECB9EC673B84237BEF15BE6F59108B97D81144B4E9C06F24296074F7BC48F92A97916C6DC5EA9",
+      "tx_json" : {
+         "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+         "Fee" : "15000",
+         "Flags" : 0,
+         "Sequence" : 377,
+         "SetFlag" : 1,
+         "SigningPubKey" : "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
+         "TransactionType" : "AccountSet",
+         "TxnSignature" : "304402201C430B4C29D0A0AB94286AE55FB9981B00F84C7985AF4BD44570782C5E0C5E290220363B68B81580231B32176F8C477B822ECB9EC673B84237BEF15BE6F59108B97D",
+         "hash" : "3F2B233907BE9EC51AE1C822EC0B6BB0965EFD2400B218BE988DDA9529F53CA4"
+      }
+   }
+}
+```
+
+## See Also
+
+- [Source and Destination Tags](source-and-destination-tags.html)
+- [XRP Ledger Businesses](xrp-ledger-businesses.html)
+- [Payment Types](payment-types.html)
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md

@@ -287,11 +287,10 @@ Processing payments to and from the XRP Ledger naturally comes with some risks,
 - Track your obligations and balances within the XRP Ledger, and compare with the assets in your collateral account. If they do not match up, stop processing withdrawals and deposits until you resolve the discrepancy.
 - Avoid ambiguous situations. We recommend the following:
     - Enable the [`DisallowXRP` flag](#disallowxrp) for the issuing address and all operational addresses, so customers do not accidentally send you XRP. (Private exchanges should *not* set this flag, since they trade XRP normally.)
-    - Enable the [`RequireDest` flag](#requiredest) for the issuing address and all operational addresses, so customers do not accidentally send a payment without the destination tag to indicate who should be credited.
+    - Enable the [`RequireDest` flag](require-destination-tags.html) for the issuing address and all operational addresses, so customers do not accidentally send a payment without the destination tag to indicate who should be credited.
     - Enable the [`RequireAuth` flag](#requireauth) on all operational addresses so they cannot issue currency by accident.
 - Monitor for suspicious or abusive behavior. For example, a user could repeatedly send funds into and out of the XRP Ledger, as a denial of service attack that effectively empties an operational address's balance. Suspend customers whose addresses are involved in suspicious behavior by not processing their XRP Ledger payments.
 
-
 ## Trading on Ripple
 
 After the issuances have been created in the XRP Ledger, they can be freely transferred and traded by XRP Ledger users. There are several consequences of this situation:
@@ -322,7 +321,7 @@ For more information, see the [Freeze article](freezes.html).
 
 ## Authorized Trust Lines
 
-The XRP Ledger's Authorized Trust Lines feature (formerly called "Authorized Accounts") enables a gateway to limit who can hold that gateway's issuances, so that unknown XRP Ledger addresses cannot hold the currency the gateway issues. Ripple feels this is *not necessary* in most cases, since gateways have full control over the process of redeeming Ripple balances for value in the outside world. (You can collect customer information and impose limits on withdrawals at that stage without worrying about what happens within the XRP Ledger.)
+The XRP Ledger's Authorized Trust Lines feature (formerly called "Authorized Accounts") enables a gateway to limit who can hold that gateway's issuances, so that unknown XRP Ledger addresses cannot hold the currency the gateway issues. Ripple feels this is *not necessary* in most cases, since gateways have full control over the process of redeeming XRP Ledger balances for value in the outside world. (You can collect customer information and impose limits on withdrawals at that stage without worrying about what happens within the XRP Ledger.)
 
 For more information, see [Authorized Trust Lines](authorized-trust-lines.html).
 
@@ -333,14 +332,11 @@ For more information, see [Authorized Trust Lines](authorized-trust-lines.html).
 
 Similarly, *Source Tags* indicate the originator or source of a payment. Most commonly, a Source Tag is included so that the recipient of the payment knows where to bounce the payment. When you bounce an incoming payment, use the Source Tag from the incoming payment as the Destination Tag of the outgoing (bounce) payment.
 
-We recommend providing several kinds of Destination Tags for different purposes:
+Ripple recommends making a user interface to generate a destination tag on-demand when a customer intends to send money to the gateway. You should consider that destination tag valid only for a payment with the expected amount. Later, bounce any other transactions that reuse the same destination tag.
 
-* Direct mappings to customer accounts
+Enable the [RequireDest](require-destination-tags.html) flag on your issuing and operational addresses so that customers must use a destination tag to indicate where funds should go when they send XRP Ledger payments to your gateway.
-* Matching the Source Tags on outgoing payments (in case your payments get bounced)
-* Tags for quotes, which expire
-* Other disposable destination tags that customers can generate.
 
-See [Generating Source and Destination Tags](#generating-source-and-destination-tags) for recommendations on the technical details of making and using Source Tags and Destination Tags.
+For more information, see [Source and Destination Tags](source-and-destination-tags.html).
 
 
 ## Gateway Bulletins
@@ -446,18 +442,6 @@ Response:
 To confirm that an address has DefaultRipple enabled, look up the address using the [account_info method][], specifying a validated ledger version. Use [a bitwise-AND operator](https://en.wikipedia.org/wiki/Bitwise_operation#AND) to compare the `Flags` field with 0x00800000 (the [ledger flag lsfDefaultRipple](accountroot.html#accountroot-flags)). If the result of the bitwise-AND operation is nonzero, then the address has DefaultRipple enabled.
 
 
-## Generating Source and Destination Tags
-
-You need a scheme to create Source and Destination tags for your customers and payments. (See [Source and Destination Tags](#source-and-destination-tags) for an explanation of what Source and Destination Tags are.)
-
-For greater privacy and security, we recommend *not* using monotonically-incrementing numbers as destination tags that correlate 1:1 with customers. Instead, we recommend using convenient internal IDs, but mapping those to destination tags using a quick hash or cipher function such as [Hasty Pudding](http://en.wikipedia.org/wiki/Hasty_Pudding_cipher). You should set aside ranges of internal numbers for different uses of destination tags.
-
-After passing the internal numbers through your hash function, you can use the result as a destination tag. To be safe, you should check for collisions. Do not reuse destination tags unless they have explicit expiration dates (like quotes and customer-generated tags).
-
-We recommend making a user interface to generate a destination tag on-demand when a customer intends to send money to the gateway. Then, consider that destination tag valid only for a payment with the expected amount. Later, bounce any other transactions that reuse the same destination tag.
-
-Enable the [RequireDest](#requiredest) flag on your issuing and operational addresses so that customers must use a destination tag to indicate where funds should go when they send XRP Ledger payments to your gateway.
-
 
 ## DisallowXRP
 
@@ -517,65 +501,6 @@ Response:
 ```
 
 
-## RequireDest
-
-The `RequireDest` setting (`requireDestinationTag` in RippleAPI) is designed to prevent customers from sending payments to your address while accidentally forgetting the [destination tag](#source-and-destination-tags) that identifies who should be credited for the payment. When enabled, the XRP Ledger rejects any payment to your address that does not specify a destination tag.
-
-We recommend enabling the `RequireDest` flag on all gateway issuing and operational addresses.
-
-The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the `RequireDest` flag:
-
-Request:
-
-```
-POST http://localhost:5005/
-Content-Type: application/json
-{
-    "method": "submit",
-    "params": [
-        {
-            "secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
-            "tx_json": {
-                "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-                "Fee": "15000",
-                "Flags": 0,
-                "SetFlag": 1,
-                "TransactionType": "AccountSet"
-            }
-        }
-    ]
-}
-```
-
-{% include '_snippets/secret-key-warning.md' %}
-<!--{#_ #}-->
-
-Response:
-
-```
-200 OK
-{
-	"result": {
-		"engine_result": "tesSUCCESS",
-		"engine_result_code": 0,
-		"engine_result_message": "The transaction was applied. Only final in a validated ledger.",
-		"status": "success",
-		"tx_blob": "12000322000000002400000161202100000003684000000000003A98732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100CD9A87890ADFAC49B8F69EDEC4A0DB99C86667883D7579289B06DAA4B81BF87E02207AC3FEEA518060AB2B538D330614D2594F432901F7C011D7EB92F74383E5340F81144B4E9C06F24296074F7BC48F92A97916C6DC5EA9",
-		"tx_json": {
-			"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
-			"Fee": "15000",
-			"Flags": 0,
-			"Sequence": 353,
-			"SetFlag": 3,
-			"SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
-			"TransactionType": "AccountSet",
-			"TxnSignature": "3045022100CD9A87890ADFAC49B8F69EDEC4A0DB99C86667883D7579289B06DAA4B81BF87E02207AC3FEEA518060AB2B538D330614D2594F432901F7C011D7EB92F74383E5340F",
-			"hash": "59025DD6C9848679BA433448A1DD95833F2F4B64B03E214D074C7A5B6E3E3E70"
-		}
-	}
-}
-```
-
 ## RequireAuth
 
 The `RequireAuth` setting prevents all counterparties from holding balances issued by an address unless the address has specifically approved an accounting relationship with that counterparty. For more information, see [Authorized Trust Lines](authorized-trust-lines.html).

dactyl-config.yml

@@ -249,60 +249,88 @@ pages:
         targets:
             - local
 
-    # TODO: "Source and Destination Tags" stand-alone document
+    -   md: concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md
+        html: source-and-destination-tags.html
+        funnel: Docs
+        doc_type: Concepts
+        category: Payment System Basics
+        subcategory: Transaction Basics
+        blurb: Use source and destination tags to indicate specific purposes for payments from and to multi-purpose addresses
+        targets:
+            - local
 
+    -   name: Payment Types
+        html: payment-types.html
+        funnel: Docs
+        doc_type: Concepts
+        category: Payment Types
+        template: template-landing-children.html
+        blurb: The XRP Ledger supports point-to-point XRP payments alongside other, more specialized payment types.
+        targets:
+            - local
+
+        # Redirect from the old landing name/URL
     -   name: Complex Payment Types
         html: complex-payment-types.html
         funnel: Docs
         doc_type: Concepts
-        category: Complex Payment Types
+        category: Payment Types
-        template: template-landing-children.html
+        template: template-redirect.html
-        blurb: In addition to simple point-to-point XRP Payments, the XRP Ledger supports a number of complex payment types for a variety of use cases and situations.
+        redirect_url: payment-types.html
         targets:
             - local
 
-    -   md: concepts/complex-payment-types/cross-currency-payments.md
+    -   md: concepts/payment-types/direct-xrp-payments.md
+        html: direct-xrp-payments.html
+        funnel: Docs
+        doc_type: Concepts
+        category: Payment Types
+        blurb: Direct XRP payments are the simplest way to send value in the XRP Ledger.
+        targets:
+            - local
+
+    -   md: concepts/payment-types/cross-currency-payments.md
         html: cross-currency-payments.html
         funnel: Docs
         doc_type: Concepts
-        category: Complex Payment Types
+        category: Payment Types
         blurb: Cross-currency payments atomically deliver a different currency than they send by converting through paths and order books.
         targets:
             - local
 
-    -   md: concepts/complex-payment-types/checks.md
+    -   md: concepts/payment-types/checks.md
         html: checks.html
         funnel: Docs
         doc_type: Concepts
-        category: Complex Payment Types
+        category: Payment Types
         blurb: Checks let users create deferred payments that can be canceled or cashed by the intended recipients.
         status: not_enabled
         targets:
             - local
 
-    -   md: concepts/complex-payment-types/escrow.md
+    -   md: concepts/payment-types/escrow.md
         html: escrow.html
         funnel: Docs
         doc_type: Concepts
-        category: Complex Payment Types
+        category: Payment Types
         blurb: Escrows set aside XRP and deliver it later when certain conditions are met. Escrows can depend on time limits, cryptographic conditions, or both.
         targets:
             - local
 
-    -   md: concepts/complex-payment-types/partial-payments.md
+    -   md: concepts/payment-types/partial-payments.md
         html: partial-payments.html
         funnel: Docs
         doc_type: Concepts
-        category: Complex Payment Types
+        category: Payment Types
         blurb: Partial payments subtract fees from the amount sent, delivering a flexible amount. Partial payments are useful for returning unwanted payments without incurring additional costs.
         targets:
             - local
 
-    -   md: concepts/complex-payment-types/payment-channels.md
+    -   md: concepts/payment-types/payment-channels.md
         html: payment-channels.html
         funnel: Docs
         doc_type: Concepts
-        category: Complex Payment Types
+        category: Payment Types
         blurb: Payment Channels enable fast, asynchronous XRP payments that can be divided into very small increments and settled later.
         targets:
             - local
@@ -775,15 +803,35 @@ pages:
         targets:
             - local
 
+    -   md: tutorials/manage-account-settings/require-destination-tags.md
+        html: require-destination-tags.html
+        funnel: Docs
+        doc_type: Tutorials
+        category: Manage Account Settings
+        blurb: Require users to specify a destination tag when sending to your address.
+        targets:
+            - local
+
     # TODO: "Use Deposit Authorization to Block Unwanted Payments" (DOC-1555)
 
+    -   name: Use Specialized Payment Types
+        html: use-specialized-payment-types.html
+        funnel: Docs
+        doc_type: Tutorials
+        category: Use Specialized Payment Types
+        template: template-landing-children.html
+        blurb: Use advanced features like Escrow and Payment Channels to build smart applications on the XRP Ledger.
+        targets:
+            - local
+
+        # Redirect from old "complex" payment types URL
     -   name: Use Complex Payment Types
         html: use-complex-payment-types.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
-        template: template-landing-children.html
+        template: template-redirect.html
-        blurb: Use advanced features like Escrow and Payment Channels to build smart applications on the XRP Ledger.
+        redirect_url: use-specialized-payment-types.html
         targets:
             - local
 
@@ -791,7 +839,7 @@ pages:
         html: use-escrows.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Escrows
         blurb: The XRP Ledger supports held payments, or escrows, that can be executed only after a certain time has passed or a cryptographic condition has been fulfilled. Escrows can only send XRP, not issued currencies. You can use these features to build publicly-provable smart contracts. This sections explains basic tasks relating to held payments.
         template: template-landing-children.html
@@ -802,7 +850,7 @@ pages:
         html: send-a-time-held-escrow.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Escrows
         blurb: Create an escrow whose only condition for release is that a specific time has passed.
         targets:
@@ -812,7 +860,7 @@ pages:
         html: send-a-conditionally-held-escrow.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Escrows
         blurb: Create an escrow whose release is based on a condition being fulfilled.
         targets:
@@ -822,7 +870,7 @@ pages:
         html: cancel-an-expired-escrow.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Escrows
         blurb: Cancel an expired escrow.
         targets:
@@ -832,7 +880,7 @@ pages:
         html: look-up-escrows.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Escrows
         blurb: Look up pending escrows by sender or destination address.
         targets:
@@ -843,7 +891,7 @@ pages:
         html: use-payment-channels.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         blurb: Payment Channels are an advanced feature for sending "asynchronous" XRP payments that can be divided into very small increments and settled later. This tutorial walks through the entire process of using a payment channel, with examples using the JSON-RPC API of a local rippled server.
         targets:
             - local
@@ -852,7 +900,7 @@ pages:
         html: use-checks.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Checks
         blurb: Checks in the XRP Ledger authorize another account to claim funds later, similar to how personal paper checks work.
         status: not_enabled
@@ -864,7 +912,7 @@ pages:
         html: send-a-check.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Checks
         status: not_enabled
         targets:
@@ -874,7 +922,7 @@ pages:
         html: cash-a-check-for-an-exact-amount.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Checks
         status: not_enabled
         targets:
@@ -884,7 +932,7 @@ pages:
         html: cash-a-check-for-a-flexible-amount.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Checks
         status: not_enabled
         targets:
@@ -894,7 +942,7 @@ pages:
         html: cancel-a-check.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Checks
         status: not_enabled
         targets:
@@ -904,7 +952,7 @@ pages:
         html: look-up-checks-by-sender.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Checks
         status: not_enabled
         targets:
@@ -914,7 +962,7 @@ pages:
         html: look-up-checks-by-recipient.html
         funnel: Docs
         doc_type: Tutorials
-        category: Use Complex Payment Types
+        category: Use Specialized Payment Types
         subcategory: Use Checks
         status: not_enabled
         targets: