出款系统来说： 付款方就是出款的源头（通常为商户），收款方就是收钱的那一方（通常为个人）
计费中心---怎么计算手续费
收费模式：实收 后收 预付实扣 均有有效期概念，有效期立即生效
实收---退款时，是否退手续费
后收--退款时，是否退手续费，后收结算周期--日结，周结，月结，季结，年结
预付实扣--退款时，是否退手续费
如果为付款方出手续费，那么可以支持三种收费模式；
如果为收款方出手续费，则只可支持实收收费模式；
计费策略：简单的说是一笔出款按照什么样的公式来收你的钱；
固定比例 最低收取多钱 最高收取多钱
固定费额
固定费额+固定比例 最低收取多钱 最高收取多钱
区间固定费额/固定费率/固定费额+固定比例
例如：区间固定费额
区间1 0---100元 收取1元
区间2 100--500元 收取 5元
例如：区间固定比例
区间1 0---100元 按照0.38%收取 最低1元
区间2 100--500元 按照0.3%收取 最低5元
例如：区间固定费额+固定费率
区间1 0---100元 按照1+0.38%收取 最低1元
区间2 100--500元 按照5+0.3%收取 最低5元
让商户来告诉我们传递哪方来收取手续费；但是，此种情况下，手续费的配置就比较繁琐，那就需要2种计费策略，一种是付款方的，一种是收款方的；
在商户跟支付公司签订好协议后，手续费的变动理应来说不会经常变动。所以，在商户入网时候，就将手续费的收取方式设定号好可，不需要再实际出款的时候在进行告知；
付款方出手续费（商户出）
出款金额为100元，计费策略为每笔出款收取1元手续费；
实收的时候怎么扣：出款金额100元不变，在商户的账户余额中扣除1元，当做手续费，如果商户账户余额不足，则出款失败；
后收的时候怎么扣：出款金额100元不变，在商户的后收表中记录一条手续费数据，待计费周期结束后收取；
预付实扣的时候怎么扣：出款金额100元不变，在商户的手续费账户余额中扣除1元，当做手续费，若商户的手续费账户不足，则出款失败；
收款方出手续费（用户出）
收款方出手续费，只能支持实收模式，其余2种不能支持，因为用户在支付公司没有任何账户的概念，没法扣钱；
出款金额为100元，计费策略为每笔出款收取1元手续费；
实收的时候怎么扣：出款金额100元，扣除手续费1元，实际出款金额99元，进行出款，用户收到99元；
在实际进行出款时候，为了应对各种场景下的需求；计费侧，建议提供预计费接口，和实际计费接口，逻辑相同，只是一个会入库，一个只在内存中计算；
实际出款中，一种是商户请求支付公司接口进行出款操作；
另一种，是商户在支付公司的商户后台进行页面形式的出款操作；
第一种情况下还可以分为2种，展示计费和实际出款；
例如，商户接口请求，想先看下计费结果，那么此时的接口逻辑应当包含计费和参数的校验；
商户不看计费结果，直接进行出款操作，那么就包含实际出款流程，检验，计费，出款。。。
第二种，也就是商户后台，通常情况下，会展示给用户计费的结果和要出款的校验结果。所以跟接口中的第一类相似；
如果计费异常，则拒绝后续出款流程；
疑问点?到底谁来做扣除手续费的操作？
计费中心？ 出款系统？ 后面的账务账户系统？
手续费的计算理应由计费中心来实现，计费结果计费中心保留；
出款系统，也会保存计费的结果；
我认为由账务来做手续费的扣减比较合适，因为无论怎么操作，账务都需要对商户账户的余额进行扣减，手续费账户也保留在账务系统，那么由账务来做统一的扣减比较合适；
但是对于账务账户来说，他理应不关注付款方还是收款方的概念。
传递给账务账户时，出款的商户编码，出款的金额，出款的手续费，传递给账务即可；
但是在传递的时候，需要注意，如果是收款方承担手续费（只有实时一种情况），那么手续费字段为0，出款金额为：出款金额-计算出的手续费金额；
后续在做手续费统计等统计工作的时候，统计出款系统中的出款成功明细即可；
但是计费中心处，出款系统需要对后收的计费进行处理，可以使用定时通知的方式，将后收的出款订单告诉计费中心，出款成功，在结算周期结束后，找商户收钱去；
麻烦点是，出款可能成功可能失败，但是计费是在实际出款前就进行了的，所以对于后收的来说需要知道这笔计费是否真的要跟商户去要钱。
站在计费中心的角度来说，对于实收和预付实扣来说并不关注其是否成功还是失败；当然我们也可以将成功和失败告诉计费中心；还有一点就是计费中心不关注当时计费记录的成功失败，如果想对后收的商户在手续费统计收取，那么计费中心可以开个接口来接收后收的计费，只要有唯一流水号关联当时的计费记录即可。
还有一点在于，实际银行的操作出款中，银行侧有可能出款打款成功，但实际打款失败；打款失败，但实际打款成功的情况。
这样，我们整个链路上的系统，状态就会出现终态后不一致的情况，如果多个系统保留了出款状态，那么后续想让状态保持一致，就需要单独开发功能来保证了，麻烦事；建议出款的状态不要侵略到其他业务系统中。
