310 lines
12 KiB
Markdown
310 lines
12 KiB
Markdown
方案介绍
|
||
更新时间：2025-03-26
|
||
阅读数：21079
|
||
1.业务介绍
|
||
快手平台提供了凭证发送和核销能力，给有线上发码及线下消费的交易商家提供服务。码商可以通过入驻快手小店及电商开放平台，给快手商家提供电子凭证的发送以及核销的服务。目前快手整体提供了三种电子凭证的对接能力
|
||
|
||
1.快手发码和核销：此种方式无需ISV对接，联系我们的快手电子平台运营同学，即可接入，这种方式属于接入最快的方式。所有券码的生命周期由快手平台负责，商家可以自定义券的应用场景，有效期等。【平台发码产品使用手册（可忽略门店管理）】
|
||
|
||
2.码库发码、快手核销：商家可以通过excel导入已有的券码，核销由快手平台核销，这种方式也无需ISV对接，但是需要商家手动把外部二维码导入。【码库发码产品使用手册（可忽略门店管理）】
|
||
|
||
3.商家发码和核销：这种方式下由商家系统自己负责发码，并且将码的副本信息同步给快手平台，双方共同管理券码的生命周期，本方案主要介绍这种接入方式。
|
||
|
||
4. 新开发的跨门店结算/按卡券结算能力/poi接入的相关细节可以查看对接实践
|
||
|
||
|
||
|
||
名词解释
|
||
发码方式：用户购买后商家通过某种方式把卡券发送给用户，目前快手支持3种发码方式：商家发码、码库发码、快手平台发码
|
||
|
||
i、商家发码：商家通过对接收单和发码2个接口，当用户购买商品后，快手会「推送订单给商家」，以及商家必须在超时时效内「回调发码的结果」给快手
|
||
|
||
ii、码库发码：商家需提前准备一批「未核销」的卡券，上传到快手小店的「码库」中。当用户购买商品后，快手会自动从「码库」中选择一个「未核销」的卡券发给用户。无需商家对接「发码接口」
|
||
|
||
iii、快手平台发码：商家无需提前准备卡券，由快手侧自动生成唯一的卡券发给用户。缺点是这批卡券是快手生成的，商家系统是不存在这些卡券的，所以不支持商家核销，只能在快手内核销
|
||
|
||
|
||
|
||
核销方式：用户收到卡券后可以通过不同方式核销掉，目前快手支持2中核销方式：商家核销、快手核销
|
||
|
||
i、商家核销：用户收到卡券后，拿着卡券去商家系统进行核销，核销完成后商家需回传核销状态给快手，快手驱动卡券状态到『已核销』。商家需要对接『核销回调接口』
|
||
|
||
ii、快手核销（非自动）：商家使用快手商家版APP或者快手小店后台「券码工具箱」，对用户卡券进行核销。核销后快手会驱动卡券状态到『已核销』。商家无需对接核销接口
|
||
|
||
iii、自动核销（只发不核）：用户的卡券发放成功后，快手会自动核销，适用于少数业务场景。该核销方式必须同步给快手小二并获得其同意，方可配置。商家无需对接核销接口
|
||
|
||
|
||
|
||
关单：商家在指定的发码时间内，未进行发码回调。快手先调用商家的查询接口，如果查询到券码，报警人工处理。如果查询不到券码，才会调用销毁接口通知商家进行关单。
|
||
|
||
i、查询接口：超过24h（不同业务，超时时间不同）商家还未发码回调，快手定时任务会触发查询发码结果的操作，商家只能返回2种错误码「4012002-订单不存在」「 4012005-卡券不存在」，详见错误码规范
|
||
|
||
ii、发起销毁接口：当快手「查询接口」识别到商家返回的是上面2种指定的「关单错误码」，快手侧会调用「发起销毁接口」通知商家关单。商家必须要同意销毁「result=1」，快手才会关单并退款
|
||
|
||
|
||
|
||
常用对接场景
|
||
商家发商家核：只能商家发码且商家主动核销，商家需要对接「发码」和「核销」接口，对应下文的方案A 。
|
||
|
||
只发不核：发码后自动核销，无需用户主动去「商家系统」或者「快手系统」核销。只发不核模式容易产生大量客诉，需要小二谨慎评估才可以使用该功能。包括：商家发码自动核销、码库发码自动核销、快手平台发码自动核销，统称为「只发不核」
|
||
|
||
|
||
|
||
快手已支持的链路
|
||
发码方式 \ 核销方式 商家核销 快手核销（非自动） 自动核销【只发不核】（需加白才能开通）
|
||
商家发码 支持 不支持 支持
|
||
码库发码 支持 支持 支持
|
||
快手平台发码 不支持 支持 支持
|
||
|
||
|
||
订单和卡券状态
|
||
动作 订单状态 卡券状态
|
||
用户支付成功 已支付/待发货（30） 无
|
||
商家发码成功 已发货（40） 未使用
|
||
商家核销成功 已签收（50） 已使用
|
||
核销成功 + N天，用户无异议推动订单完成（结算货款） 交易完成（70） 已使用
|
||
商家超时未发码（默认24h内需发货） 交易失败（80） 无
|
||
卡券到期未核销（过期自动退场景） 交易失败（80） 已销毁
|
||
用户主动申请退款（支持退款场景） 交易失败（80） 已销毁
|
||
|
||
|
||
2.接入评估
|
||
2.1 目标用户
|
||
面向拥有自研能力可以发码的商家，可以和平台进行对接并将数据同步，双方共同管理券码的生命周期
|
||
|
||
2.2 接入评估
|
||
评估点 评估等级 评估内容 默认 备注信息
|
||
售卖类目 高 放在哪个类目下？有哪些资质 运营决策 商家和快手小二沟通清楚售卖类目
|
||
售后规则 高
|
||
随时退过期退：未使用状态下，支持用户主动申请。卡券未使用状态下，过期会自动退款
|
||
|
||
过期自动退：不支持用户主动申请退款。卡券未使用状态下，过期会自动退款
|
||
|
||
不可退：卡券不关心是否使用，都不支持退款
|
||
|
||
已商家实际业务为准，不可以随意选择
|
||
商品发品示例如下，不支持其他售后规则，比如：不支持「7天无理由退款」。
|
||
|
||
|
||
|
||
发码方式 高
|
||
【商家发码、码库发码、快手平台发码】
|
||
|
||
商家发码：商家通过对接接口进行发码
|
||
|
||
码库发码：商家在快手小店先导入券码，发品的时候绑定码库。如果用户购买了该商品，那么快手会从该商品绑定的码库里面选择一个「可用」券码发给用户
|
||
|
||
快手平台发码：商家无需做任何操作，快手会随机生成券码然后发给用户
|
||
|
||
已商家实际业务为准，不可以随意选择
|
||
建议联系运营小二，做正确评估。商品发品示例：
|
||
|
||
|
||
|
||
核销方式 高
|
||
商家核销、快手核销、自动核销（只发不核）
|
||
|
||
商家核销：用户在快手站外核销，然后商家必须通过对接接口把核销状态同步给快手
|
||
|
||
快手核销：商家可以在快手小店-商品-券码工具箱，操作核销
|
||
|
||
自动核销（只发不核）：特殊业务场景，卡券发了之后不能退还，需发码即核销。容易产生客诉，运营小二会严格审核
|
||
|
||
商家核销
|
||
建议联系产品、运营同学做完整接入的评估
|
||
|
||
|
||
|
||
技术对接方案 高 参考2.4节，有5种方案可选 默认方案A（商家发码、商家核销）
|
||
核销方式在哪 中 扫码核销、网页核销、电话核销等，说清楚 扫码核销 商家描述清楚用户卡券核销全链路
|
||
是否需要支持实体卡 低 实体卡、虚拟卡 虚拟卡，目前已不支持实体卡 仅大闸蟹业务支持实体卡
|
||
是否会冻结资金 低 是、否 否
|
||
一单一份发一张码还是多张码？ 低 一单一码、一单多码 一单一码
|
||
购买时一单一件，发「一张卡券」
|
||
|
||
购买时一单多件，发「多张卡券」
|
||
|
||
快手不支持次卡（一张卡券只能核销一次）
|
||
|
||
结算方式 低 结算时间、结算周期、起结金额等
|
||
1. 首张核销+N天结算
|
||
2. 全部核销+N天结算
|
||
3. 卡券核销+N天按卡券独立结算给门店(跨门店结算) 全部核销后+7天 不支持商家定制
|
||
退款方式 低 部分退、整单退 整单退
|
||
发码账号类型 低 用户填写的账号类型，比如：手机号 手机号 目前只支持手机号
|
||
卡号形式 低 卡券号、卡密，或者两者都有 仅卡券号
|
||
- 卡密（卡号 + 卡密）只支持在「商家发码」方式下
|
||
|
||
- 卡号（仅卡号）3种方式都支持
|
||
|
||
是否需要展示二维码 低 二维码用卡券号还是卡密等 卡券号二维码 - 只发不核默认不展示二维码
|
||
是否需要支持撤销核销（冲正） 低 是、否，一般撤销核销配合预约核销功能使用 否
|
||
是否有独立品牌和资质 低 自有品牌，代理品牌，无品牌等 自有品牌
|
||
基于以上评估，选择哪个对接方案 方案A、方案B、方案C、方案D、方案E 方案A
|
||
|
||
2.3 评估模板示例
|
||
售卖类目：游戏充值类目
|
||
发码方式：商家发码
|
||
核销方式：自动核销（只发不核）
|
||
核销方式在哪：游戏内部充值入口
|
||
支持实体卡：否
|
||
冻结资金：否
|
||
一单一码：一单一码
|
||
退款方式：不支持七天无理由退款、产品质量问题整单退
|
||
是否需要展示二维码：不需要
|
||
卡号形式：仅卡号
|
||
是否过期退：不支持
|
||
是否有独立品牌和资质：是，有独立品牌及资质
|
||
选择对接方案：方案E
|
||
|
||
|
||
|
||
2.4 方案对比
|
||
接口
|
||
方案A (推荐方案)
|
||
|
||
(商家发码，商家核销)
|
||
|
||
方案B
|
||
|
||
(商家发码，快手退款)
|
||
|
||
方案C
|
||
|
||
(快手码库发码，商家核销)
|
||
|
||
方案D (推荐方案)
|
||
|
||
(快手平台全托管)
|
||
|
||
方案E（只发不核）
|
||
|
||
(需要和运营沟通，只支持代金卡密类目)
|
||
|
||
优点：方案最成熟，功能最完善，接入后券码由isv生成，可以自己定制逻辑，券码生命周期保持跟快手平台同步，并且可以自动化处理退款和券码。
|
||
|
||
缺点：接口数量相对较多
|
||
|
||
接口数量：8-13个
|
||
|
||
优点：在接入方案A的基础之上做减法，只保留基础的发码功能
|
||
|
||
缺点：退款需要在卖家后台处理，主播带货场景需要大量客服小二处理退款，容易造成退款不及时
|
||
|
||
接口数量：6个
|
||
|
||
优点：接入速度最快，仅需接入2个接口，完全由快手平台负责券码的生命周期
|
||
|
||
缺点：不支持卡密
|
||
|
||
接口数量：2个
|
||
|
||
优点：快手平台发码/码库发码，无需开发，运营配置即可使用
|
||
|
||
缺点：无法定制化，完全依赖快手平台已有能力，不支持卡密
|
||
|
||
接口数量：0个
|
||
|
||
优点：只需要接入发码、查询、销毁接口
|
||
|
||
缺点：接入限制多，要和运营沟通确认
|
||
|
||
接口数量：3
|
||
|
||
是否需要开发
|
||
|
||
|
||
|
||
电子凭证通知发码接口
|
||
|
||
integration.virtual.eticket.send
|
||
|
||
是 是 否 否 是
|
||
电子凭证发码回调
|
||
integration.callback.virtual.eticket.send
|
||
是 是 否 否 是
|
||
订单新增消息
|
||
|
||
kwaishop_order_addOrder
|
||
|
||
或
|
||
|
||
获取订单列表v2
|
||
|
||
open.order.cursor.list
|
||
|
||
可选 可选 否 否 可选
|
||
新增退款单消息 kwaishop_refund_addRefund
|
||
|
||
或
|
||
|
||
售后单列表(游标方式) open.seller.order.refund.pcursor.list
|
||
|
||
是 否 否 否 否
|
||
商家同意/不同意退款接口
|
||
|
||
open.seller.order.refund.approve
|
||
|
||
open.seller.order.refund.disagree.refund
|
||
|
||
是 否 否 否 否
|
||
商家超时未发码，快手发起关单接口
|
||
|
||
或
|
||
|
||
卡券过期，快手发起销毁接口
|
||
|
||
integration.virtual.eticket.destroy
|
||
|
||
是 是
|
||
否
|
||
|
||
否
|
||
|
||
是
|
||
电子凭证销毁回调接口
|
||
|
||
integration.callback.virtual.eticket.destroy
|
||
|
||
是 是 否 否 否
|
||
电子凭证查询接口
|
||
|
||
integration.virtual.eticket.query
|
||
|
||
是 是 否 否 是
|
||
电子凭证冲正回调接口
|
||
|
||
integration.callback.virtual.eticket.reverse
|
||
|
||
可选 可选 可选 否 否
|
||
电子凭证核销回调接口
|
||
|
||
integration.callback.virtual.eticket.consume
|
||
|
||
是 是 是 否 否
|
||
电子凭证检查电子凭证是否有效
|
||
|
||
open.virtual.eticket.checkavailable
|
||
|
||
可选 可选 是 否 否
|
||
通过图商poi获取快手poi详情
|
||
|
||
open.shop.poi.getPoiDetailByOuterPoi
|
||
|
||
可选 可选 可选 可选 可选
|
||
商品新增
|
||
|
||
open.item.new
|
||
|
||
可选 可选 可选 可选 可选
|
||
商品上下架管理
|
||
|
||
open.item.shelf.status.update
|
||
|
||
可选 可选 可选 可选 可选
|
||
商品库存扣减
|
||
|
||
integration.item.stock.deduct
|
||
|
||
可选 可选 可选 可选 可选
|