随着互联网和智能手机的普及,在线支付在过去几年变得越来越流行。从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