通过移动终端原生应用程序进行交易的方法、装置和系统与流程

本申请涉及移动终端技术领域，特别涉及一种通过移动终端原生应用程序进行交易的方法、装置和系统。

背景技术：

随着互联网技术的发展，通过互联网进行交易已经越来越普遍。在对于涉及到多种业务的交易来说，交易流程非常复杂。目前的交易流程中，每个业务在接入应用程序中时，大多是通过请求单一的API(Application Programming Interface，应用程序编程接口)方式，将业务集中在API对应的业务服务器。在通过原生应用程序进行交易时，由于交易流程中业务量较大而造成了业务服务器系统臃肿，导致业务发展受阻。虽然使用网页应用程序或混合应用程序进行交易能够增加业务接入应用程序的灵活性，但网页应用程序或混合应用程序用户体验较差，远远不及原生应用程序，仍然难以满足用户的业务需求。

技术实现要素：

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。为此，本申请的一个目的在于提出一种通过移动终端原生应用程序进行交易的方法，提升用户体验，同时可减轻服务器的负担。

本申请的第二个目的在于提出另一种通过移动终端原生应用程序进行交易的方法。

本申请的第三个目的在于提出一种通过移动终端原生应用程序进行交易的系统。

本申请的第四个目的在于提出一种移动终端。

本申请的第五个目的在于提出一种业务服务器。

根据本申请第一方面实施例的通过移动终端原生应用程序进行交易的方法，所述原生应用程序包括多个流程节点模块，所述方法包括以下步骤：第一流程节点模块将原生应用程序的当前节点状态发送至业务服务器，其中，所述第一流程节点模块提供的第一页面中包括第一触发按键；接收所述业务服务器发送的第一API，其中，所述第一API与所述第一触发按键相对应；当所述第一触发按键被触发时，第二流程节点模块根据所述第一API生成第二页面，并将当前节点状态发送至所述业务服务器，其中，所述第二流程节点模块提供的第二页面中包括第二触发按键；以及接收所述业务服务器发送的第二API，并在所 述第二触发按键被触发时第三流程节点模块根据所述第二API生成第三页面，其中，所述第二API与所述第二触发按键相对应。

根据本申请实施例的通过移动终端原生应用程序进行交易的方法，原生应用程序在处于不同的节点状态时，可通过相应的流程节点模块将当前节点状态发送至业务服务器，以使业务服务器下发相应的API，并在该API对应的触发按键被触发时，进入下一流程节点状态，并由业务服务器继续下发该流程节点状态对应的API。由此，通过业务服务器可针对原生应用程序的不同节点状态分别发送API，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器端的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

根据本申请第二方面实施例的通过移动终端原生应用程序进行交易的方法，所述原生应用程序包括多个流程节点模块，所述方法包括以下步骤：业务服务器接收原生应用程序中第一流程节点模块发送的当前节点状态，其中，所述第一流程节点模块提供的第一页面中包括第一触发按键；所述业务服务器将所述第一触发按键对应的第一API发送至所述第一流程节点模块；所述业务服务器接收原生应用程序中第二流程节点模块发送的当前节点状态，其中，所述第二流程节点模块提供的第二页面中包括第二触发按键；所述业务服务器将所述第二触发按键对应的第二API发送至所述第二流程节点模块。

根据本申请实施例的通过移动终端原生应用程序进行交易的方法，原生应用程序在处于不同的节点状态时，可通过相应的流程节点模块将当前节点状态发送至业务服务器，以使业务服务器下发相应的API，并在该API对应的触发按键被触发时，进入下一流程节点状态，并由业务服务器继续下发该流程节点状态对应的API。由此，通过业务服务器可针对原生应用程序的不同节点状态分别发送API，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器端的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

根据本申请第三方面实施例的通过移动终端原生应用程序进行交易的系统，包括承载原生应用程序的移动终端和业务服务器，其中，所述原生应用程序包括多个流程节点模块。其中，第一流程节点模块用于将原生应用程序的当前节点状态发送至业务服务器，并接收所述业务服务器发送的第一API，其中，所述第一流程节点模块提供的第一页面中包括第一触发按键，所述第一API与所述第一触发按键相对应；第二流程节点模块，用于当所述第一触发按键被触发时，根据所述第一API生成第二页面，并将当前节点状态发送至所述业务服务器，并接收所述业务服务器发送的第二API，其中，所述第二流程节点模块提供 的第二页面中包括第二触发按键；以及第三流程节点模块，用于当所述第二触发按键被触发时，根据所述第二API生成第三页面，其中，所述第二API与所述第二触发按键相对应；所述业务服务器，用于接收原生应用程序中第一流程节点模块发送的当前节点状态，并将所述第一触发按键对应的第一API发送至所述第一流程节点模块，以及接收原生应用程序中第一流程节点模块发送的当前节点状态，并将所述第二触发按键对应的第二API发送至所述第二流程节点模块。

根据本申请实施例的通过移动终端原生应用程序进行交易的系统，原生应用程序在处于不同的节点状态时，可通过相应的流程节点模块将当前节点状态发送至业务服务器，以使业务服务器下发相应的API，并在该API对应的触发按键被触发时，进入下一流程节点状态，并由业务服务器继续下发该流程节点状态对应的API。由此，通过业务服务器可针对原生应用程序的不同节点状态分别发送API，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器端的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

根据本申请第四方面实施例的移动终端，所述移动终端具有原生应用程序，所述原生应用程序包括多个流程节点模块，其中，第一流程节点模块用于将原生应用程序的当前节点状态发送至业务服务器，并接收所述业务服务器发送的第一API，其中，所述第一流程节点模块提供的第一页面中包括第一触发按键，所述第一API与所述第一触发按键相对应；第二流程节点模块，用于当所述第一触发按键被触发时，根据所述第一API生成第二页面，并将当前节点状态发送至所述业务服务器，并接收所述业务服务器发送的第二API，其中，所述第二流程节点模块提供的第二页面中包括第二触发按键；以及第三流程节点模块，用于当所述第二触发按键被触发时，根据所述第二API生成第三页面，其中，所述第二API与所述第二触发按键相对应。

根据本申请实施例的移动终端，其中的原生应用程序在处于不同的节点状态时，可通过相应的流程节点模块将当前节点状态发送至业务服务器，以使业务服务器下发相应的API，并在该API对应的触发按键被触发时，进入下一流程节点状态，并由业务服务器继续下发该流程节点状态对应的API。由此，通过业务服务器可针对原生应用程序的不同节点状态分别发送API，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器端的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

根据本申请第五方面实施例的业务服务器，移动终端包括原生应用程序，所述原生应 用程序包括多个流程节点模块，所述业务服务器包括：第一接收模块，用于接收原生应用程序中第一流程节点模块发送的当前节点状态，其中，所述第一流程节点模块提供的第一页面中包括第一触发按键；第一发送模块，用于将所述第一触发按键对应的第一API发送至所述第一流程节点模块；第二接收模块，用于接收原生应用程序中第一流程节点模块发送的当前节点状态，其中，所述第二流程节点模块提供的第二页面中包括第二触发按键；第二发送模块，用于将所述第二触发按键对应的第二API发送至所述第二流程节点模块。

根据本申请实施例的业务服务器，可根据原生应用程序处于的不同节点状态下发不同相应的API，以使原生应用程序在该API对应的触发按键被触发时，进入下一流程节点状态，并进一步为原生应用程序下发相应的API。由此，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

图1为根据本申请一个实施例的通过移动终端原生应用程序进行交易的方法的流程图；

图2为根据本申请一个具体实施例的通过移动终端原生应用程序进行交易的方法的流程图；

图3为根据本申请一个实施例的另一种通过移动终端原生应用程序进行交易的方法的流程图；

图4为根据本申请一个实施例的通过移动终端原生应用程序进行交易的系统的结构框图；

图5为根据本申请一个实施例的移动终端的结构框图；

图6为根据本申请一个实施例的业务服务器的结构框图；

图7为根据本申请另一个实施例的业务服务器的结构框图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的通过移动终端原生应用程序进行交易的方法、系统、移动终端及业务服务器。

图1为根据本申请一个实施例的通过移动终端原生应用程序进行交易的方法的流程图。

其中，原生应用程序是指用移动设备的操作系统的原生UI(User Interface，用户界面)和控件设计开发的移动互联网客户端。原生应用程序包括多个流程节点模块。多个流程节点模块与原生应用程序的多个节点状态分别对应。举例来说，在商品交易的过程中，可包括商品详情展示、确认下单、创建订单以及付款等节点状态，那么商品交易的原生应用程序则可包括与上述节点状态分别对应的四个流程节点模块。原生应用程序在处于每个节点状态时可提供至少一个业务，当用户选择其中一个业务时，原生应用程序可进入被选择的业务对应的下一节点状态。

如图1所示，本申请实施例的通过移动终端原生应用程序进行交易的方法，包括以下步骤：

S101，第一流程节点模块将原生应用程序的当前节点状态发送至业务服务器，其中，第一流程节点模块提供的第一页面中包括第一触发按键。

原生应用程序在交易流程中随着流程的进行可处于不同的节点状态。原生应用程序在处于不同的节点状态时，相应的流程节点模块会将当前节点状态发送至业务服务器。因此，当原生应用程序处于第一流程节点模块对应的节点状态时，第一流程节点模块可将原生应用程序的当前节点状态发送至业务服务器，以便业务服务器根据原生应用程序的当前节点状态选择对应的API返回至原生应用程序。

在本申请的实施例中，原生应用程序处于每个节点状态时，可提供与节点状态对应的页面，页面中包括与节点状态所提供的业务相对应的触发按键。其中，用户可通过触发某一触发按键控制原生应用程序执行接下来的业务。因此，当原生应用程序处于第一流程节点模块对应的节点状态时，第一流程节点模块可提供第一页面，且第一页面中包括第一触发按键。其中，第一触发按键可为一个或多个，与第一流程节点模块对应的节点状态所提供的业务的数量相对应。

S102，接收业务服务器发送的第一API，其中，第一API与第一触发按键相对应。

其中，第一API的数量可为一个或多个，与第一触发按键相同，其数量与第一流程节点模块对应的节点状态所提供的业务数量一致。

当业务服务器接收到第一流程节点模块发送的原生应用程序的当前节点状态后，业务服务器可根据第一流程节点模块提供的商品标记或移动终端的类型信息等选择对应的第一API并发送至原生应用程序。

在本申请的一个实施例中，业务服务器可获取第一流程节点模块提供的商品标记，并根据商品标记选择对应的第一API并发送。其中，商品标记可包括商品类目标记(例如游戏类、家电类等)或商品属性标记(促销类、特定优惠类、特定市场类、特殊交易流程类等)。

具体地，对于通过原生应用程序进行交易的商品，业务服务器可根据其类目或属性对其交易流程中的业务进行标记。不同的商品标记可与不同的第一API相对应，从而业务服务器可根据商品标记和原生应用程序的当前节点状态选择对应的第一API并发送。举例而言，对于服装、食品和玩具等不同类目的商品，业务服务器可分别返回服装、食品和玩具等类目对应的第一API；对于连个不同交易平台的商品来说，业务服务器可根据交易平台的标志分别发送对应的第一API。

由此，业务服务器可根据商品的商品标记对业务进行区分，并为第一流程节点模块发送相应的第一API。

在本申请的一个实施例中，业务服务器还可获取移动终端的类型信息，并可根据移动终端的类型信息选择对应的第一API并发送。其中，移动终端的类型信息可包括操作系统类型、操作系统版本等。

举例而言，对于分别运行IOS(一种由苹果公司开发的手持设备操作系统)或Android系统(一种基于Linux的自由及开放源代码的操作系统)的移动终端，业务服务器可分别选择IOS系统对应的第一API和Android系统对应的第一API。

由此，业务服务器可根据移动终端的类型信息对业务进行区分，并为第一流程节点模块发送相应的第一API。

需要说明的是，第一触发按键对应有默认的API。而在第一流程节点模块接收到第一API后，第一API将作为与第一触发按键相对应的API，即可通过触发第一触发按键实现对第一API的调用。

S103，当第一触发按键被触发时，第二流程节点模块根据第一API生成第二页面，并将当前节点状态发送至业务服务器，其中，第二流程节点模块提供的第二页面中包括第二触发按键。

在本申请的一个实施例中，当第一触发按键被触发时，原生应用程序可调用并执行第一触发按键对应的第一API，并接收第一API返回的数据，并进行渲染以生成第二页面。其中，第二页面中包括第二触发按键。此时，原生应用程序进入第二流程节点对应的节点状态，第二流程节点模块可将当前节点状态发送至业务服务器。业务服务器接收到第二流程节点模块发送的当前节点状态时，可根据原生应用程序的当前节点状态选择对应的API返回至原生应用程序。

S104，接收业务服务器发送的第二API，并在第二触发按键被触发时第三流程节点模块根据第二API生成第三页面，其中，第二API与第二触发按键相对应。

其中，第二API的数量可为一个或多个，与第二触发按键相同，其数量与第二流程节点模块对应的节点状态所提供的业务数量一致。

当业务服务器接收到第二流程节点模块发送的原生应用程序的当前节点状态后，业务服务器可根据第二流程节点模块提供的商品标记或移动终端的类型信息等选择对应的第二API并发送至原生应用程序。具体地，可参照S102中对第一API的选择方法，在此不再赘述。

由此，业务服务器可根据商品的商品标记或移动终端的类型信息对业务进行区分，并为第二流程节点模块发送相应的第二API。从而，在第二触发按键被触发时，第三流程节点模块可根据第二API生成第三页面。

此外，为了确保原生应用程序能够识别不同API执行后返回的结果，可统一通过预设的API协议对各个API执行后返回的结果进行封装。在本申请的一个实施例中，可统一使用JSON(JavaScript Object Notation，脚本语言中的对象和数组)数据协议对各个API执行后返回的结果进行封装。

图2为根据本申请一个具体实施例的通过移动终端原生应用程序进行交易的方法的流程图。下面结合图2对本申请的通过移动终端原生应用程序进行交易的方法进行具体说明。图2以第一页面为商品展示页面为例进行说明。第一触发按键为订单触发按键，第一API为订单触发API，第二页面为订单页面，第二触发按键为支付触发按键，第二API为支付触发API，第三页面为支付页面。其中，商品展示页面包括商品详情页面或购物车页面，订单触发按键为下单按键或创建订单按键。

具体地，如图2所示，本申请实施例的通过移动终端原生应用程序进行交易的方法，包括以下步骤：

S201，提供商品详情页面或购物车页面的第一流程节点模块接收业务服务器发送的订单触发API。

在原生应用程序处于第一流程节点时，第一流程节点模块提供商品展示页面，即在交易过程中可通过商品详情页面展示各种商品的相关内容，或通过购物车页面放置所选择的商品。第一流程节点模块可接收业务服务器发送的订单触发API。其中，订单触发API与商品详情页面或购物车页面的订单触发按键即下单按键或创建订单按键相对应。

以某网游类商品的交易为例，在原生应用程序处于该网游类商品的商品展示页面时，业务服务器可根该网游类商品的商品标记，为该交易发送订单触发API。

S202，当下单按键或创建订单按键被触发时，第二流程节点模块根据订单触发API生 成订单页面。

S203，提供订单页面的第二流程节点模块接收业务服务器发送的支付触发API。

其中，支付触发API与支付触发按键相对应。

S204，当支付触发按键被触发时，第三流程节点模块根据支付触发API生成支付页面。

具体地，在支付触发按键被触发时，业务服务器可将支付触发按键对应的支付触发API发送至第二流程节点模块。在原生应用程序的支付触发按键被触发时，第三流程节点模块可调用支付触发API，从而生成支付页面。从而，用户可通过支付页面完成支付。

根据本申请实施例的通过移动终端原生应用程序进行交易的方法，原生应用程序在处于不同的节点状态时，可通过相应的流程节点模块将当前节点状态发送至业务服务器，以使业务服务器下发相应的API，并在该API对应的触发按键被触发时，进入下一流程节点状态，并由业务服务器继续下发该流程节点状态对应的API。由此，通过业务服务器可针对原生应用程序的不同节点状态分别发送API，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

上述实施例从原生应用程序的角度实现通过移动终端原生应用程序进行交易的方法，在本申请的一个实施例中，还可从业务服务器的角度实现上述方法，为此，本申请提出了另一种通过移动终端原生应用程序进行交易的方法。

图3为根据本申请一个实施例的另一种通过移动终端原生应用程序进行交易的方法的流程图。

如图3所示，本申请实施例的通过移动终端原生应用程序进行交易的方法，包括以下步骤：

S301，业务服务器接收原生应用程序中第一流程节点模块发送的当前节点状态，其中，第一流程节点模块提供的第一页面中包括第一触发按键。

原生应用程序在交易流程中随着流程的进行可处于不同的节点状态。原生应用程序在处于不同的节点状态时，相应的流程节点模块会将当前节点状态发送至业务服务器。因此，当原生应用程序处于第一流程节点模块对应的节点状态时，业务服务器可接收第一流程节点模块发送的当前节点状态，以便根据原生应用程序的当前节点状态选择对应的API返回至原生应用程序。

在本申请的实施例中，原生应用程序处于每个节点状态时，可提供与节点状态对应的页面，页面中包括与节点状态所提供的业务相对应的触发按键。其中，用户可通过触发某一触发按键控制原生应用程序执行接下来的业务。因此，当原生应用程序处于第一流程节 点模块对应的节点状态时，第一流程节点模块可提供第一页面，且第一页面中包括第一触发按键。

S302，业务服务器将第一触发按键对应的第一API发送至第一流程节点模块。

其中，第一API的数量可为一个或多个，与第一触发按键相同，其数量与第一流程节点模块对应的节点状态所提供的业务数量一致。

当业务服务器接收到第一流程节点模块发送的原生应用程序的当前节点状态后，业务服务器可根据第一流程节点模块提供的商品标记或移动终端的类型信息等选择对应的第一API并发送至原生应用程序。

在本申请的一个实施例中，业务服务器可获取第一流程节点模块提供的商品标记，并根据商品标记选择对应的第一API并发送。其中，商品标记可包括商品类目标记(例如游戏类、家电类等)或商品属性标记(促销类、特定优惠类、特定市场类、特殊交易流程类等)。

具体地，对于通过原生应用程序进行交易的商品，业务服务器可根据其类目或属性对其交易流程中的业务进行标记。不同的商品标记可与不同的第一API相对应，从而业务服务器可根据商品标记和原生应用程序的当前节点状态选择对应的第一API并发送。举例而言，对于服装、食品和玩具等不同类目的商品，业务服务器可分别返回服装、食品和玩具等类目对应的第一API；对于连个不同交易平台的商品来说，业务服务器可根据交易平台的标志分别发送对应的第一API。

由此，业务服务器可根据商品的商品标记对业务进行区分，并为第一流程节点模块发送相应的第一API。

在本申请的一个实施例中，业务服务器还可获取移动终端的类型信息，并可根据移动终端的类型信息选择对应的第一API并发送。其中，移动终端的类型信息可包括操作系统类型、操作系统版本等。

举例而言，对于分别运行IOS或Android系统的移动终端，业务服务器可分别选择IOS系统对应的第一API和Android系统对应的第一API。

由此，业务服务器可根据移动终端的类型信息对业务进行区分，并为第一流程节点模块发送相应的第一API。

需要说明的是，第一触发按键对应有默认的API。而在第一流程节点模块接收到第一API后，第一API将作为与第一触发按键相对应的API，即可通过触发第一触发按键实现对第一API的调用。

S303，业务服务器接收原生应用程序中第二流程节点模块发送的当前节点状态，其中，第二流程节点模块提供的第二页面中包括第二触发按键。

在本申请的一个实施例中，当第一触发按键被触发时，原生应用程序可调用并执行第一触发按键对应的第一API，并接收第一API返回的数据，并进行渲染以生成第二页面。其中，第二页面中包括第二触发按键。此时，原生应用程序进入第二流程节点对应的节点状态，第二流程节点模块可将当前节点状态发送至业务服务器。业务服务器接收到第二流程节点模块发送的当前节点状态时，可根据原生应用程序的当前节点状态选择对应的API返回至原生应用程序。

S304，业务服务器将第二触发按键对应的第二API发送至第二流程节点模块。

其中，第二API的数量可为一个或多个，与第二触发按键相同，其数量与第二流程节点模块对应的节点状态所提供的业务数量一致。

当业务服务器接收到第二流程节点模块发送的原生应用程序的当前节点状态后，业务服务器可根据第二流程节点模块提供的商品标记或移动终端的类型信息等选择对应的第二API并发送至原生应用程序。具体地，可参照S102中对第一API的选择方法，在此不再赘述。

由此，业务服务器可根据商品的商品标记或移动终端的类型信息对业务进行区分，并为第二流程节点模块发送相应的第二API。

此外，为了确保原生应用程序能够识别不同API执行后返回的结果，可统一通过预设的API协议对各个API执行后返回的结果进行封装。在本申请的一个实施例中，可统一使用JSON数据协议对各个API执行后返回的结果进行封装。

在本申请的一个具体实施例中，第一页面为商品展示页面，第一触发按键为订单触发按键，第一API为订单触发API，第二页面为订单页面，第二触发按键为支付触发按键，第二API为支付触发API。其中，商品展示页面可包括商品详情页面或购物车页面，订单触发按键为下单按键或创建订单按键。具体方法可参照上述结合图2所描述的具体实施例，在此不再赘述。

根据本申请实施例的通过移动终端原生应用程序进行交易的方法，原生应用程序在处于不同的节点状态时，可通过相应的流程节点模块将当前节点状态发送至业务服务器，以使业务服务器下发相应的API，并在该API对应的触发按键被触发时，进入下一流程节点状态，并由业务服务器继续下发该流程节点状态对应的API。由此，通过业务服务器可针对原生应用程序的不同节点状态分别发送API，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

为实现上述实施例的通过移动终端原生应用程序进行交易的方法，本申请还提出一种 通过移动终端原生应用程序进行交易的系统。

图4为根据本申请一个实施例的通过移动终端原生应用程序进行交易的系统的结构框图。

如图4所示，本申请实施例的通过移动终端原生应用程序进行交易的系统，包括：承载原生应用程序110的移动终端100和业务服务器200，其中，原生应用程序110包括：第一流程节点模块111、第二流程节点模块112和第三流程节点模块113。

其中，第一流程节点模块111用于将原生应用程序的当前节点状态发送至业务服务器200，并接收业务服务器200发送的第一API，其中，第一流程节点模块111提供的第一页面中包括第一触发按键，第一API与第一触发按键相对应。业务服务器200用于接收原生应用程序中第一流程节点模块111发送的当前节点状态，并将第一触发按键对应的第一API发送至第一流程节点模块111。

原生应用程序110在交易流程中随着流程的进行可处于不同的节点状态。原生应用程序110在处于不同的节点状态时，相应的流程节点模块会将当前节点状态发送至业务服务器200。因此，当原生应用程序110处于第一流程节点模块111对应的节点状态时，第一流程节点模块111可将原生应用程序110的当前节点状态发送至业务服务器200，以便业务服务器200根据原生应用程序110的当前节点状态选择对应的API返回至原生应用程序110。

在本申请的实施例中，原生应用程序110处于每个节点状态时，可提供与节点状态对应的页面，页面中包括与节点状态所提供的业务相对应的触发按键。其中，用户可通过触发某一触发按键控制原生应用程序110执行接下来的业务。因此，当原生应用程序110处于第一流程节点模块对应的节点状态时，第一流程节点模块可提供第一页面，且第一页面中包括第一触发按键。其

在本申请的一个实施例中，第一API的数量可为一个或多个，与第一触发按键相同，其数量与第一流程节点模块对应的节点状态所提供的业务数量一致。

当业务服务器200接收到第一流程节点模块111发送的原生应用程序的当前节点状态后，业务服务器100可根据第一流程节点模块111提供的商品标记或移动终端100的类型信息等选择对应的第一API并发送至原生应用程序110。

在本申请的一个实施例中，业务服务器200可获取第一流程节点模块111提供的商品标记，并根据商品标记选择对应的第一API并发送。其中，商品标记可包括商品类目标记(例如游戏类、家电类等)或商品属性标记(促销类、特定优惠类、特定市场类、特殊交易流程类等)。

具体地，对于通过原生应用程序110进行交易的商品，业务服务器200可根据其类目或属性对其交易流程中的业务进行标记。不同的商品标记可与不同的第一API相对应，从 而业务服务器200可根据商品标记和原生应用程序的当前节点状态选择对应的第一API并发送。举例而言，对于服装、食品和玩具等不同类目的商品，业务服务器200可分别返回服装、食品和玩具等类目对应的第一API；对于连个不同交易平台的商品来说，业务服务器200可根据交易平台的标志分别发送对应的第一API。

由此，业务服务器200可根据商品的商品标记对业务进行区分，并为第一流程节点模块111发送相应的第一API。

在本申请的一个实施例中，业务服务器200还可获取移动终端100的类型信息，并可根据移动终端100的类型信息选择对应的第一API并发送。其中，移动终端的类型信息可包括操作系统类型、操作系统版本等。

举例而言，对于分别运行IOS或Android系统的移动终端100，业务服务器200可分别选择IOS系统对应的第一API和Android系统对应的第一API。

由此，业务服务器200可根据移动终端100的类型信息对业务进行区分，并为第一流程节点模块111发送相应的第一API。

需要说明的是，第一触发按键对应有默认的API。而在第一流程节点模块接收到第一API后，第一API将作为与第一触发按键相对应的API，即可通过触发第一触发按键实现对第一API的调用。

第二流程节点模块112用于当第一触发按键被触发时，根据第一API生成第二页面，并将当前节点状态发送至业务服务器200，并接收业务服务器200发送的第二API，其中，第二流程节点模块112提供的第二页面中包括第二触发按键。业务服务器200用于接收原生应用程序中第二流程节点模块112发送的当前节点状态，并将第二触发按键对应的第二API发送至第二流程节点模块112。

在本申请的一个实施例中，当第一触发按键被触发时，原生应用程序110可调用并执行第一触发按键对应的第一API，并接收第一API返回的数据，并进行渲染以生成第二页面。其中，第二页面中包括第二触发按键。此时，原生应用程序110进入第二流程节点对应的节点状态，第二流程节点模块112可将当前节点状态发送至业务服务器200。业务服务器200接收到第二流程节点模块112发送的当前节点状态时，可根据原生应用程序110的当前节点状态选择对应的API返回至原生应用程序110。

在本申请的一个实施例中，第二API的数量可为一个或多个，与第二触发按键相同，其数量与第二流程节点模块对应的节点状态所提供的业务数量一致。

当业务服务器200接收到第二流程节点模块112发送的原生应用程序的当前节点状态后，业务服务器200可根据第二流程节点模块112提供的商品标记或移动终端100的类型信息等选择对应的第二API并发送至原生应用程序。具体地，可参照上述实施例中对第一 API的选择方法，在此不再赘述。

由此，业务服务器200可根据商品的商品标记或移动终端100的类型信息对业务进行区分，并为第二流程节点模块111发送相应的第二API。

此外，为了确保原生应用程序110能够识别不同API执行后返回的结果，可统一通过预设的API协议对各个API执行后返回的结果进行封装。在本申请的一个实施例中，可统一使用JSON数据协议对各个API执行后返回的结果进行封装。

在本申请的一个具体实施例中，第一页面为商品展示页面，第一触发按键为订单触发按键，第一API为订单触发API，第二页面为订单页面，第二触发按键为支付触发按键，第二API为支付触发API。其中，商品展示页面可包括商品详情页面或购物车页面，订单触发按键为下单按键或创建订单按键。具体地，可参照上述结合图2所描述的通过移动终端原生应用程序进行交易的方法具体实施例，在此不再赘述。

根据本申请实施例的通过移动终端原生应用程序进行交易的系统，原生应用程序在处于不同的节点状态时，可通过相应的流程节点模块将当前节点状态发送至业务服务器，以使业务服务器下发相应的API，并在该API对应的触发按键被触发时，进入下一流程节点状态，并由业务服务器继续下发该流程节点状态对应的API。由此，通过业务服务器可针对原生应用程序的不同节点状态分别发送API，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

为实现上述实施例的通过移动终端原生应用程序进行交易的方法和系统，本申请还提出一种移动终端。

图5为根据本申请一个实施例的移动终端的结构框图。

如图5所示，本申请实施例的移动终端具有原生应用程序110，原生应用程序包括：第一流程节点模块111、第二流程节点模块112和第三流程节点模块113。

其中，第一流程节点模块111用于将原生应用程序的当前节点状态发送至业务服务器，并接收业务服务器发送的第一API，其中，第一流程节点模块111提供的第一页面中包括第一触发按键，第一API与第一触发按键相对应。

原生应用程序110在交易流程中随着流程的进行可处于不同的节点状态。原生应用程序110在处于不同的节点状态时，相应的流程节点模块会将当前节点状态发送至业务服务器200。因此，当原生应用程序110处于第一流程节点模块111对应的节点状态时，第一流程节点模块111可将原生应用程序110的当前节点状态发送至业务服务器，以便业务服务器根据原生应用程序110的当前节点状态选择对应的API返回至原生应用程序110。

在本申请的实施例中，原生应用程序110处于每个节点状态时，可提供与节点状态对应的页面，页面中包括与节点状态所提供的业务相对应的触发按键。其中，用户可通过触发某一触发按键控制原生应用程序110执行接下来的业务。因此，当原生应用程序110处于第一流程节点模块对应的节点状态时，第一流程节点模块可提供第一页面，且第一页面中包括第一触发按键。其

在本申请的一个实施例中，第一API的数量可为一个或多个，与第一触发按键相同，其数量与第一流程节点模块对应的节点状态所提供的业务数量一致。

当业务服务器接收到第一流程节点模块111发送的原生应用程序的当前节点状态后，业务服务器100可根据第一流程节点模块111提供的商品标记或移动终端100的类型信息等选择对应的第一API并发送至原生应用程序110。

需要说明的是，第一触发按键对应有默认的API。而在第一流程节点模块接收到第一API后，第一API将作为与第一触发按键相对应的API，即可通过触发第一触发按键实现对第一API的调用。

第二流程节点模块112用于当第一触发按键被触发时，根据第一API生成第二页面，并将当前节点状态发送至业务服务器，并接收业务服务器发送的第二API，其中，第二流程节点模块112提供的第二页面中包括第二触发按键。

在本申请的一个实施例中，当第一触发按键被触发时，原生应用程序110可调用并执行第一触发按键对应的第一API，并接收第一API返回的数据，并进行渲染以生成第二页面。其中，第二页面中包括第二触发按键。此时，原生应用程序110进入第二流程节点对应的节点状态，第二流程节点模块112可将当前节点状态发送至业务服务器200。业务服务器200接收到第二流程节点模块112发送的当前节点状态时，可根据原生应用程序110的当前节点状态选择对应的API返回至原生应用程序110。

在本申请的一个实施例中，第二API的数量可为一个或多个，与第二触发按键相同，其数量与第二流程节点模块对应的节点状态所提供的业务数量一致。

当业务服务器接收到第二流程节点模块112发送的原生应用程序的当前节点状态后，业务服务器可根据第二流程节点模块112提供的商品标记或移动终端100的类型信息等选择对应的第二API并发送至原生应用程序。

此外，为了确保原生应用程序110能够识别不同API执行后返回的结果，可统一通过预设的API协议对各个API执行后返回的结果进行封装。在本申请的一个实施例中，可统一使用JSON数据协议对各个API执行后返回的结果进行封装。

在本申请的一个具体实施例中，第一页面为商品展示页面，第一触发按键为订单触发按键，第一API为订单触发API，第二页面为订单页面，第二触发按键为支付触发按键， 第二API为支付触发API。其中，商品展示页面可包括商品详情页面或购物车页面，订单触发按键为下单按键或创建订单按键。具体地，可参照上述结合图2所描述的通过移动终端原生应用程序进行交易的方法具体实施例，在此不再赘述。

根据本申请实施例的移动终端，其中的原生应用程序在处于不同的节点状态时，可通过相应的流程节点模块将当前节点状态发送至业务服务器，以使业务服务器下发相应的API，并在该API对应的触发按键被触发时，进入下一流程节点状态，并由业务服务器继续下发该流程节点状态对应的API。由此，通过业务服务器可针对原生应用程序的不同节点状态分别发送API，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

为实现上述实施例，本申请还提出一种业务服务器。

图6为根据本申请一个实施例的业务服务器的结构框图。

根据本申请实施例的业务服务器，移动终端包括原生应用程序，原生应用程序包括多个流程节点模块。

如图6所示，本申请实施例的业务服务器，包括：第一接收模块210、第一发送模块220、第二接收模块230和第二发送模块240。

其中，第一接收模块210用于接收原生应用程序中第一流程节点模块发送的当前节点状态，其中，第一流程节点模块提供的第一页面中包括第一触发按键。

原生应用程序在交易流程中随着流程的进行可处于不同的节点状态。原生应用程序在处于不同的节点状态时，相应的流程节点模块会将当前节点状态发送至业务服务器。因此，当原生应用程序处于第一流程节点模块对应的节点状态时，第一接收模块210可接收第一流程节点模块发送的当前节点状态，以便根据原生应用程序的当前节点状态选择对应的API返回至原生应用程序。

在本申请的实施例中，原生应用程序处于每个节点状态时，可提供与节点状态对应的页面，页面中包括与节点状态所提供的业务相对应的触发按键。其中，用户可通过触发某一触发按键控制原生应用程序执行接下来的业务。因此，当原生应用程序处于第一流程节点模块对应的节点状态时，第一流程节点模块可提供第一页面，且第一页面中包括第一触发按键。

第一发送模块220用于将第一触发按键对应的第一API发送至第一流程节点模块。

其中，第一API的数量可为一个或多个，与第一触发按键相同，其数量与第一流程节点模块对应的节点状态所提供的业务数量一致。

当接收到第一流程节点模块发送的原生应用程序的当前节点状态后，第一发送模块220可根据第一流程节点模块提供的商品标记或移动终端的类型信息等选择对应的第一API并发送至原生应用程序。因此，如图7所示，本申请实施例的业务服务器还可包括：第一API选择模块250和第二API选择模块260。

其中，第一API选择模块250用于获取第一流程节点模块提供的商品标记，并根据商品标记选择对应的第一API。其中，商品标记包括商品类目标记(例如游戏类、家电类等)或商品属性标记(促销类、特定优惠类、特定市场类、特殊交易流程类等)。

具体地，对于通过原生应用程序进行交易的商品，第一API选择模块250可根据其类目或属性对其交易流程中的业务进行标记。不同的商品标记可与不同的第一API相对应，从而第一API选择模块250可根据商品标记和原生应用程序的当前节点状态选择对应的第一API并发送。举例而言，对于服装、食品和玩具等不同类目的商品，第一API选择模块250可分别返回服装、食品和玩具等类目对应的第一API；对于连个不同交易平台的商品来说，第一API选择模块250可根据交易平台的标志分别发送对应的第一API。

由此，第一API选择模块250可根据商品的商品标记对业务进行区分，并为第一流程节点模块发送相应的第一API。

第二API选择模块260用于获取移动终端的类型信息，并可根据类型信息选择对应的第一API。其中，移动终端的类型信息可包括操作系统类型、操作系统版本等。

举例而言，对于分别运行IOS或Android系统的移动终端，第二API选择模块260可分别选择IOS系统对应的第一API和Android系统对应的第一API。

由此，第二API选择模块260可根据移动终端的类型信息对业务进行区分，并为第一流程节点模块发送相应的第一API。

需要说明的是，第一触发按键对应有默认的API。而在第一流程节点模块接收到第一API后，第一API将作为与第一触发按键相对应的API，即可通过触发第一触发按键实现对第一API的调用。

第二接收模块230用于接收原生应用程序中第一流程节点模块发送的当前节点状态，其中，第二流程节点模块提供的第二页面中包括第二触发按键。

在本申请的一个实施例中，当第一触发按键被触发时，原生应用程序可调用并执行第一触发按键对应的第一API，并接收第一API返回的数据，并进行渲染以生成第二页面。其中，第二页面中包括第二触发按键。此时，原生应用程序进入第二流程节点对应的节点状态，第二接收模块230可接收第二流程节点模块发送的当前节点状态，并根据原生应用程序的当前节点状态选择对应的API返回至原生应用程序。

第二发送模块240用于将第二触发按键对应的第二API发送至第二流程节点模块。

其中，第二API的数量可为一个或多个，与第二触发按键相同，其数量与第二流程节点模块对应的节点状态所提供的业务数量一致。

当接收到第二流程节点模块发送的原生应用程序的当前节点状态后，第二发送模块240可根据第二流程节点模块提供的商品标记或移动终端的类型信息等选择对应的第二API并发送至原生应用程序。具体地，可参照S102中对第一API的选择方法，在此不再赘述。

由此，可根据商品的商品标记或移动终端的类型信息对业务进行区分，并为第二流程节点模块发送相应的第二API。

此外，为了确保原生应用程序能够识别不同API执行后返回的结果，可统一通过预设的API协议对各个API执行后返回的结果进行封装。在本申请的一个实施例中，可统一使用JSON数据协议对各个API执行后返回的结果进行封装。

在本申请的一个具体实施例中，第一页面为商品展示页面，第一触发按键为订单触发按键，第一API为订单触发API，第二页面为订单页面，第二触发按键为支付触发按键，第二API为支付触发API。其中，商品展示页面可包括商品详情页面或购物车页面，订单触发按键为下单按键或创建订单按键。具体地，可参照上述结合图2所描述的通过移动终端原生应用程序进行交易的方法具体实施例，在此不再赘述。

根据本申请实施例的业务服务器，可根据不同的节点状态下发不同状态对应的API。由此，可为交易流程中的各个业务分别配置API，使得交易过程中复杂的业务能够灵活地接入原生应用程序，从而在原生应用程序上统一不同业务的交易过程，减轻了业务服务器的负担，且便于管理，集成了原生应用程序的良好用户体验以及业务灵活接入的优点。

在本申请的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”、“顺时针”、“逆时针”、“轴向”、“径向”、“周向”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本申请中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系，除非另有明确的限定。对于本领域的普通技术 人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

在本申请中，除非另有明确的规定和限定，第一特征在第二特征“上”或“下”可以是第一和第二特征直接接触，或第一和第二特征通过中间媒介间接接触。而且，第一特征在第二特征“之上”、“上方”和“上面”可是第一特征在第二特征正上方或斜上方，或仅仅表示第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”可以是第一特征在第二特征正下方或斜下方，或仅仅表示第一特征水平高度小于第二特征。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。