
五个月前,我们发布了一个NPM模块,用于与2017年10月发布的新版本的Yandex.Kassa一起使用。 我们的模块已纳入官方文档,并且已被下载1300次以上。

在Habré,我们已经
与 Yandex的同事一起
谈论了创建模块的经验,但是当我们面对面向俄罗斯客户的支付系统集成时获得的经验却被抛在了后面。
因此,今天我们要告诉您,对于我们的一位国内客户,我们如何从集成我们熟悉的国外支付系统转变为俄罗斯同行,我们遇到了什么困难以及如何解决它们。
他们如何使用付款系统
以前,我们仅与外国客户的付款系统合作。 我们拥有与Authorize.net,Paypal,Braintree,Stripe,Payoneer,Wirecard和Svea集成的经验。
使用这些支付系统,很容易进行交互并实现各种功能。 例如,当我们在欧洲从事货运服务时,我们将几个支付系统集成到该项目中,并编写了一个算法-它实现了货币操作的复杂逻辑。 当用户订购一项服务时,系统将资金从客户的帐户转移到该服务的帐户,该算法进行交易:重新计算出现交付问题时的付款,将其转换为货币,进行退款和重新安排付款,注销使用该服务的百分比。
最好的支付系统代表使您无需注册即可开始在沙盒中进行开发。 许多文档都有出色的文档,并且在没有积极支持的情况下,几乎所有文档都可以帮助解决问题。 开发人员可以从个人帐户管理权限和访问。 支付系统具有适用于大多数流行平台的SDK,现在是未成文的标准。
要集成支付系统,开发人员需要:
- 在网站上注册并访问沙箱。
- 下载SDK并将其连接。 在应用程序的正确位置插入对支付系统功能的调用。
- 测试所有方案,并确保一切正常。
- 在客户解决财务和法律问题时从事其他任务。
- 在适当的时候,将付款接受切换为“战斗”模式。
发生了什么变化
一年前,我们开始在国内市场工作。 最早的项目之一
是Sellsay应用程序 。 它可以帮助用户发展谈判技巧,并且是相互专业协助的平台。
除了标准功能外,该应用程序还具有许多功能:授权和注册,项目的创建和编辑。 通过服务您可以联系
给企业教练。 如果您具备必要的知识,则可以获取证书并成为独立的培训师,参加活动和培训
从应用程序的创建者那里赚钱。
为了能够使用该服务付款,必须集成一种付款系统-您可以在其中以卢布和美元付款,转移付款条件并退款,保存卡并且在重复购买时不输入数据,使用Apple和Android Pay。 为了实现这一点,我们选择了Braintree系统。
然后我们做出了巨大的伪装。 我们同意并实现了使用支付系统的基本功能,但未考虑一个重要的细节。 我们在发布前两周(他们正在准备启动项目)时了解到这一点。 我们没有考虑Braintree不与俄罗斯的公司合作。 在美国注册公司不是一种选择。 我们还有一个出路:尽快更换付款系统。
Yandex.Kassa:使用API的第一个版本
在分析了系统之后,我们选择了Yandex.Cash:该服务使我们能够实现几乎所有功能,以一定的价格适合客户,并在连接在线收银台时解决了54-FZ问题。
不久之后,我们意识到我们的集成愿景与Yandex.Kassa及其安全服务的愿景根本不同。 集成的整个阶段更多地是通过无休止的合同,表格和电话来记住的,而不是通过编写代码来记住的。
因此,要获取测试密钥,必须在Apple Store或Google Play中提供指向该应用程序的链接。 如果付款接受是发布应用程序的先决条件,那么我们从哪里获得链接? 我们设法解决了这个问题,但是在某些情况下,有必要实现并发布由经理激活的功能。
是的,几乎所有请求都可以通过与个人经理沟通来解决。 但是,如果您的个人帐户中的问题转达给您的个人经理,那么当您打电话给您时,很有可能会在线上找一个随机的免费经理并获得完全随机的答案。 一段时间后-找另一位经理,对同一问题得到相反的答案。
另一个缺点:Yandex支持多代API。 甚至Yandex.Kassi也有几个使用不同文档,身份验证等的子系统。 结果,您必须同时实现不相关的API。 例如,您正在接受付款,而要取消,则需要重新开始:申请,合同,通话,研究和API集成。
发射前的最后几周变成了地狱。 为了按时启动项目,我们必须加强团队和加班,而Yandex.Cash同时也没有错过让我们感到紧张的机会。
Yandex.Kassa与Stripe的比较
在开发人员社区中,Stripe在易于集成和使用支付系统方面处于领先地位。 他们是第一个照顾程序员的人,并使支付系统尽可能方便和灵活。 这使开发人员不仅可以松一口气,而且可以加快集成过程并降低成本。
您可以在Yandex.Kassa和Stripe之间找到很多共同点。 例如,两个系统都基于类似REST的原理构建,使用HTTP响应代码,支持CORS(并且响应来自JSON),都支持幂等。 有一个“沙箱”-真实商店的完整副本,并且模式之间的转换只是密钥的替换:无需更改API或URL。
但是同时,它们也有很大不同,为了展示这些系统如何具有不同的方法,我们将使用具体示例来考虑某些阶段的实现。
由于服务器部分是在此项目的Node.js上实现的,因此我将举一些例子。
我们连接到该项目 。
条纹:
var stripe = require('stripe')('sk_test_...');
Yandex.Cash:
, ;
索取卡详细信息条纹:
以相同的方式连接客户端库,并在输入卡的表格显示中请求令牌。
var stripe = Stripe('pk_test_6pRNASCoBOKtIshFeQd4XMUh'); var elements = stripe.elements();
在服务器上
stripe.charges.create({ amount: 2000, currency: "usd", source: "token from previous step",
Yandex.Cash:
: , . : <a href="https://money.yandex.ru/eshop.xml?shopId=12345&scid=1234566&sum=3000&customerNumber=73">https://money.yandex.ru/eshop.xml?shopId=12345&scid=1234566&sum=3000&customerNumber=73</a>
实际上,网站上必须有付款表格。 当用户单击“付款”时,此表单将发送到上述地址,并使用POST方法传递参数。 但是我们有一个移动应用程序,因此我不得不放弃该表单,并在服务器端与WebView中的开口形成链接。
该链接被提供给客户以输入卡的详细信息并确认付款。 但是在这里我们面临另一个惊喜:在2017年底,Yandex.Kassa不支持响应式设计。 使用设置进行的各种操作均未产生结果。
设计不适用于移动应用原来,要将付款页面的外观切换为自适应模式,您需要在个人帐户中留下一个请求。 我们不得不再次联系技术支持。
Hooray,2017年手机的改版设计!
但仅适用于通过信用卡付款检查付款事实条纹:
在付款过程中检查付款,如果发生错误,API函数将返回相应的异常。
Yandex.Cash:
用户使用Yandex.Cash进行付款,但用户的应用程序尚不了解付款事实。 因此,Yandex.Kassa必须通知服务器已付款。 为此,开发人员必须创建一个WebHook并配置Yandex.Cash,以便它可以使用WebHook中的地址来传达付款事实。
服务器付款通知分为两个阶段:
- 检查付款的可能性。 我们的服务器检查所有内容,允许或拒绝扣除资金,例如,检查货物的余额或价格的正确性。
- 履行付款。 Yandex.Kassa通知我们的服务器这笔钱已经借记,并且付款成功。 此时,有必要在数据库中修复付款事实。
但是这里有惊喜在等着我们:
- 要更改地址,您需要向经理发送请求,然后再次等待。
- 有必要实现一种特殊的算法来检查Yandex.Kassa中数据的有效性。
- 服务器必须返回定制生成的XML。 我们能够找到一个生成正确答案的现成模块 。
取消付款条纹:
stripe.refunds.create({ charge: "ch_1BTuEo2eZvKYlo2CSGqKz76n" }, function(err, refund) {
Yandex.Cash:
X.509 MWS. ., ..
您可能会猜到,协调和连接花费了一些时间。 它顺利地超出了截止日期的界限。
保存卡条纹:
stripe.customers.create({ email: "paying.user@example.com", source: "src_18eYalAHEMiOZZp1l9ZTjSU0", }, function(err, customer) {
Yandex.Cash:
我们描述了取消存储卡的规则并实现了删除功能。 然后,我们将应用程序发送给Yandex.Kassa安全服务进行审核,并等待答案。
如果答案是肯定的,则可以在成功付款后保存卡,并使用MWS协议重复付款。
文档中的示例请求:
POST https:
从示例中可以看到,Stripe更适合开发人员,并具有多种功能。 但是有一个很大的问题:像Braintree一样,Stripe在俄罗斯不起作用,尽管它可以接受来自不同国家/地区的付款。 Stripe帐户的所有者必须是他可以访问的国家/地区的居民-俄罗斯不在其中。
结果是什么
即使考虑到我们不得不做很多额外的工作并在支持下进行沟通这一事实,我们不仅设法按时完成几乎所有工作,而且还进行了额外的工作。 发布前一周,发布了新版本的Yandex.Kassi API,我们创建了NPM模块并重写了代码。
当我们弄清楚API的新版本时,我们感到很惊讶:开发人员清楚地查看了外国类似物并采用了最佳实践。 先前版本的一些问题已解决。 新API的文档没有用于Node.js的SDK。 我们计划进一步在俄罗斯市场工作,我们将需要这样的工具。 因此,我们决定创建一个NPM模块,任何人都可以独立地将其集成到他们的项目中。