整天在谷歌上搜索，阅读大量 PDF，但仍然对从 Westpac (a bank in Australia) 向 Payway 系统发送数据的概念感到困惑。他们通过 API 提供访问权限，但也通过他们所谓的“NET”提供访问权限。
我理解的方式是，当客户想在我的网站上付款时，如果是 NET，客户会进入页面（由银行托管或由我托管），该页面提供了输入信用卡信息详细信息的表格。然后通过正常的 POST 调用将此表单提交到 Payway 的特定 https 地址。然后处理它，浏览器返回到我指定为我在隐藏字段中发送的参数之一的 URL。
如果 API 故事类似，因此用户收到表单，填写数据，然后将数据发送到我的后端（不是 Payway 的）。然后我的后端使用提供的数据调用 payway API，一旦收到答案，就会向客户端返回确认页面。
我的理解对吗？请解释一下，因为我觉得我在这里缺少一些基本的东西。
【问题讨论】：
标签： api payment credit-card bank
PayWay 的一个奇怪之处在于，虽然大多数支付网关都有 2 个选项.. 商家托管或服务器托管，但 PayWay 使用令牌请求提供了这种通过 NET 选项托管的伪商家。信用卡详细信息直接在商家网站上获取，并且只会将确认暂时重定向到服务器，然后再返回。如果付费方式帐户可与 NET 和 API 通用，这将是很棒的。但似乎 API 帐户不支持 NET 方法。所以如果你想在你的网站上接受卡片，NET 令牌方法几乎被它更大的 API 兄弟所掩盖。
【讨论】：
有多种不同的方式可以与 PayWay Net 进行交互，具体取决于您想要的控制程度。最简单的方法是这样的：
还有一些方法可以完全自定义信用卡输入页面和收据页面。
PayWay API 不同。您在服务器上安装了一个软件。当你想进行信用卡交易时，你调用这个软件。它通过互联网与 PayWay 服务器对话，进行交易，并给您一个响应。例如，如果您正在编写电话支付系统，则可以使用它，因为 PayWay 界面中不涉及任何浏览器。
（免责声明：我为 Qvalent 工作，PayWay 的开发人员）。
【讨论】：
你的理解是正确的。
我已经完成了几个 Payway 集成，并且一直选择 API 解决方案，以便用户获得一致的体验并且不会在网站之间跳转。
【讨论】：