对接是从第一次调通之后才开始算范围

调通一次的那个画面

对接需求大多是以服务名字的形式进来的。支付、地图、短信、登录。名字看上去工作量差不多，报价回来却各不相同。

对开发的人来说，第一次成功很快。把文档里的示例原样贴进去，申请一把测试密钥，看到响应回来，这一段花不了多久。屏幕上弹出收银台、出现一条成功提示，说接好了并不算夸张。

只是那个画面是顺利的那一次。产品上线之后，不顺利的那些每天都会来。定对接范围，就是把这些情况数清楚，报价拉开差距的地方基本也在这里。

开户和审核先占掉日程

不少外部服务不是开发者一个人能开的。要用公司主体去申请，交材料，等审核过了才有线上用的密钥。凡是牵涉资金、实名信息、对外发送的服务，基本都带这道流程。

这段时间不在开发排期里。代码写得再快，审核没下来就没法用真实账号验证，而审核的条件里有时还包含你自己的页面或者协议文案。被退回一次，改完再交，又往后挪一截。

所以谈对接报价，第一件要定的是谁去申请。把开户和审核沟通一并交出去，和自己去跑、只把开发交出去，排出来的日程表是两回事。

沙箱里过得去、线上过不去的那些

大多数服务方会另给一套测试环境。在那里卡号随便填都能通过，短信也不会真的发出去，开发和自测都在这个环境里完成。

切到线上就开始附加条件。有的要求把调用方的域名或服务器地址提前登记。有的要求接收结果的地址必须是外部能访问、证书齐全的正式地址。有的会核对结算账户或者发送方信息，和登记内容对不上就直接拒掉。

这些都不是代码问题，是备料问题。而备料没齐，代码写完了也上不了线。在启动阶段就把上线所需的清单要过来，是压缩这一段最直接的办法。

失败、重复和取消的流程

成功路径只有一条。失败路径有好几条，对接的工作量大多堆在这几条上。

最典型的是等响应等到超时。你这边记成失败，对方那边其实已经处理完了。用户以为没成，再点一次，同一笔请求就进去了两次。到这里就需要一套机制，让同一笔请求收两次也只处理一次，再加一个把两边记录对起来的界面。

取消和退款是另一条线。整笔取消和部分取消不一样，对方已经结算过之后流程又会变。通知结果的回调重复到达也很常见，所以同一条通知收几次，结果都不能对不上。

这些流程要做到哪一步，才是对接范围的真正内容。询价时把要接的服务名字，连同”取消怎么处理”的答案一起给过来，报价会准得多。

对方改规格的那一天

你的代码一行没动，对接也可能坏掉。服务方会停掉旧版本，会把响应里原本有的字段去掉，会换掉鉴权方式。通知是会提前发的，但它发给的是当初开户的那个人。

所以对接不像一次做完就结束的条目，更像需要一直看着的条目。至少把服务方的通知邮件导到一个真的有人看的地址，再把接进来的外部服务和每个账号挂在谁名下，整理成一页。这一页以后会帮上大忙。

把要接的服务名字发过来就行

Weple 接到对接需求，会先把它变成一个关于情况的问题，而不是关于服务的问题。账号和审核谁来扛，上线之前对方要什么，取消和重复要处理到哪一步。分开写出来，范围就露出来了。按什么单位计价，价格说明里写着。要是理下来发现某个服务现在还不值得接，我们会陪你把绕过去的路一起找出来。