lswcap随着互联网和智能手机的普及，在线支付在过去几年变得越来越流行。从2011年开始，Stripe着重开发人员，首先开发了易于使用的API作为数百万公司引入的在线支付服务。随着支付方式的多样化，这种条带化API发生了怎样的变化？
在Stripe出生的2011年至2015年之间，信用卡是美国的主要付款方式。 Stripe.js是用于实现Stripe提供的支付功能的JavaScript库，当时是令牌对象和收费对象的基本概念。首先，客户端使用公共可用的API密钥与Stripe通信以生成令牌。客户端将生成的令牌，API密钥和与付款相关的信息发送到服务器。服务器根据从客户端发送的令牌和API密钥将与支付有关的信息发送到服务器。服务器创建一个费用，该费用基于从客户端发送的令牌和API密钥秘密来查询Stripe。 Stripe端是一种结构，用于通过每个实体交付实际的信用卡付款和付款结果。
在展位开始时，它仅支持信用卡，但在2015年，它响应了在美国广泛使用的ACH借记和比特币。但是，这些付款方式与信用卡非常不同，因为付款没有立即完成。
首先，对于ACH借记，将待处理状态添加到费用中，以便服务器端可以响应付款失败。该API进行了改进，因此您可以检查服务器和条带上的付款是否已完成。
由于比特币不太适合Stripe API的设计，Stripe决定将信用卡和ACH借记付款以及付款处理按比特币划分。为了分离处理，添加了新的比特币接收者对象，并且在使用比特币付款的情况下，服务器可以使用比特币接收者而不是令牌进行处理。但是，由于处理的分离，客户端的实现变得复杂。
在2015年至2017年期间，Stripe将逐步扩展其付款方式。与比特币一样，每种付款方式都增加了处理，实现变得越来越复杂，因此需要不同的解决方案。 Stripe将各种付款方式抽象为Source对象，并集成了令牌和接收者。货源充当资金的临时容器，当可以付款时，状态由计费显示，当不能立即付款时，状态由挂起指示，服务器可以根据付款的状态进行处理。客户端发送的源。
尽管已经简化了结构，但是仍然存在一个问题，即当客户使用无法立即付款的付款方式付款时，服务器无法处理它，直到付款完成为止。另外，据说存在这样的问题，因为在进行支付时会话针对在另一页上需要认证的支付方法而终止，因此不能在服务器侧产生费用。
付款表单设计的一个显着特征是，处理可以通过付款方式进行同步或异步。例如，可以将直接付款的付款方式（例如信用卡或银行帐户）直接向货源收取费用，并在服务器端产生费用。但是，无法立即付款的付款方式（例如比特币和借记卡）必须等待处理，直到可以付款为止。开发人员必须分别在客户端和服务器端保留付款状态。
从2017年开始，如果您查看付款方式，Stripe会发现，无需付款人操作即可立即付款的唯一付款方式是信用卡。 2011年基于信用卡支付设计的API架构在2017年效率低下。可以说，这种情况与通过向汽车中添加零件组装航天器相同。
因此，从2017年底到2018年全年，Stripe开始设计新的API架构。这个由五人组成的小组说，他们讨论了三个月的新API。经过讨论后完成的新API使用了PaymentMethods对象和PaymentIntents对象作为基本概念。类似于令牌，付款方式包含有关付款方式的基本信息，但与来源不同，它不包含付款状态。同时，“付款意图”保存所有与交易有关的信息，例如付款和付款状态。
此外，过去，包括付款信息在内的令牌和来源都是从客户端传输到服务器的，但是在新的API中，服务器会将包括可用付款方式的付款意图发送给客户端，从而使客户端可以获得所选的付款方式由客户通过Stripe。这消除了客户端通过付款方式处理分支的需要，因此服务器端可以与付款方式一起检查付款状态。
但是，API不仅以设计结尾，而且还有很多事情要做，例如代码实现和开发人员部署。 Stripe正在努力从2018年到2020年分发新的API 。可以在此处找到相关信息。
Add comment