因为Ripple本身属于金融协议，所以除了基本的货币收发与转换功能外，还具备很多的高级金融工具属性，比如“分期付款”（Partial Payments）。PS：这项隶属于“资金返回”的功能之一，可以参看wiki中【Returning payments】条目。
具体来说，在系统默认情况下，您所支付的交易金额，也就是设置好的发往目标账户的货币量。所需交易费用，或货币兑换时所需的任何额外金额，都从在发送账户的SendMax值（也就是可能发出的最大金额）中扣除。如果此SendMax值不能支付这些费用，则系统提示交易失败，并列出原因。
然而，当tfPartialPayment标识被激活时（这是Rippled端标识，需要自己运行Rippled时才可调，位于TxFlag集合中），则Amount这项可以发出的金额会发生变化（文档中也有注明），并不再遵循默认的那一套，将变成无论多少钱都可以发送。
简单地说，如果此tfPartialPayment标识被使用，则Amount将不再是事实上的发币金额，而变成“准备支付”的金额，不再受到账户SendMax的制约，只需满足XRP验证费，并且交易金额是正数，交易就可以发出（附带一提，使用此标识时，Ripple协议还会返回一个“分期付款”的交易警告给用户）。
也就是当用户以tfPartialPayment标识发出资金时，接收方虽然不会收到具体金额，但是会接收到一个含有tfPartialPayment标识的交易数据（“预付”数据，并不会增加接收方的资金，但是会收到条交易记录）。
而在这时，假如接收方再单纯验证Amount中的数量，则必然悲剧无疑，因为对方并没有给你这个钱，这钱仅仅是“想要给你”的空头支票罢了（这个标识本意是为了配合一些机构需要才有的）。
所以，RL文档中早就明确注明，当此标识被允许时，Amount金额并不能保证必然为事实上收到的金额。而只有DeliveredAmount字段(交易款，如果用js包的话，位于tx.meta.DeliveredAmount)，才能满足任何时候都是实收款，而绝对不会被“预付款”所干扰。
着重强调下，避免有人自己做代码收款，然后读Amount金额变悲剧，切记读tx.meta.DeliveredAmount，别搞错了。
其实看官方Ripple-Client代码就知道，他们一直读的就是DeliveredAmount，而非Amount……
话说自古以来，搞代码一不看文档，二不看示例，就没有不悲剧的……
具体来说，在系统默认情况下，您所支付的交易金额，也就是设置好的发往目标账户的货币量。所需交易费用，或货币兑换时所需的任何额外金额，都从在发送账户的SendMax值（也就是可能发出的最大金额）中扣除。如果此SendMax值不能支付这些费用，则系统提示交易失败，并列出原因。
然而，当tfPartialPayment标识被激活时（这是Rippled端标识，需要自己运行Rippled时才可调，位于TxFlag集合中），则Amount这项可以发出的金额会发生变化（文档中也有注明），并不再遵循默认的那一套，将变成无论多少钱都可以发送。
简单地说，如果此tfPartialPayment标识被使用，则Amount将不再是事实上的发币金额，而变成“准备支付”的金额，不再受到账户SendMax的制约，只需满足XRP验证费，并且交易金额是正数，交易就可以发出（附带一提，使用此标识时，Ripple协议还会返回一个“分期付款”的交易警告给用户）。
也就是当用户以tfPartialPayment标识发出资金时，接收方虽然不会收到具体金额，但是会接收到一个含有tfPartialPayment标识的交易数据（“预付”数据，并不会增加接收方的资金，但是会收到条交易记录）。
而在这时，假如接收方再单纯验证Amount中的数量，则必然悲剧无疑，因为对方并没有给你这个钱，这钱仅仅是“想要给你”的空头支票罢了（这个标识本意是为了配合一些机构需要才有的）。
所以，RL文档中早就明确注明，当此标识被允许时，Amount金额并不能保证必然为事实上收到的金额。而只有DeliveredAmount字段(交易款，如果用js包的话，位于tx.meta.DeliveredAmount)，才能满足任何时候都是实收款，而绝对不会被“预付款”所干扰。
着重强调下，避免有人自己做代码收款，然后读Amount金额变悲剧，切记读tx.meta.DeliveredAmount，别搞错了。
其实看官方Ripple-Client代码就知道，他们一直读的就是DeliveredAmount，而非Amount……
话说自古以来，搞代码一不看文档，二不看示例，就没有不悲剧的……
