绕不开的 IAP 支付 —— 如何实现支付效率优化

消息来源:baojiabao.com 作者: 发布时间：2024-11-18

报价宝综合消息绕不开的 IAP 支付 —— 如何实现支付效率优化

本次 GameTube 邀请网易云音乐资深交互设计师于康康来分享他在优化 IAP 支付效率的经验和感受！

下面有请康康~

前言

近年来互联网行业整体流量见顶，但为了保证营收达到既定目标，就不得不在转化率和客单价上下功夫。作为网易云音乐营收业务线的交互设计师，通过近几年的设计实践积累了一些提升转化率和客单价的经验和方法，在此向大家分享，希望能给大家带来启发和借鉴。今天分享的是优化 IAP 支付效率的经验。

什么是 IAP 支付

IAP 的全称是"In-App Purchase"，它是苹果为 App 内购买虚拟商品或服务提供的一套交易系统，用户在 iOS 系统内购买虚拟商品（例如游戏道具、电子书、会员等）必须使用 IAP 支付，不允许使用支付宝、微信等第三方支付方式。

IAP 的内购项目分为 4 种类型：消耗型项目、非消耗型项目、自动续费订阅、非续费订阅。目前来看应用最广泛的是消耗型项目、自动续费订阅和非续费订阅。消耗型项目通常是用来可多次购买的项目，例如直播里的充值虚拟币、游戏里的装备道具等。自动续费订阅适用于对 App 中内容、服务或进阶功能持续访问的权限，用户购买后定期自动续费，直到用户手动取消，例如音乐、视频类 App 的连续包月（季、年）会员项目。非续费订阅适用于对 App 中服务或内容提供有时限性的访问权限，例如音乐、视频类 App 的月（季、年）卡会员项目。

虽然苹果的 IAP 支付存在分成比例高且支付成功率比国内支付软件（支付宝、微信等）低等诸多缺点，但我们在 iOS 端虚拟商品支付这块实在绕不开它。当然，网上有些老司机也会分享一些通过"舍小保大"、"偷梁换柱"等大招绕过 IAP 支付的经验。在此建议小伙伴们（尤其是体量大且竞争对手环视的产品）千万别耍小聪明，否则届时轻则审核不通过，重则收到 App 下架和开发者帐号被删的"大礼包"。既然绕不开，那我们就要沉下心来把它研究透，思考在现有的 IAP 支付规则限制下如何通过优化流程触点体验来提升支付转化率。

IAP 支付的特点

通过将 IAP 支付与支付宝、微信等支付方式对比可以发现，它们在分成、技术实现、退款策略等诸多方面存在差异点，在此仅展开说明影响支付效率的"预设价格"和"支付实现逻辑"。

预设价格

我们在创建 IAP 项目时只能选苹果预设的价格，这些预设价格在中国大陆地区是间断且固定的整数（文章写作时已有小道消息说后续苹果会增加一些带小数的 IAP 项目），例如 1 块钱、3 块钱、6 块钱、8 块钱、12 块钱、18 块钱、25 块钱...... 如果想设置一个类似 9.9 元这样价格的 IAP 项目是不被允许的。

这种价格策略不仅十分限制折扣、满减等实际支付金额随优惠策略变动的促销玩法，还使得用户用同一个 App 同一个帐号在 Android 和 iPhone 端可能看到两套价格策略，造成不解和困惑。另外 IAP 项目的价格在商品发布以后还可以在后台修改，但是大部分 App 的内购项目价格是从自己的服务端获取的，所以如果要修改价格需要两边一起处理，还是挺麻烦的。

支付实现逻辑

有些朋友要问了，我一个设计师搞懂支付实现逻辑有什么用？这不是开发同学应该做的吗？在此先讲个发生在朋友身上的小故事，我朋友她们公司的一个设计负责人不懂 IAP 支付逻辑，某次使用 IAP 支付时忘记了冗长的苹果支付密码又不想用人脸识别，就一拍脑袋产生了一个自以为巧妙的方案，即在他们的 App 内做个只需像微信那样输 6 位数字密码就能完成 IAP 支付的功能。就让我朋友去找开发沟通强推他的方案，最终被开发怒怼回来，搞了个笑话。因此策划和交互必须对苹果 IAP 支付的逻辑有一定了解，只有这样才能与开发一起设计出用户体验好、转化效率高的支付方案，而不是拍脑袋提想法被怒怼。

我们日常使用支付宝（微信）的支付交易验证工作是在服务器之间通讯完成的，而 IAP 支付是一种以用户设备作为信息流转中心的支付方式，支付信息以用户设备（如 iPhone）为中心在 App Store 和 Developer Server 之间传输和校验，最终完成支付履约。具体流程如下，用户在 iOS 设备上点击支付按键后，应用程序向 App Store 发送支付请求，App Store 处理支付流程并返送交易完成信息，应用程序调取交易收据数据并将其发送给 Developer Server，Developer Server 记录收据数据并建立查账索引，Developer Server 将收据数据发送给 App Store 确认交易是否有效，App Store 分析收据数据并判断后将结果发送给 Developer Server，Developer Server 接收后确认用户购买哪项产品和是否成功并将结果发送给用户设备的应用程序。

综上所述，IAP 支付方式的信息流转路径长、节点多，作为信息流转中心的移动设备所处的网络环境比较复杂，扣款成功后下发和上传票据还会受到网络异常、App 服务器和 Apple 服务器异常等因素的考验，这就导致 IAP 支付稳定性和流畅度较支付宝（微信）支付低很多。

IAP 支付优化策略

某同行曾经做了一个 AB 实验，在相同条件下悄悄切了 iPhone 端部分流量走支付宝（微信）这样的第三方支付，结果发现第三方支付的成功率大概是 IAP 的 2~3 倍，反映在总体营收上也是 IAP 的 2 倍多。由此可见，IAP 支付效率确实低，即使提升 IAP 支付转化率至第三方支付（支付宝、微信）的普通水平，对业务营收的贡献也是巨大的。

本次就探讨一下用户在 iOS 端点击"支付"按键以后的流程中如何提升转化率，点击按键前的提高购买动机、引爆触发点等不在本次讨论之内。按照上面所述的支付流程，我们可以梳理出设计侧可以干预的优化触点，即支付加载动效、充值页（消耗型项目）、支付失败、支付成功。下面我们将从这 4 个触点说明一下我们积累的提升转化率的经验。

1.支付加载动效

IAP 支付流程本身比较复杂、网络环境不佳、校验延迟等问题导致整个支付流程耗时长且流畅度低，如果我们在这个过程中什么也不做，仅靠 iOS 原生的"转菊花"loading 撑着，用户心理必然经历无聊（没事可干，想打发时间）--焦虑（怎么还不出结果，越等越烦躁）--放弃（还没成功，算了，不买了）。有购买意愿且已经点击"支付"按键的用户就这么白白流失，太可惜了。因此必须在支付加载动效上下功夫。目前加载动效有 2 种思路：一是用自己的品牌形象替换系统"转菊花"做成 loading 动效，二是将用户订单信息采用动效形式展示给用户。

下方是各大平台采用品牌形象替换系统 loading 的方案，这种方案相较于系统 loading 不仅趣味性更强、实现成本低，还能在等待过程中不断给用户强化品牌认知。我们网易云音乐目前线上也采用这种方案，在前些年上线时与系统 loading 对比实验的结果显示，该方案可以增加用户停留时间并对转化率有更好的正向促进作用。不过这种 loading 方式也有缺点，就是一味地展示单调重复的品牌形象动效，时间一长还是会引起用户的反感。

下方是采用订单信息逐条加载来替换系统 loading 的方案，逐条加载的信息吸引用户视觉动线追随查看，用户在查看过程中不仅可以再次核对订单信息，还可以在查看信息过程中忘记自己是在等待漫长的支付校验，如果看到有额外的赠品还可以增加用户的惊喜感和等待动力。这种方案的原理是让用户在等待中忙碌起来，是利用人们的"空闲厌恶"心理，即人们害怕无所事事，他们需要忙碌的理由，即使人们被迫忙碌，但也会因忙碌而感到满足快乐。

2.充值页

我们在 iOS 端购买消耗型项目时通常需要先进入"充值页"，充值完毕后才能用虚拟币来购买虚拟商品。我在这里采用的是"一步直达"和"优化充值页"的策略，核心原则就是降低用户认知和操作成本。这里给大家分享的是网易云音乐内数字专辑售卖过程中充值页的优化案例。

前些年我走查 iOS 端数字专辑支付流程时发现，下单过程中当数字专辑价格和我们申请的消耗型 IAP 项目价格一致时，仍然要跳转到"充值页"，并且需要用户点击 IAP 项目后才能完成数字专辑的购买。在这种场景下我们平台能否将"跳转到充值页"和"用户点击 IAP 充值金额"帮用户自动处理掉，减少用户支付的阻力呢？因此提出"一步直达"的方案，即用户点击"充值并支付"按键后如果所需支付价格等于 IAP 项目价格，后端自动帮用户完成充值并支付，前端不再展示"跳转到充值页"和"用户点击 IAP 充值金额"这两个步骤，在当前页面就能完成数专购买。开发同学也受此启发，增加了用户所需支付价格等于 IAP 项目价格整数倍时也可"一步直达"逻辑，将 100 元以内的价格覆盖率提升至 47%。上线后数据反响优异。

当 IAP 项目单价（或整数倍）覆盖不到虚拟商品价格的时候还是需要充值页，这就需要设计师分析充值页的不足进而提出优化方案，通过页面优化的方式提升 IAP 支付转化率。下图是对原有充值页（左图）的分析和优化上线后充值页面（右图）的说明，优化后的页面信息更加条理清晰、手指移动和点击成本更低，并且依据"默认效应"为用户选中接近所需充值金额且最便宜价格的选项，用户可以无需思考点击"立即支付"按键即可完成购买。默认选项的优势是将"选择充值金额"由在原有页面上的"选择题"变为在优化后页面上的"判断题"，降低用户思考成本。上线后数据反馈良好。当然该页面仍有进一步优化的空间，目前持续优化的方案正在测试中。

注：针对大额虚拟商品，尽量说服定价方将售价设置成 IAP 项目价格，因为苹果的预设价格策略是随着金额的增大两个相邻阶梯价格之间的差额越大。例如我们将一个虚拟商品的价格设置成 699 元，因为没有对应价格的 IAP 项目，所以用户只能最低充值 798 元才能购买。那么用户就会想"我买的东西是 699 元，为什么让我充 798 元，而且多余的 99 块钱只能留在这个平台里面，还取不出来，太坑了，算了，不买了"，最后一些大额客单价的用户就这么白白流失了。

3.支付失败

IAP 支付失败的原因有很多，例如与用户以往购买实体产品的经验不一致导致用户主动放弃支付、未绑定 App Store 的支付方式、网络不佳、苹果服务器挂掉等等，各个产品用户属性、产品性能不同需要具体分析。有些需要针对支付失败的用户投放调研问卷，例如某同行通过问卷调研发现他们的用户中竟然有 75% 是因为没有绑定 App Store 支付方式而导致支付失败；有些需要开发同学立项找原因提升技术性能，例如我们的开发同学通过将果验证小票接口的性能提升了 1 倍的方式，达到了缩短等待时间和降低支付失败风险的目标。

设计侧常用的是"失败挽留"和"重新下单"策略。"失败挽留"是在用户支付失败时出对应的挽留策略和帮助引导，分为站内和站外挽留两种方式。站内挽留是在用户支付失败的瞬间在 App 内直接调起挽留措施（弹窗、浮层、新支付页等）根据可能的失败原因展示不同内容，包括增加用户购买动机、提供支付教程、引导找客服协助购买等，目的是帮助用户完成支付操作。站外挽留是用户在购买失败后一定时间内仍没有完成购买，通过短信、智能客服电话等渠道引导用户购买，传达的内容也会有所区别，例如折扣价格、额外赠品等。

"重新下单"是由于苹果验证方式的原因，用户支付失败后会在一定时间内产生一笔支付确认中的订单。如果用户继续在这笔订单上支付的话，大概率会继续导致支付失败，因此虽然前端呈现给用户的是在原来的订单上继续支付，但其实后端是为用户重新下了一笔订单。

4.支付成功

既然用户已经付款成功了，还有什么可以提升转化率的触点呢？那当然是避免用户退款啦。引起用户退款的原因主要是履约延迟，即用户完成了会员权益或一个虚拟商品的支付后发现不能用，怒而找客服退款。造成履约延迟的原因主要是苹果为保障交易验证完成而提供的事务机制，如果某一个事务在当次 App 生命周期内未能正常结束，只能在下次 App 重启后，中断的事务才能恢复，这种情况下就会造成扣了款长时间不履约。

我们这里一般采用"履约延迟提示"和"未到账补发"两个策略。"履约延迟提示"是在用户支付成功后展示，告知用户已支付成功但权益可能稍后生效，它可以有效降低权益下发延迟时的用户客诉退款率。"未到账补发"是在一些极端情况下用户支付成功后权益没有下发的一个兜底策略，用户可以通过该功能自助完成未到账权益的获取。