开发指南
消费者付款后，小游戏需要完成充值到账。比如，道具购买付款后，开发者需要真正将道具发放给消费者的账户openId中。
因此付款完成后，淘宝会发起奇门调用，告诉开发者对消费充值。以下为开发者需要开发的充值接口。
下面描述订单处理的流程。直充系统和商家的交互最可能的情况有以下两种：
① 直充系统发起充值请求，服务商返回成功或者失败结果，直充系统给商家打款或者给买家退款。
② 直充系统发起充值请求，开发者发现自己无法在5秒内返回确定结果（TOP请求超时是5秒），返回Underway，直充系统过一段时间继续发送查询请求，开发者可以返回订单处理结果，或者仍然返回Underway表示订单仍在处理。开发者订单处理结束后，使用异步接口告诉直充系统订单处理的结果。直充系统可以给商家打款或者给买家退款。异步通知可以加快订单履行速度，提高用户体验，请尽量使用。
③ 用户付款成功后，为了防止开发者无尽地返回Underway导致订单不能完结，做了以下的约定：
a）0-60分钟，直充会发起充值请求，充值请求调用成功一次后不再调用充值请求。默认3分钟调度一次，随着调度次数约定间隔也会加大。（并发情况下一个订单可能会有多次充值调用，商家要做好幂等）
b）60-100分钟，直充系统调用查询操作，100分钟后最后查询一次，默认3分钟调度一次，随着调度次数约定间隔也会加大，如果仍然是未充值成功则直接退款给买家，订单强制关闭，并发起一次cancel请求通知商家。
以上所有时间点，以一笔订单的买家支付成功时间为起点。
一、基本约定
1. 淘宝订单号和商家订单号一一对应。
2. 对于一笔订单的充值请求，厂商必须返回成功/失败/处理中，充值请求可能会有重复。商家必须针对同一淘宝订单号的重复充值请求做控制，相同订单号的充值请求可能会同时到达，请做好并发处理。订单的query请求，厂商返回的值参考本文档“订单查询接口”部分的返回值说明。
3. 在充值请求发出后，淘宝会对同一笔订单发送query请求，直到订单完结状态或者100分钟结束。超过100分钟未完结，订单强制关闭，退款给买家。“订单完结状态”定义请看本文档最后面的附录。
4. 商家应该尽快处理UNDERWAY状态的订单，使其要么成功，要么失败。
5. 如果超过100分钟，仍然为UNDERWAY状态，淘宝将取消相应订单，然后为买家退款，并不再进行任何接口通知。淘宝每次对商家的HTTP请求超时时间为5秒（查询、充值）。
6. 商品信息快照记录了商品成交时的样子，为合计金额和cardId、gameId、section1、section2四个字段对应中文名称字符串的组合，用”|”号隔开，快照信息不应该在业务逻辑中使用，仅用于记录日志保存以备查。淘宝所传的快照应为淘宝数据库中的信息，商家所传的快照应为商家数据库中的信息。
7. 【注意】无论是淘宝主动查询商家订单状态，还是商家异步通知淘宝订单状态，还是商家充值接口返回的订单状态，只要商家返回的状态是“订单完结状态”，淘宝就会认为订单完结，直接转支付宝交易或者退款给买家，订单状态不能再发生变更。比如淘宝查询时返回“failed”，但是后来外部商家又异步通知订单为“success”，淘宝是不会处理后面的“success”的；“订单完结状态”和“订单中间状态”定义看最后面的附录。
8. 厂家返回xml时，如果有些字段为空，就返回空的值，对应xml字段不能省略，否则会引起xml解析出错。如成功状态下没有failedReason，则可以返回<failedReason></failedReason>。
9. 商家务必做到结果的幂等性，比如上次查询或者充值某笔订单返回成功结果，下次同一订单的查询或者充值也返回成功结果。
二、实现平台充值对应的奇门接口
以下接口的服务地址（host:port/query.do）是商家在开发者控制台平台上配置的，开发者控制平台在需要调用对应商家服务时获取这个地址，并且添加相应参数，通过http格式发送给商家。商家接到对应请求后，需要调用sdk的函数验证相应签名。
1. 订单查询接口（taobao.game.charge.zc.query）
a) 请求地址样例
http://host:port/query.do?coopId=xxx&tbOrderNo=xxx&version=xxx
1) 请求参数说明
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
coopId |
商家编号，商家id |
必选 |
String |
/ |
tbOrderNo |
淘宝的订单号，tb.virtualTrade返回的orderId |
必选 |
String |
/ |
version |
接口版本 |
必选 |
String |
1.2.0 |
2)请求返回结果示例（参考淘宝开放平台的开发文档，下面内容如果和开发文档不一致，以开发文档的为准）
（返回内容必须和以下一摸一样，大小写一致，否则淘宝这边解析将会抛出异常，返回字符的编码是GBK，某个字段即使不是必选，不需要返回内容，xml格式还是需要返回，如<failedCode></failedCode>。）
响应状态和格式
HTTP/1.1 200 OK
content-type:text/xml ;charset=GBK
<gamezctopquery> <tbOrderNo>2130547689</tbOrderNo> <coopOrderSuccessTime>201507290913</coopOrderSuccessTime> <coopOrderStatus>SUCCESS</coopOrderStatus> <failedReason>do not have the order</failedReason> <coopOrderNo>231029383</coopOrderNo> <failedCode>0101</failedCode> <coopOrderSnap>moshou|qufu1</coopOrderSnap> </gamezctopquery>
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
tbOrderNo |
淘宝订单号 |
必选 |
String |
/ |
coopOrderNo |
商家的订单号 |
必选 |
String |
/ |
coopOrderStatus |
商家的订单状态 |
必选 |
String |
见附录的订单状态 |
当coopOrderStatus为 SUCCESS 时 |
? |
|||
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
coopOrderSnap |
商品信息快照 |
必选 |
String |
/ |
coopOrderSuccessTime |
充值成功时间 |
必选 |
格式为yyyyMMddHHmmss |
/ |
当coopOrderStatus 为ORDER_FAILED、FAILED时 |
/ |
|||
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
failedCode |
失败代码 |
必选 |
String |
见附录的失败代码 |
failedReason |
失败原因 |
必选 |
String |
/ |
当coopOrderStatus 为UNDERWAY时 |
表示充值中 |
|||
3) 说明
该接口用于淘宝向开发者进行订单查询：
a) [充值成功coopOrderStatus=SUCCESS，并返回充值成功时间、商品信息快照]；
b) [充值中coopOrderStatus=UNDERWAY]；
c) [充值失败coopOrderStatus=FAILED，并说明失败代码和原因，此时订单关闭]；
d) [订单创建失败coopOrderStatus=ORDER_FAILED，并说明失败代码和原因]。
如果发现签名验证等其他错误，返回GENERAL_ERROR，失败代码见附件。
coopOrderNo在coopOrderStatus为 SUCCESS、UNDERWAY、FAILED时必须返回，其余情况不需返回。
2. 订单充值接口（taobao.game.charge.zc.order）
1）请求地址样例
http://host:port/charge.do?coopId=xxx&tbOrderNo=xxx&cardId=xxx&cardNum=xxx&customer=xxx&sum=xxx&gameId=xxx§ion1=xxx§ion2=xxx¬ifyUrl=xxx&version=xxx
2）请求参数说明
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
coopId |
商家账号对应的商家ID |
必选 |
String |
正常调用支付API的时候，淘宝周转到服务端会带上这个参数，服务端记下来后，就可以调用其他API了 |
tbOrderNo |
淘宝的订单号(tb.virtualTrade返回的orderId) |
必选 |
String |
/ |
cardId |
充值商品的TSC编码/C店为商家编码，由商家在商品发布时自己编辑。 |
必选 |
String |
需要开发者在自己的直充系统中维护对应关系 |
cardNum |
充值卡数量 |
必选 |
String |
/ |
customer |
被充值帐号 |
必选 |
String |
小游戏里面为openId |
sum |
本次充值总金额，代表用户支付的金额 |
必选 |
String |
单位为元，如200.00代表200.00元 |
gameId |
充值游戏编号（游戏品牌ID） |
可选 |
String |
需要开发者自行维护对应关系 |
section1 |
一级分类，如游戏大区 |
可选 |
String |
需要开发者自行维护对应关系 |
section2 |
二级分类，如游戏子服 |
可选 |
String |
需要开发者自行维护对应关系 开发者可视情况使用cardId、gameId、section1、section2中的部分或全部来确定一个充值目标 |
tbOrderSnap |
商品信息快照 |
必选 |
String |
单件宝贝金额|宝贝标题|宝贝类型|一级区服名（网游）|二级区服名（网游）| 扩展信息（包含外部订单outOrderId） |
notifyUrl |
异同通知地址 |
必选 |
String |
异步通知地址，此地址是固定值。商家可以不用这个值，为早期商家做兼容使用。（这个字段已经不使用了，可以忽略） |
version |
接口版本 |
必选 |
String |
1.2.0 |
3) 请求返回结果，返回字符的编码是GBK；
HTTP/1.1 200 OK
content-type:text/xml ;charset=GBK
<gamezctoporder> <tbOrderNo>1232131321</tbOrderNo> <coopOrderSuccessTime>20150729135912</coopOrderSuccessTime> <coopOrderStatus>SUCCESS</coopOrderStatus> <failedReason>the order is succeed</failedReason> <coopOrderNo>123242423</coopOrderNo> <failedCode>0701</failedCode> <coopOrderSnap>taobao|game|order</coopOrderSnap> </gamezctoporder>
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
tbOrderNo |
淘宝订单号 |
必选 |
String |
/ |
coopOrderNo |
商家的订单号 |
必选 |
String |
/ |
coopOrderStatus |
商家的订单状态 |
必选 |
String |
见附录的订单状态 |
当coopOrderStatus为 SUCCESS 时 |
/ |
|||
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
coopOrderSnap |
商品信息快照 |
必选 |
String |
/ |
coopOrderSuccessTime |
充值成功时间 |
必选 |
格式为yyyyMMddHHmmss |
/ |
当coopOrderStatus 为FAILED、ORDER_FAILED时 |
/ |
|||
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
failedCode |
失败代码 |
必选 |
String |
见附录的失败代码 |
failedReason |
失败原因 |
必选 |
String |
/ |
当coopOrderStatus 为UNDERWAY时 |
表示充值中 |
|||
4) 说明
该接口用于淘宝向开发者发起充值请求，开发者实现该接口必须至少包含两个功能，a、完成自己订单系统中订单的创建；b、为买家完成充值。
充值结果可以同步返回，也可以异步返回。返回视情况而定：
a) [充值成功coopOrderStatus=SUCCESS，并返回充值成功时间、商品信息快照]；
b) [充值中coopOrderStatus=UNDERWAY]；
c) [充值失败coopOrderStatus=FAILED，并说明失败代码和原因，此时订单关闭]；
d) [订单创建失败coopOrderStatus=ORDER_FAILED，并说明失败代码和原因]。
如果发现签名验证等其他错误，返回GENERAL_ERROR，失败代码见附件。
coopOrderNo在coopOrderStatus为 SUCCESS、UNDERWAY、FAILED时必须返回，其余情况不需返回。
此充值接口返回的状态中如果订单中充值帐号错误等原因导致的不可以充值成功，此类情况下返回订单完结状态FAILED。
参数tbOrderSnap表示订单快照，在最后的竖线右边，为一个对象的json序列化内容，小游戏如果需要提取该信息，需要考虑后续的扩展性。
ip与ipv6只会有一个有值，样例：
{"buyerIp":"117.136.38.61","buyerIpv6":""}
或{"buyerIp":"","buyerIpv6":"2409:8928:c5e:7cac:d45c:92e6:7b41:8317"}
为了方便部分商品能够发布SKU商品售卖，增加sku商家编码传参，商家在发布sku信息时，必须填写商家编码，直充平台将充值时用户选择的sku对应商家编码，通过tbOrderSnap传给商家，商家通过TSC+商家编码(cardId+outerId)映射充值。
tbOrderSnap完整结构样例：单件宝贝金额|宝贝标题|宝贝类型|一级区服名（网游）|二级区服名（网游）|{"buyerIp":"","buyerIpv6":"2409:8928:c5e:7cac:d45c:92e6:7b41:8317","outerId":"1111","outOrderId":"20000000000sss"}
3. 订单取消接口（taobao.game.charge.zc.cancel）
1）请求地址样例
http://host:port/cancel.do?coopId=xxx&tbOrderNo=xxx&version=xxx
2）请求参数说明
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
coopId |
商家编号 |
必选 |
String |
/ |
tbOrderNo |
淘宝的订单号 |
必选 |
String |
tb.virtualTrade返回的orderId |
version |
接口版本 |
必选 |
String |
1.2.0 |
3) 请求返回结果，返回字符的编码是GBK；
HTTP/1.1 200 OK
content-type:text/xml ;charset=GBK
<gamezctopcancel> <tbOrderNo>14213421313</tbOrderNo> <coopOrderNo>13114232131</coopOrderNo> <coopOrderStatus>CANCEL</coopOrderStatus> <coopOrderSnap>taobao|game service</coopOrderSnap> <coopOrderSuccessTime>201507291347</coopOrderSuccessTime> <failedCode>0101</failedCode> <failedReason>the order is cancel</failedReason> </gamezctopcancel>
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
tbOrderNo |
淘宝订单号 |
必选 |
String |
/ |
coopOrderNo |
商家的订单号 |
必选 |
String |
/ |
coopOrderStatus |
商家的订单状态 |
必选 |
String |
见附录的订单状态 |
当coopOrderStatus为 SUCCESS 时 |
/ |
|||
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
coopOrderSnap |
商品信息快照 |
必选 |
String |
/ |
coopOrderSuccessTime |
充值成功时间 |
必选 |
格式为yyyyMMddHHmmss |
/ |
当coopOrderStatus 为CANCEL、FAILED时 |
/ |
|||
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
failedCode |
失败代码 |
必选 |
String |
见附录的失败代码 |
failedReason |
失败原因 |
必选 |
String |
/ |
4) 说明
该接口用于淘宝向开发者进行订单取消，返回值视情况而定：
a) [充值成功coopOrderStatus=SUCCESS，并返回充值成功时间、商品信息快照]；
b) [订单已取消coopOrderStatus=CANCEL，返回failedCode=0901，并说明原因]；
c) [充值中coopOrderStatus=UNDERWAY]；
d) [充值失败coopOrderStatus=FAILED，并说明失败代码和原因]。
如果发现签名验证等其他错误，返回GENERAL_ERROR，失败代码见附件。
无论返回值是什么，淘宝都会进行退款。coopOrderNo在coopOrderStatus为 SUCCESS、CANCEL、UNDERWAY、FAILED时必须返回。
4. 使用sdk校验奇门发来的请求（验证签名）
奇门网关会组装服务地址和参数，以http的形式将请求发送到淘宝开放平台指定的地址，服务商的服务在接收到奇门请求后，需要使用sdk的方法进行校验，校验内容包括签名和服务到达的时间。服务商家最好把奇门调用的内容和时间再日志里记录一下，同时把每次调用的request_id记录下来，这样有问题的话奇门网关比较容易定位原因。request_id在请求的上下文环境中，内容类似为"request_id":"z26j8t11hzpf。
调用淘宝的服务需要使用开放平台上的sdk，在应用管理 sdk下载下可以下载各个版本的sdk，以下以java描述，其他版本的函数名字相似但是可能有点不同。
调用SDK验证签名的返回如下，奇门发送请求信息给商家服务器时会在参数里增加一个sign参数。下面函数的secret参数使用厂商在第一步骤申请Appkey时得到的。
/** * 校验SPI请求签名，适用于请求体是xml/json等可用文本表示的POST请求。 * * @param request 请求对象 * @param secret app对应的secret * @return result: isSuccess()为true则校验通过 */ CheckResult result = SpiUtils.checkSign(req, secret);
签名校验可以参考文档
奇门签名算法 及SPI服务接入文档 （签名校验部分），如果没有对应语言的sdk，可以直接编写校验服务。
注意：
① HTTP请求中的URL参数编码字符集、字符串转字节流进行MD5摘要时的字符集要保持一致，否则会导致含中文参数的签名与TOP不一致。
② 编码使用的是GBK。
5. 调用平台接口主动返回充值结果
该接口的调用，开发者必须下载淘宝开放sdk，使用sdk提供的方法发起调用。
TOP API名字：taobao.game.charge.zc.updatesupplierorder。
说明
a) 该接口是充值接口的补充，商家可以通过此接口向淘宝通知订单信息。
b) 商家在其异步返回订单结果时需要调用该接口，异步调用一旦发生，则表明商家自己的订单创建成功了（这里是指订单创建成功，不是订单充值成功）。商家创建自己订单失败必须在同步调用的时候返回。
c) 商家收到成功[T]结果，可以理解为，淘宝系统已正确理解了订单异步结果，否则必须再次发起回调，直到收到[T]为止。异步结果的逻辑请结合基本约定第8小点。
d) 当淘宝根据商家订单号找不到淘宝的订单时，返回失败结果[F]，并说明失败原因，如[0104]。
e) coopOrderStatus仅为[SUCCESS、CANCEL、FAILED]，非以上状态淘宝返回[F]，并说明[0701]。
f) 异步结果错误返回主要有以下4大类：
错误号 |
错误原因 |
0101 一般是缺少参数 |
① The coopOrderStatus is null. ② 参数中有某个参数为空" |
0104 一般是找不到对应的订单 |
① 商家编号小等于0，不合法 ② 订单号小等于0，不合法 ③ 商家不存在 ④ 商家编号和淘宝订单里保存的商家编号不一致 ⑤ 淘宝更新订单状态失败 |
0701 一般原因是非法的订单状态转换 |
① 状态不是SUCCESS、FAILED、CANCEL中的一个 ② 淘宝订单已经失败，但是异步回调通知订单成功，不合法 ③ 淘宝订单已经成功，但是异步回调通知订单失败或者取消，不合法 |
0103 一般原因是参数有误 |
① 状态为成功，但是快照或者订单成功时间有一个为空 ② 状态为失败或者取消，但是失败代号或者失败原因有一个为空 ③ 订单成功时时间参数转化为Date类型失败 ④ 异步调用在买家付款后的100分钟内有效 |
6. 对账接口（按需对接）
该接口的调用，开发者必须下载淘宝开放sdk，使用sdk提供的方法发起调用。
TOP API名字：taobao.game.charge.zc.audit。
请求参数说明
参数 |
说明 |
是否必选 |
参数类型 |
备注 |
coopId |
商家标识 |
必选 |
String |
/ |
tbOrderNo |
淘宝订单号（tb.virtualTrade返回的orderId） |
必选 |
String |
订单号之间用英文逗号分隔 |
version |
接口版本 |
必选 |
String |
1.2.0 |
1) 请求返回结果
<response>
<tbOrders>
<tbOrder>
<tbOrderNo>2232113369</tbOrderNo>
<auctionPrice>1800</auctionPrice>
<buyAmount>1</buyAmount>
<chargeAccount>adsdsafsadf</chargeAccount>
<payedFee>1800</payedFee>
<presentPoint>18</presentPoint>
<usePoint>0</usePoint>
<tcStatus>6</tcStatus>
<ecardOrderStatus>4</ecardOrderStatus>
<alIPayOrderId>2009121605133022</alIPayOrderId>
<paytime>20091216133340</paytime>
<endTime>20091216133342</endTime>
</tbOrder>
<tbOrder>
<tbOrderNo>2232108203</tbOrderNo>
<failedCode>0104</failedCode>
<failedReason>order is not exist</failedReason>
</tbOrder>
</tbOrders>
</response>
2) 异步接口的调用方法请参考文下方“使用SDK调用淘宝服务 ”。
3) 说明
返回的找到的字段值的说明：
auctionPrice; 商品单价 buyAmount; 购买数量 chargeAccount; 充值号码 payedFee; 付款金额 ecardOrderStatus; 直冲订单状态 值对应状态说明见附录直冲订单状态 tcStatus; 交易操作结果（状态）值对应状态说明见附录交易订单状态(资金状态) tbOrderNo; 淘宝订单号 alIPayOrderId;支付宝流水号 usePoint; 使用积分 presentPoint; 赠送积分 paytime; 交易付款时间 endTime; 交易完结时间 coopId; 商家编号 coopOrderNo; 商家订单号 failedCode; 失败编码 failedReason; 失败原因
查询接口的对账时间为凌晨的2点—7点，其它时间段不提供对账功能，对账接口一次最多只支持20条订单的查询
7. 设置服务地址和测试
1）服务地址设置
开发者开发完对应的服务后，将相应的服务在服务器的某个地址上运行起来，接口自测后，然后登录开发者控制台，路径：开发->选择应用->(左边的)API服务提供->淘宝游戏充值->点击对应接口的开发测试。
填写服务地址，其中的测试环境地址和线上环境地址对应厂商自己提供该服务的地址，如用http://125.34.12.23/charge.do 来表示自己接受淘宝下单调用的地址，从而完成消费者的充值。
2）接口测试
服务地址设置好，点击进入测试：
1、冒烟测试：冒烟测试只是测试奇门网关是否可以调通你的服务，你的服务返回内容是否正常，返回内容是否可以正常解析这里都是不能测出来的。
2、编码测试：验证返回的编码是否为GBK，如果不是则测试失败，也是不能测试返回结果是否格式正常。
3、签名测试：这个测试奇门网关会故意把签名弄错，商家服务使用sdk测试签名时返回False。商家需要返回签名错误的结果，其中错误类型为GENERAL_ERROR，错误码为0102（见附录）因此，服务需要返回如下的内容：（针对query），其他的order和cancel最外面的gamezctopquery不同，具体差别看接口的开发文档。
<gamezctopquery> <tbOrderNo>2130547689</tbOrderNo> <coopOrderSuccessTime>201507290913</coopOrderSuccessTime> <coopOrderStatus>GENERAL_ERROR</coopOrderStatus> <failedReason>签名失败</failedReason> <coopOrderNo>231029383</coopOrderNo> <failedCode>0102</failedCode> <coopOrderSnap>moshou|qufu1</coopOrderSnap> </gamezctopquery>
3）服务测试
上述的接口测试只是完成最基本的测试，只是认为商家服务在线，但是服务返回结果形式是否正确，是否做到幂等等能力没有办法测试，此时需要进行线上测试。
线上测试方法：进行线上测试需要先发布5个以上商品，店铺正式上线才可以进行，先在店铺内发布一件商品，用其他淘宝帐号到自家店里通过小游戏拍下一个商品，查看服务处理是否正常。
接口上线
推进接口状态至完成；接口状态如下处于【线上运行中】时，可以进行线上测试。
订单查询
开发者可以通过 虚拟充值> 订单查询 进行相关订单的查询，输入淘宝的订单号即可进行查看。
线上测试时以下几点一定需要确认一下：
1）各种情况下返回的参数格式和内容，测试一下奇门是否解析正确。订单成功和失败返回的必选参数是不一样的的（必选参数是否都设置了），有商家在订单处理失败时，返回的结果里也设置了coopOrderSuccessTime这个值，虽然设置了也没有关系，但是内容却设置成“充值失败”而不是yyyyMMddHHmmss这种格式的时间信息，这样导致返回结果解析失败，导致这个返回无效，订单可以等了60分钟才关闭。
2=）针对某一个订单，确保每次查询都是返回同样类型的信息，比如订单处理成功，则之后任何一次查询，只要订单号一样，就返回成功，在调用充值操作时，如果发现对应订单号的订单已经充值成功，则也返回成功结果。
3）针对取消，如果取消操作成功，返回CANCEL结果，如果在接到取消请求前订单已经处理成功，则返回SUCCESS表示订单处理成功。
4）在充值请求返回underway，当操作操作成功后，尽量快的调用异步回调接口通知淘宝这边，这样之后的打款或者退款给买家才可以尽快进行，增加用户体用。
4）服务测试路径
服务不能因为正式流程走通了就直接发布上线了。需要测试各种异常情况下，服务返回内容是否正常。（流程1和流程5务必都测试一下，有商家只有一个可用某些情况下发生资损）
流程1：淘宝发送充值请求，服务返回成功，查看订单是否处理成功。
流程2：淘宝发送充值请求，服务返回失败，查看订单是否处理成功。
流程3：淘宝发送充值请求，服务返回UNDERWAY，过一段时间淘宝发送查询请求，服务返回成功。
流程4：淘宝发送充值请求，服务返回UNDERWAY，过一段时间淘宝发送查询请求，服务返回失败。
流程5：淘宝发送充值请求，服务返回UNDERWAY，过一段时间淘宝发送查询请求，服务返回UNDERWAY。过一段时间服务异步通知订单处理成功。
流程6：淘宝发送充值请求，服务返回UNDERWAY，过一段时间淘宝发送查询请求，服务返回UNDERWAY。过一段时间服务异步通知订单处理失败。
流程7：淘宝发送充值请求，服务返回UNDERWAY，过一段时间淘宝发送查询请求，服务返回UNDERWAY。等60分钟后，淘宝会发起取消操作，服务返回成功（表示订单处理成功）。
流程8：淘宝发送充值请求，服务返回UNDERWAY，过一段时间淘宝发送查询请求，服务返回UNDERWAY。等60分钟后，淘宝会发起取消操作，服务返回失败（表示订单处理失败）。
流程9：淘宝发送充值请求，服务返回UNDERWAY，过一段时间淘宝发送查询请求，服务返回UNDERWAY。等60分钟后，淘宝会发起取消操作，服务返回取消（表示订单取消操作成功）。
注意看看服务有没有可能做以下的处理。
1、淘宝发送充值请求，服务返回UNDERWAY，之后淘宝再发送查询请求，服务不能返回订单未创建，如果订单没有处理好，返回UNDERWAY。
2、服务已经返回成功、失败、取消结果，但是后来又异步通知我们不同的结果（如第一次是成功，后来失败），我们以第一次返回的结果为准。
特别需要关注一点：
这边由于是集群并发处理订单，因此一笔订单可能同时在两台机器上进行处理，各个接口都需要做到幂等。以下是一个错误的例子，可能造成资损：
2016-11-09 12:14:51,200 机器1发起查询请求。 2016-11-09 12:14:51,281 机器1收到对方返回充值失败的结果。 2016-11-09 12:14:51,144 机器2发起查询请求。 2016-11-09 12:14:51,228 机器2收到对方充值成功的结果。 充值成功的结果先返回（快60毫秒），但是由于返回后这边是扔到线程池里进行处理， 机器1的结果先执行了，导致订单最后失败了。文档里虽然说过以第一次返回的结果为准， 但是时间间隔这么近，如果同一笔订单返回不同的结果，还是可能出现问题的。
务必保证查询请求，对于一笔订单的多次请求都返回一样的结果。如果两次充值请求几乎并发执行，第二次的充值请求发现充值过程正在执行，无法马上确定结果的，先返回underway。
5）发布上线
奇门对接开发测试完后必须发布，若未发布上线，异步调用次数的上限为每天5000次。
