我坐火车去办公室-我需要经过一个车站，我几乎要到那里。
每天早上，我都会在该应用中购买火车票，这让我感到痛苦。 那里比较便宜，但是当我承受这三分钟的压力时，差价并不能弥补我的痛苦。 甚至没有提到应用程序五个屏幕中每个屏幕的加载时间，就不得不说有关使用已保存的地图对WebView进行存储，在运行中从SMS输入代码以及意外故障。
这是当您在火车上行驶时，他们说“出事了”并注销了钱，但他们不给票。 回程到达那里，但是火车已经离开了。 不管互联网的质量如何，这种情况每月都会发生两次。 无需谈论任何份额。
此时此刻，您在想-也许有一种更简单的方法？ 好吧，完全没有网页视图，既漂亮又原生。 是的，有这种方法。 细节剪下。
tl; dr我们创建了一个界面，用于在iOS和Android中通过Apple Pay，Google Pay，Sberbank移动银行和Yandex.Money接受付款。 不，您不必绘制付款表格。 是的，它也是开源的。
通常，在移动应用程序中大约有两种方案可以接受付款。
首先是通过带有付款页面的WebView。 因此，您可以通过钱包，银行卡，手机或其他任何方式接受付款。 问题是WebView无法访问浏览器cookie，这意味着它没有某些付款方式的授权，因此您将无法付款。
在第二种情况下，商户将卡数据通过其后端传递-为此，您需要遵守PCI DSS，这既昂贵，又长又困难。
行动SDK
Yandex.Kassi的移动SDK是我们用于简化iOS和Android的库，旨在简化商家，应用程序开发人员以及关心用户的人们的生活。 实际上，移动SDK是用于对银行卡和其他付款工具进行令牌化的工具。 令牌化是交换唯一标识符（令牌）所需的数据交换。
在春季，我们推出了SDK的第一个版本-通过卡付款和Yandex.Money钱包中的付款。 现在一切都变得更好了-在7月发行的版本中，他们添加了Google Pay，Apple Pay和通过Sberbank进行的付款，并通过短信进行了确认。
关于好处
主要好处是，买方可以支付任何费用，但是对于商人来说，它看起来像是可以操作而不是支付数据的令牌。
尚无必要通过PCI DSS合规性认证-卡数据将在我们的外围进行处理。 每年我们都要通过认证，遵守监管机构的所有规则，并取消与收银员相关的商店。 因此有可能。
有了SDK，用户看起来就很熟悉Android和iOS中的付款方式，现在他们无需在付款过程中离开应用程序上下文。 使用电子钱包付款的人也无需登录-如果用户登录了Money应用程序，则只需通过Yandex.Passport选择所需的帐户。
如何开始在家使用？
如果要完全概括，则需要完成两件事：
- 集成支付API Yandex.Cash-用于接收付款；
- 连接移动SDK-用于标记化和本机界面。
要添加Apple Pay，足以激活银行卡付款的接受并在Apple开发者帐户中
发行密钥 。
Google Pay有所不同。 需要：
- 准备APK的测试版本。
- 填写集成清单-确认您的应用程序不会接管世界，还有其他一些事情。
- 填写程序集以在Google Pay上进行验证。
Google将检查所有内容，并允许（或不允许）将应用程序发布到Google Play上。
移动SDK嵌入在客户端应用程序中，因此本机付款可以通过它进行工作。 原理是这样的：卡的详细信息直接进入我们的PCI DSS外围，而不会掉落到商店的后端。 我们将检查，处理并将其返回给商家的有效期为30分钟的支付令牌-该令牌只能使用一次。
用户，商家，移动SDK和API的交互方案Ya.Kassa在SDK的参与下，付款包括三个阶段：
- 开始支付和接收令牌。 该应用程序通过SDK发起付款，并在输出处收到付款令牌。
- 创建付款。 令牌进入服务器，服务器通过API发起付款。
- 请求付款状态。 为了绘制成功或错误的正确窗口，这是必需的。
为什么这么好？
- 该架构在不同的支付方案中是同质的。
- 无需在商店的后端使用信用卡。
关于开发和测试
在iOS版本中，我们使用VIPER和微服务。
令牌化模块是移动SDK的基石-它控制流程，以便商人仅看到Yandex.Kassi API输出的令牌，而与用户支付的费用无关。 另一个令牌化模块决定现在要显示用户的窗口，并向服务器发出POST请求。 我们为API编写了包装程序，以便处理对YandexMoneyCoreApi的HTTP / HTTPS请求-这使工作变得更加轻松。
服务是与Yandex.Kassi客户端API一起使用的存储和对象。
他们的代码简明扼要，没有大量分支和早期退出，因为开发部门设法预先考虑了整个体系结构。 SDK服务具有大量的功能编程-在这里，我们已充分展示了其功能。 在不得不与Functor，Monad，Applicative Functor合作的地方，普通的Promise帮助了我们。
let method = PaymentOptions.Method(oauthToken: clientApplicationKey, passportAuthorization: passportToken, gatewayId: gatewayId, amount: amount, currency: currency) let paymentOptions = session.perform(apiMethod: method).responseApi() let allItems = getItems <^> paymentOptions let items = paymentMethodHandler.filterPaymentMethods <^> allItems let itemsWithEmptyError = items .recover(on: .global(), mapError) .then(makeErrors) return itemsWithEmptyError
VIPER出现的唯一困难是-我们开始添加新的付款方式，并意识到中央模块正在迅速发展。 当其中有大约1000行时，我们决定必须对此做些事情并修改体系结构。
我们喜欢此过程的中央模块的想法，因此决定放弃它。 在其他项目中，我们使用确定性有限状态机来描述过程，但是在这里它不能解决问题，因为许多事情的实现将保留在同一模块中。 因此，我们决定采用“策略”模式来隔离每种付款方式的流程。 用户选择付款方式后，我们将为付款方式创建一个策略，该策略控制过渡卡并确定遵循哪个过程。
演示应用
我们做到了。
一切始于测试部门需要一些东西来测试移动SDK。 没有测试应用程序，他们就无法检查SDK的工作方式，并且测试人员中没有两个平台的开发人员。
在此过程中，事实证明，除了测试任务之外，演示应用程序还是向合作伙伴展示什么是移动SDK的好方法。 任何不知道如何使用Swift或Kotlin编程的人（阅读：任何人）都可以看到SDK的工作方式。 因此，我们将
演示应用程序通过Google Play和
iOS版本上传
到Yandex.Cash网站。事实证明，您可以查看不同的付款方式如何工作，如何使用设置或将其显示给负责选择付款汇总器的人员。 不要害羞。
开源的
发布后的几个月，我们非常不方便地分发了该库-共享了指向该站点的链接或通过邮件发送了文件。 好家伙不这样做-他们按照MIT许可将所有内容发布在GitHub上。 所以我们正是这样做的。
除了标记化的魔力外，商人还可以自定义颜色，更改徽标或对库进行任何其他更改。 为了方便起见，我们在CocoaPods中为iOS开发人员发布了移动SDK，在Maven中为Android开发人员发布了移动SDK。
如果您已经通过收银员接受付款，但是现在您想要做得更好，更高效，请连接移动SDK。 如果您只是要开一家商店，请连接收银员。 我们做得很好。
有用的链接
→
移动应用程序库→
SDK文档→GitHub上的
iOS和
Android SDK 。
→
Maven仅此而已。 在评论中提问！