收银台SDK不只是一个开发工具，也不只有一个程序，而是一系列编程接口、接入文档、接入示例、开发辅助工具的集合。
完整的SDK应该包括如下内容：
（1）接口文件和库文件：是接入主体，包含核心逻辑与对外接口。
（2）帮助文档：也叫作开发者接入指南，帮助开发者了解和快速接入。
（3）开发示例：应用Demo程序或服务器Demo程序，甚至提供各种开发语言版本的Demo，例如Java、C#、Objective-C。
（4）辅助工具：辅助应用开发或测试人员正确接入。
1、接口设计原则
针对前面讲到的关于SDK接口的设计一般会有相应的设计原则，这也是终端和服务端通用的接口设计原则。
（1）单一职责原则（Single Responsibility Principle，SRP）：由Rabert C.Martin最先提出，核心概念是“一个类应该只有一个改变的理由”。单一功能原则是一个接口设计原则，它指出每一个模块或类应当拥有的一个单一的责任功能，而责任应被完全封装在类或模块中。其所有服务都应与其责任严格一致，相互之间没有依赖。简单来说，就是需要建立单一、纯粹的接口，不要建立功能庞大、代码臃肿的接口。
（2）里氏代换原则（Liskov Substitution Principle ，LSP）：是面向对象设计的基本原则之一，同样适用于SDK的接口设计。在里氏代换原则描述中，在任何基类可以出现的地方，子类都一定可以出现。
里氏代换原则是继承和复用（父类、基类概念）的基石，只有当衍生类可以替换基类且软件单位的功能不受到影响时，基类才能真正被复用。而衍生类能够在基类的基础上增加新的行为。同时，里氏代换原则是对“开-闭”原则的一种补充，实现“开-闭”原则的关键步骤和前提是抽象化，而父类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对抽象化的具体步骤规范。例如：在Client类中调用其他类时一定要使用其基类或接口，如果不能使用，则说明这个类或接口的设计已经违背了里氏代换原则。
简单地说，可以按照如下所述理解里氏原则。
·子类必须完整、完全地实现基类的方法、属性（字段）。当然：子类是基类的一个延续，可以有自己特有的属性、方法，即使在相同的方法内也可以表现为不同的数据和业务流程实现。
·在覆写、实现父类的方法、接口时，期法可以更优。例如：可以增加相应的输入参数。
·覆写（Override）、实现父类的方法，返回的结果可以缩小。
（3）接口隔离原则（Interface Segregation Principle，ISP）：指接口功能尽量内聚、小。接口功能只服务于一个子模块或业务流程，对没有关联性的内容都需要剔除。每个接口都应代表一个功能 ，而不是某个功能的一个步骤，否则会存在分布式事务污染的问题。
2、收银台SDK接口设计
收银台SDK是第三方支付机构或融合支付厂商向商户的支付功能开发者提供的Android、ios、 Windows平台专业开发辅助工具包，商户开发者在产品中添加收银台SDK并调用其接口后即可直接使用收银台的各种功能。
融合支付SDK则是将市面上常用的支付方式都整合到一个SDK中，这样商户和开发者无须再和各家支付公司逐一签订合同 ，就可以通过接口在应用程序中集成和调用功能齐全的收银台。
依据以上接口设计原则，收银台SDK一般将功能收敛到以下4个接口中：
1.初始化支付接口
在商户的商业化产品应用中，收银台SDK一般需要商户开发人员在应用启动或支付页面拉起的地方，进行初始化支付SDK（包含鉴权用户端或设备信息），扫描当前App环境是否安全，并且在初始化过程中准备好支付环节的资源、参数配置和界面展示内容，通常只需要初始化一次。在Android环境中，一般建议在Application的onCreate方法里面调用。
以Android SDK为例：
其参数情况如表1所示。
表1
对其中的参数介绍如下。
（1）Context是Android系统的上下文抽象类，通过类的结构可以看到：Activity、 Service、 Application 都是Context的子类。以上这些
子类的实例对象都可以作为初始化函数的入参，一般推荐使用Application实例作为参数进行传入。
（2）data通常是支付SDK初始化需要的参数数据，一般包含如下内容。
·应用标识：指应用的唯一标识，在第三方支付机构申请完成之后，由第三方支付机构提供应用标识参数。
·横竖屏类型：用于展示收银台页面的显示风格。
·其他参数：第三方支付机构定义的渠道标识、应用密钥等相关参数。例如：游戏的渠道标识，用于后期支付分润、数据打标及门店标识等。
注意：Intent主要用于Android应用各项组件之间的通信，负责描述应用中的一次启动动作及动作涉及的相关数据；同时有另外一种功能，可以根据在Intent中描述的内容找到对应的对象，并将Intent中的其他数据传递给被调用的组件。
（3）回调函数。在调用了初始化函数之后，收银台SDK初始化的结果就会被异步回调给商户应用，其基本原型如下：
回调中的State（状态）数据一般包含以下三种状态。
·初始化中：初始化进度开始，通常用于回调给应用界面，展示正在初始化的加载界面或动画。
·初始化失败：初始化失败，一般涉及配置参数失败、服务器校验失败、风控、网络及其他问题。
·初始化成功：初始化顺利完成。
注意：Bundle数据包含在状态过程中携带的附加数据，为Bundle数据结构类型，该类型的数据为Key-Value结构，可以类比Java中的Map结构，通常用于在Activity、Service、 BroadCast Receiver、Content Provider这Android四大组件之间传递数据。
在初始化回调接口中，Bundle实例可携带的数据包含：初始化中状态回调里携带的进度百分比数据（加载Web支付页面的30%进度）；失败回调里携带的初始化错误码和错误信息等。
2.支付接口
支付接口主要用于用户下单并支付的场景中，通常会拉起支付界面：
其参数情况如表2所示。
表2
对其中的参数介绍如下。
（1）activity：Activity类型，是Android系统的界面组件类，于承载View对象容器和展示一个移动界面。 这个参数一般负责拉起支付界面的Activity 类型，例如电子商务网站的订单详情页面。
（2）data：Intent类型，通常是支付需要的参数数据，一般包含如下内容。
·商户订单编号：是商户系统生成的订单编号，与支付系统中的交易单号一对应。支付系统一般要求商户系统生成订单号时符合并发条件且不重复，兼顾安全性（不容易从订单号中看出运营规则）。一般推荐使用”时间戳+随机码+流水号”的规则生成商户的订单号，这是一个必须上传的参数。
·商品编号：是商户在第三方支付系统中登记的商品编号，在某些支付SDK中不需要传入这个参数。
·商品名称：用于显示支付确认界面的商品名称，一般也被登记在第三方支付系统中，通常用于订单数据校验。
·商品价格：支付的金额，一般以”分”为单位，但部分系统以"元”为单位，支持有两位小数。
·商品描述：支付确认界面的商品描述内容。
·订单超时：订单的绝对超时，通常以服务器同步的时间为基准。
·扩展参数：为动态数据，通常为支付回流数据，这样可以在订单状态返回时将该数据返回到本地。
·渠道标识：用于后期支付分成及数据打标，由第三方支付机构进行分配。
在调用了支付函数之后会展示支付界面，用户确认支付信息之后，这些数据将被传送给支付服务器处理，在处理完成后支付结果就会被异步回调给商户应用。
（3）回调函数，其基本原型与初始化回调基本一 致，仅数据的内容不一样，代码如下：
支付状态（State）包含如下内容。
·支付进行中：此状态表示用户正在支付，通常用于回调支付进度。例如：支付进行了30%。
·支付失败：支付失败，一般涉及支付过程中支付参数不正确、访问校验失败、风控等支付错误。
·支付成功：支付顺利完成。
支付接口中的Bundle数据包含以上支付状态所携带的相关数据，这个数据与初始化接口同样为Key一Value结构，但数据的内容不一样。
（1）如果是支付进行中状态，则在Bundle中包含支付进度数据，将支付进度展示给商户应用或用户。
（2）如果是支付成功状态，则在Bundle中包含以下数据。
·交易订单号：支付交易引|擎系统中的交易流水编号，与商户交易订单号对应。
·支付类型：采用的支付类型。
·交易金额：支付的金额。
·订单数据验签：是之前商户申请时预置在平台上的公钥，采用商户公钥将返回的信息数据签名，进行发货前的数据验证，避免数据被篡改。
·扩展信息：数据回流信息，通常是商户采用支付接口带上去的数据原本（商品编号、商品价格、验证数据、描述等）。
（3）如果是支付失败状态，则在Bundle中包含以下数据。
·支付错误码：支付系统对支付失败过程中错误原因的编码，例如支付宝系统的公共错误码和SPI错误码等。
·错误描述：错误码对应的支付错误信息描述，一般是UTF一8编码，用于展示给商户开发者或进行用户提示。
3.支付结果查询接口
在调用了支付接口之后，对于未返回的支付结果订单，支付SDK一般会提供支付结果查询接口给商户开发者，用于查询当前支付进度和结果：
其参数情况如表3所示。
表3
这个接口通常用于查询某个支付订单的结果和状态，这些数据会通过回调函数的形式异步返回给应用。回调函数与支付接口的形式一致，详见支付回调函数的描述。
查询订单的结果状态会有所变化。
·未付款：交易单已创建，并且订单未付款。
·支付中：付款中。
·支付成功：付款已成功。
·支付结束：此交易已完成，不支持退款等操作。
4.退出接口
退出接口主要用于关闭支付并且清理支付资源。以下接口用于退出SDK，调用该接口之后SDK不可使用（不能再调用支付接口）。
应用退出时推荐调用该接口， 若不调用该接口，则部分支付数据无法在本地持久化，例如支付记录数据等。该接口一般为同步接口，会在此接口中进行内存清理与本地数据持久化。
