惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Engineering at Meta
Engineering at Meta
月光博客
月光博客
WordPress大学
WordPress大学
C
Cisco Blogs
Recent Commits to openclaw:main
Recent Commits to openclaw:main
博客园 - 【当耐特】
大猫的无限游戏
大猫的无限游戏
The GitHub Blog
The GitHub Blog
Google DeepMind News
Google DeepMind News
The Cloudflare Blog
有赞技术团队
有赞技术团队
Microsoft Azure Blog
Microsoft Azure Blog
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
小众软件
小众软件
H
Heimdal Security Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
W
WeLiveSecurity
量子位
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
F
Fortinet All Blogs
T
Threat Research - Cisco Blogs
Attack and Defense Labs
Attack and Defense Labs
P
Privacy & Cybersecurity Law Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
NISL@THU
NISL@THU
Forbes - Security
Forbes - Security
L
Lohrmann on Cybersecurity
C
CERT Recently Published Vulnerability Notes
L
LINUX DO - 热门话题
Google Online Security Blog
Google Online Security Blog
S
Security Affairs
V2EX - 技术
V2EX - 技术
TaoSecurity Blog
TaoSecurity Blog
N
News and Events Feed by Topic
N
News | PayPal Newsroom
S
Security @ Cisco Blogs
宝玉的分享
宝玉的分享
Project Zero
Project Zero
The Hacker News
The Hacker News
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
PCI Perspectives
PCI Perspectives
G
GRAHAM CLULEY
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Y
Y Combinator Blog
N
Netflix TechBlog - Medium
S
Schneier on Security
Application and Cybersecurity Blog
Application and Cybersecurity Blog
www.infosecurity-magazine.com
www.infosecurity-magazine.com
博客园 - 聂微东

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
“收银台”设计方法论
陈天宇宙 · 2023-05-05 · via 人人都是产品经理

收银台,字面意思是“收+银+台”,顾名思义就是收取银子的台子。本文作者对收银台的产品架构、业务架构、流程,以及常见的支付方式、支付场景等方面进行了分析,全面解析如何完整地设计一款收银台产品,一起来看一下吧。

收银台,从字面意思“收银台=收+银+台”,顾名思义就是收取银子的台子。本文主要是归纳抽象出收银台的通用设计方法,其中包含了收银台的产品架构、业务架构、流程,以及常见的支付方式分析、支付场景分析等,全面解析如何完整地去设计一款收银台产品。

01 初识收银台

1. 传统收银台

在古代你去饭馆吃饭喝酒吃肉,酒足饭饱后到柜台掏出50两的大元宝拍在了“收银台”上:老板结账,不用找了;最原始的收银台就是那个柜台,柜台的特点就是结账的场所,你把钱放上去,有专门的人员核实账款与商品,无误以后,交易就完成了。结账场所最核心应该具备的内容应该包括以下点:

  • 商品信息:消费了什么
  • 价格信息:应该多少钱
  • 支付方式:如何结算,现款还是赊账
  • 核实人员:核对货款的一致
  • 货款交割:付款结账,宣布完结

这些信息构成收银台应该具备的基本元素以及职能,而且这些职能是在实际执行过程中逐渐形成并固定下来。对于电子支付收银台的设计具有参考意义。

2. 线下收银台

近代在电子支付出现之前,我们去超市购买商品,挑好货品后拿到结账处进行清点,工作人员告诉你“一共10斤粮票” ,你掏出纸质的票子完成了付款,商品就是你的了;此时的工作人员叫收银员,他面前的台子就是收银台;这里收银台就是商品和现金的交换场所。形式跟传统收银台没有本质差别,但在技术和管理能力上有了很大的提升——货币形式变了,有了专业的收银人员,交易场所更加规模化,商品管理也更加标准化。

3. 线上收银台

电子支付出现以后,出现了新的货币形式“账户货币”支付方式产生了电子支付方式,从而产生了线上的支付场所——电子支付收银台;一个可以在线上通过各种电子支付手段完成账户货币转移的支付收银台形式。

  • PC收银台:在电脑上完成支付的收银台
  • H5收银台:手机内的H5网页上完成支付的收银台
  • API收银台:以接口形式提供的收银台服务
  • SDK收银台:提供SDK开发工具包的收银台服务
  • 硬件收银台:pos机,mpos机等硬件设备,支付卡牌等

4. 移动端收银台

移动端收银台:填写订单、选择支付方式、支付流程、支付结果。

“收银台”设计方法论

5. PC端收银台

如图中的结算页,主要“看元素、定布局、思缘由”:

  • 结算进度条
  • 地址信息
  • 支付方式选择:货到付款、在线支付、对公转账
  • 配送方式
  • 商品信息
  • 发票信息
  • 计费信息
  • 提交按钮

“收银台”设计方法论

02 收银台的产品架构

我们重点关注收银台架构的三个方面:

  1. 公司所支持的收银台种类以未来拓展倾向
  2. 支付方式的枚举及根据业务发展预判拓展倾向
  3. 收银台服务端的能力建设规划和选择

“收银台”设计方法论

03 收银台的业务架构

收银台,是支付的起点,所以无论是何种企业或者支付组织,收银台都是支付架构的最前位置,支付从“收银台”开始。

直面终端用户“消费者,B端商户,内部用户”。

“收银台”设计方法论

消费者下单需要的用户收银台:

“收银台”设计方法论

商家支付货款或充值的商家收银台:

“收银台”设计方法论

04 收银台的支付流程

收银台是支付的起点,是交易环节和支付环节的衔接点,用户在交易环节完成了商品的选购以及订单的填写、合同签约以后,下一步就要进入支付环节完成支付,而支付的起点就是收银台。用户在收银台选择合适的支付方式进行支付。

“收银台”设计方法论

05 从功能上理解收银台

收银台不只是用户看到的收银台页面那么简单,其除了在不同场所页面元素以及交互方式不同以外,与后台的数据交互以及子系统的划分也会存在差别。

例如普通的商户和三方支付机构对收银台的设计思路会存在差别,这些差别是由于:

  1. 其直接服务的用户群体不同
  2. 收银台的业务定位不同

这些差别可以从不同角度去分析,例如分析不同组织之间的收银台差别、同一个组织的收银台的前后端的差别。

从组织维度对比:

  • 商户侧的收银台分:前台/后台,前台面向用户,后台面向渠道
  • 支付公司的收银台:前台对应商户或者直接面对用户,后台面向渠道

从前后台对比:

  • 收银台前台:面向用户的可视化收银台页面主要是提供给用户完成支付方式选择和支付请求的发起
  • 收银台后台:主要是调用后端获取支付参数和支付通道,请求通道发起支付请求

06 收银台的关键指标

问自己一个问题:我的收银台好吗?

产品的一切目的都是以价值为导向,无论是用户价值还是企业价值,否则就失去的产品的方向和意义。

对收银台来说,我们如何定义其好坏,考量其“好坏”,所以需要建立几个核心指标用以考核收银台。

  • 用户支付体验-NPS:好不好用,用户用得爽不爽,界面舒服,操作流畅,支付方式丰富
  • 支付时效:最短的时间完成支付,简单的加载5s内可以反馈支付结果
  • 支付成功率:支付成功率越高意味着用户体验越好,同时也是支付转化率中最核心的一部分
  • 支付转化率:平台交易在“支付环节”的转化率高低,是整个交易转化率的一部分

“收银台”设计方法论

07 设计收银台前的准备

在设计收银台之前要先做好下面几个方面的准备,才能确保设计的产品相对完整,能够达到预期的用户体验,完成相关的支付指标。

1)了解公司业务模型

做任何产品的前提就是先了解业务是怎么样的;例如售卖的是什么商品,业务模式是电商、游戏、课程售卖还是会员充值等等,其实就是搞清楚卖什么,怎么卖的问题;我们假设是电商平台,卖的是实物商品。

2)选择支付方式

想好要为用户提供什么支付方式,比如微信支付,支付宝支付,银行卡快捷支付,账户余额支付?一般场景中,选择微信支付宝就够了,但也难免有用户想直接绑定信用卡去支付,虽然通过微信支付宝也可以使用信用卡支付;这个要看平台的选择,如果有能力实现就尽可能给用户更多的选择,满足更多的用户需求,覆盖更多的支付场景。

3)签约支付通道

完成了(2)的分析,基本就可以确定要签约什么支付产品,也就知道该如何去设计收银台了。假设签约了微信支付,易宝的快捷支付,自建钱包;就可以拿到微信的文档,易宝支付的文档,钱包账户自己来设计;拿到文档后就知道了支付需要的参数,就能确定我们请求通道时需要哪些参数,哪些参数是用户提供的,哪些参数需要后台整理封装,当前系统是不是可以提供需要的参数,还需要做哪些改造。

4)确定收银台的支撑系统

分析清楚要完成支付至少需要哪些支撑系统,收银台还需要内线的订单账单、账务等,外线就需要收银台后台、路由、风控(非必须)、支付处理、渠道管理等。

08 收银台前台设计

收银台包含前端和后端,前端是用户可以看到的收银台页面,在订单填写页提交订单以后到达。对于前端页面比较容易调研,因为直面用户,所以到任何一个平台操作一下下单和支付就可以到达相应的收银台,看到收银台展示的内容元素以及交互。

1)收银台的关键信息

收银台页面内容主要包含以下几个元素:

  • 商品信息(非必需展示) :用户买的什么
  • 收款方 (非必须展示) :钱付给谁
  • 支付有效时间:在规定时间内支付
  • 支付方式列表:有什么支付方式可以选择
  • 支付金额 :付多少钱
  • 支付操作:确认支付的按钮

2)收银台的关键流程

  1. 提交订单到达收银台页面
  2. 去支付进入支付流程,当前应用或者跳转到支付应用
  3. 支付成功或失败的支付结果落地页
  4. 支付落地页的后续流程,返回什么地方
  5. 支付结束

3)收银台的拓展

收银台随着业务的变化在不断发生变化,在更多的端上建设收银台,收银台支持更多的支付方式,相应也会出现支付方式推荐、支付补贴露出、活动优惠推送等更多内容。

同样收银台类型的拓展:逐渐发展出PC收银台、H5收银台、app收银台等更多的收银台形态。

支付方式的拓展:除了微信支付、绑卡支付、余额支付等方式以外,逐渐发展出数字人民币支付,线下支付等支持更多支付场景的支付方式。

4)银行卡快捷支付

银行卡快捷支付可以选择已经绑定的卡,也可以添加新卡;新卡的绑定一般按照绑卡鉴权的要求既可以设计出需要的要素,借记卡和贷记卡的要素不一样;个人户和对公户也不一样;随着电子支付的发展,方式也会变化,跟着接入方的要求走即可。

5)收银台的余额支付

既然是自己包装或者接入的钱包余额,算是一个新的支付方式,一个新的支付方式需要关注以下几个要素:

  • 支付logo:就是展示给用户的icon图标
  • 支付方式名称:起个名字,比如抖音支付,余额支付,钱包支付等
  • 支付发起流程:选择这个支付方式以后,提交支付后的业务流程如何

09 常见支付场景及关系

收银台的设计离不开企业业务特点,而企业的业务特点又离不开交易场景,我们看下常见的支付场景有哪些,这些场景对收银台的诉求。

“收银台”设计方法论

10 支付方式选择与分析

对于常见的支付方式选择,可以结合上面所述的支付场景,然后通过以下几个维度进行分析:

“收银台”设计方法论

对于主流支付方式,目前国内成熟市场下,主要还是微信和支付宝以及银行卡这三种支付方式,大部分可以满足消费需求,但也有基于其他目的比如降低费率、覆盖低收入人群等等,可以选择外漏支付宝花呗等消费贷支付产品。

另外还要考虑的问题就是对用户的覆盖、支付体验、支付限额、用户类型等维度,以下是主要几个支付方式的维度分析。

“收银台”设计方法论

1)余额支付方式

余额支付的最大特点就是“组织内闭环”,可以不依赖外界渠道,直接在内部完成账务处理。

好处就是可以有更好的支付体验和额度控制,劣势就是依赖前置的账户充值,依然依赖外界支付。

最典型的余额支付方式就是“微信零钱”。

余额支付的核心是:为支付系统模拟出一条“余额支付”通道。

“收银台”设计方法论

2)代扣支付方式

常见的代扣场景有2个,一个是自动周期性扣费,如自动会员续费;另一个是先服务后支付,如乘车码,我们以微信代扣支付为例。

“收银台”设计方法论

从协议中看代扣,有几个关键描述点:从哪里扣钱、代扣前的通知、订阅周期。

我们串起来看一下腾讯视频会员在苹果内签约的自动续费的扣款路径,以及扣款账单。

“收银台”设计方法论

先服务后扣款的常见场景是打车以及乘坐地铁的乘车码,如我用滴滴打车,结束后微信自动支付成功,看下图微信内的支付通知和账单信息。

“收银台”设计方法论

微信代扣产品叫“微信支付扣款服务(原委托代扣)”,是为微信支付为商户和用户提供的,可以在交易场景之外完成支付的能力,主要服务于三个场景:

  1. 免密支付:可以实现对存在签约协议的用户进行小额立即扣款的功能,扣费时间无延迟,无扣费前通知,商户只需调用【申请扣款】接口发起扣款即可。
  2. 自动续费:扣费时间有延迟,需有扣费前通知,具体参看【 周期扣费】说明文档,目前支持通知后【24小时自动扣费】或【预扣费通知】两种模式,商户只能选择申请其中一种模式实现扣费,一般申请后为【24小时自动扣费】模式,如需使用另种模式,请联系对接您的运营同学协助申请修改模式。
  3. 授权扣款:可以实现对存在签约协议的用户进行大额立即扣款的功能,扣费时间无延迟,无扣费前通知,商户只需调用【申请扣款】接口发起扣款即可。

3)小额免密支付

小额免密支付是在零售小额场景下,一定金额以下的小额支付时,无需用户进行支付密码确认,商户直接发起扣款指令完成扣款的支付方式。

“收银台”设计方法论

4)消费分期支付方式

接入外部消费分期产品方式,以接入花呗为例,至于独立设计消费分期属于信贷范畴,体系庞大,后续会出单独的内容体系,这里站在大多数普通企业视角做分期支付场景。

花呗分期是蚂蚁集团推出的消费金融产品,用户在商家端网站或线下门店购物时使用花呗分期支付,订单全额实时支付到商家支付宝账户中,用户分期偿还花呗。

“收银台”设计方法论

11 支付方式的展示策略

收银台的个性化展示:我们可以从以下几个方面去分析,当然还有很多种其他原因,归根结底都是因为多样化业务诉求的产生。

1)支付方式多样化

随着平台的发展,为了迎合更多场景及用户,会签约更多的支付渠道,从微信支付宝,到银行卡支付、苹果支付,再到银联闪付、数字人民币支付、余额支付等等,多样化的支付方式就必然对收银台的展示策略提出了更高的要求。

2)业务的多样化

有了丰富的支付渠道之后,其实业务多样化同样也会影响支付方式的展示,比如有些渠道拒绝某些品类的支付请求,所以如果用户选择了这种品类下的商品,那收银台就不应该展示不接收该类商品交易的渠道支付方式。

3)商户需求的多样化

随着商户数量的增加,种类的增加,合作模式的增加,对支付渠道的要求,甚至是收银台的要求也会相应增加,比如有些ka大商户因为跟某些渠道有合作,可能就会要求仅支持某几类支付方式,这样就需要根据大商户的特殊要求设定支付方式。

4)平台诉求的多样化

平台本身也会有营销等各种诉求,AB实验的诉求等,也会对收银台的个性化提出要求,比如某些用户优先推荐微信支付,某些已经绑了银行卡的用户优先推荐银行卡支付等。

5)渠道合作的多样化

有些渠道可能会提供一些合作模式,比如你把我放在第一位我就给你降费率,或者更有甚者,你把竞品折叠,我再给你降一些费率,而这种合作模式又可能不是全量用户,比如你要将50%的交易采用这种收银台模式。

6)用户习惯的多样化

用户体量足够大时,你就不得不考虑更好的用户习惯和体验的诉求,比如有些用户每次购物都是用微信支付,那么下次支付你要是推荐了支付宝而折叠了微信,那必然会让用户多操作几次去找到自己想要的支付方式;而如果有些用户上次使用了银行卡支付,那么下次推荐上次用的卡可能是一个不错的选择。

7)渠道营销合作

有些银行渠道可能会提供一些支付补贴,这也会成为支付方式个性化的需求来源,但是这种营销又可能不是全量用户,所以这里又需要策略问题。

所以说,收银台个性化展示的目的有时为了更高的成功率,有时为了提高用户体验,为了给某一个支付渠道引流等不同的诉求,但最终实现的业务效果就是不同的人可能看到的收银台页面的支付方式的种类和顺序会有差别。

专栏作家

陈天宇宙,微信公众号:陈天宇宙,人人都是产品经理专栏作家。多平台支付领域专栏作者,十年资深产品;专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务!

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。