如果你在评估用 Posty5 卖东西，有一个问题几乎决定一切，所以它放在最前，而不是五节之后。买家货到付款。围绕它的支付框架是完整的，也确实与提供商无关，但网关目录里只有货到付款，没有任何适配器接入。今天搭起来的商店会接单，并在送达时收款。
能在线支付吗？简短的回答
与其假定这是疏忽，不如理解它为何如此。框架具备一次真实集成所需的一切：支付会话、签名经过校验的 Webhook、退款、按国家解析支付方式，以及分别面向商家与买家的状态接口。它没有的，是一个假装成服务商的桩件。目录中的一条记录，是「商家可以接入它并收到钱」的承诺，而发布一条接受凭据却什么都扣不了的记录，等于对一家真实商店撒谎。所以这份清单保持诚实且简短。
结账按顺序询问什么
结账按各项互相依赖的顺序收集信息。先是购物车，然后是目的地，因为不知道送到哪里就无法解析配送费。费用随后从你的国家和城市规则中得出。可以应用优惠券。支付放在最后，订单随即以给你的顺序编号和给顾客的不透明追踪 ID 创建。在提交任何内容之前，购物车会在服务器端重新计价，并在同一刻检查库存，因此有人浏览期间被改动的价格不会以旧数字通过。 了解国家与配送费如何解析.
支付方式不是服务商
Posty5 把买家选择的支付方式与将要处理它的服务商分开，这个区分是刻意的：人们选择「银行卡」或「货到付款」，而不是一家从未听说过的处理公司的名字。框架能够表达银行卡、钱包、银行转账、先买后付和货到付款这些方式类型。今天只有最后一种可用，因为可用性取决于已接入的服务商，而目前一个也没有。
支付步骤何时根本不出现
由于货到付款被建模成和其他服务商一样的一种，而不是「没有支付方式」，结账里没有为它准备的特例——这带来一个细小而有用的行为。当只有一种方式适用于买家的国家和货币时，支付步骤根本不显示；结账只会说明它将使用的方式。只提供一个选项的步骤白白浪费一次点击，所以它不出现。
感谢页能诚实地说什么
结果页反映的是服务器确认的状态，绝不是返回 URL 所声称的——一旦接入真实服务商，这一点就很重要，因为浏览器是可以被说服相信某个返回 URL 的。今天有用的结果更安静：货到付款订单根本没有支付记录，感谢页也不会为它画出支付行。这种缺失意味着从未发起过在线支付。它不意味着订单未付款，两者不能当成同一件事来读。
访客结账与购物车模式
结账有两项行为归你决定。访客结账决定下单前是否必须登录；开启后，有人可以不注册就购买，并通过链接追踪订单。购物车模式决定商店是否使用购物车，这适合一次买一件的目录。两者都与支付无关，也都可以在上线后更改。 查看已登录买家能获得什么.
打开在线商店构建器
结账设置与商店其余配置放在一起，其中没有一项需要支付服务商才有用。
常见问题
Posty5 商店能刷卡支付吗？
今天不能。框架能表达银行卡支付，但目录里只有货到付款，也没有接入服务商。
会有支付服务商吗？
框架就是为接纳一个而建的，添加服务商意味着写一个适配器，而不是改动结账。没有公布日期，本文也不会杜撰。
我的商店为什么没有支付步骤？
因为只有一种方式适用。有一个以上选项时该步骤才显示；否则只会说明所用方式。
感谢页没有支付行，是缺陷吗？
不是。货到付款订单没有支付记录，因此无内容可显示。它表示未发起在线支付，而不是订单未付款。
顾客可以使用优惠券吗？
可以，在下单前于结账时应用优惠券。
可以不注册就购买吗？
可以，在你启用了访客结账的地方。追踪从不需要账户。
