AdYen 是处于荷兰的支付公司, 具备有网上支付牌照和超低的手续费率等大量优点
对于国内出海来说, 只需要看超低手续费率就可以了(PayPal这种高额手续费不推荐), 但是需要注意以下问题
信用卡支付体系: 海外性用卡拒付周期很长, 一旦申诉拒付失败会有相应罚金
海外收款转国内: 无法直接人民币结算到中国大陆对公账户, 必须走 外币→境外账户→结汇回国
黑五类等审核严格: 仿牌/黑五类/虚拟商品之类申请手续麻烦, 并且有很大封号风险
可以经由香港公司以服务费用转到国内进出口公司(需账务审计), 或者跨境PSP中转(万里汇)缴纳中转费用
这里主要将以技术方面出发来做海外第三方系统支付对接, 所以商户账号申请这部分可能没这么详细
开发文档: https://docs.adyen.com/get-started-with-adyen
初始化
首先就是向 AdYen 提交商户相关信息, 如果是公司/企业角色最好找专家处理专门对接事项
高周转金额最好找 AdYen 的商户经理做对接, 可以更快响应支付当中的问题(须英语交流)
AdYen 目前支持以下类别主体申请成为 ...
在多年工作之中对于后台管理的权限开发比较常见的是采用 RBAC 模型, 主要提供以下便利
有效分配权限
保护敏感数据
用户分组管理
比如常见的工会组织: 创建 XX工会 分组角色并在后台创建批次账号绑定该角色, 最后对该角色分配允许访问的入口和功能
毕竟这个后台角色已经经受时间的考验, 一般不会出现比较大的问题, 但是在日新月异的需求之中也开始出现问题
角色混乱: 如果需要制定角色只能看数据A/{不}允许编辑数据B/{不}允许导出数据, 就需要针对创建多个角色分配账户
权限混乱: 传统 RBAC 只能处理允许访问指定菜单/功能, 没办法针对可视数据(工会成员只允许查看自己, 会长看所有成员数据)
影响广泛: 涉及到某个角色组需要变动功能, 为了保证不影响其他相关账号, 需要手动创建分组在规划一遍权限并管理账号
内部业务固定并且用户比较少量的时候就没问题, 但是用户量级上来之后就会出现相关功能实现及其复杂且不可控
这里说下最典型的场景, 以游戏发行说明大概流程:
游戏发行最简单角色有 最高管理员/运营管理员(游戏研发)/渠道管理员(推广工会)
运营管理员相对比 ...
在多次项目的大量工程实践之后, 目前采用一下标准响应模式:
只有 GET/POST 方式做响应, 剔除掉 PUT/DELETE 方式
采用自定义的 *-X-Authorization 做 Header 认证参数而不用默认 Authorization
签名采用从参数列表 KEY 正序附加密钥生成签名 MD5
支持 i18n 多语言必须要 Header 追加 *-X-Language 标识语言从参数, 默认 en 英语
请求的内容类型为 application/x-www-form-urlencoded 传递
自定义的 *-X-Version Header 版本转发, 版本更新之后接口参数变化需要该参数决定转发新老接口
默认的响应格式 BODY 结构如下:
lines12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152// HTTP:200, 成功直接返回需要数据结构// 默认 200 代表成功直接返回数据结构体即可{ "use ...
对于国内规范化出海来说, 最推荐还是 Google 打通整套产业链处理, 主要基于以下优点
在香港设置有办事单位, 既保持与国内的连接, 又满足国际化合规要求
大量周边技术栈的成熟(Google Ads/Google Play)
广泛的用户人群, 基本上海外安卓手机都集成对应的谷歌套件
这里将从技术方面来说明和处理，首先必须要有一个 Google 开发者账号起步。
如果要打通 Google 整体链路可能要接触到以下系统:
系统
配置后台
功能
账户要求
OAuth
Google Cloud Console
用户 Google 账号登录授权
个人/企业均可
GooglePlay
Google Play Console
应用内购买 (IAP)，仅限虚拟商品
个人/企业均可
GooglePay
Google Pay 商家中心
网页/应用外支付，收实物商品款
仅企业账户
后续将围绕 GooglePlay IAP 方式来讲解怎么接入 Google 系统完成付费转化
授权机制
应用出海接入 Google 账号体系验证即可, 在 https://console.clo ...
随着 UUID 规范的日渐成熟, 目前已经可以在应用在大量日志库上面作为 主键(PrimaryKey) 使用
之所以考虑到不采用 自增ID(AUTO_INCREMENT) 就是为了方便分布式系统/多库数据合并等场景,
但因为早期规范存在缺陷现在还有一下问题要处理:
早期 UUID(v1/v4) 版本是随机乱序生成, 配合 InnoDB 主键是聚簇索引会导致频繁页分裂和索引碎片
采用字符串存储(CHAR(36)) 空间浪费巨大, 空间多占 2~3 倍会导致索引体积暴涨
UUIDv1 依赖 MAC + 时间, 可能会导致分布式多库合并出现冲突
只有在 UUIDv7 之后才修复以上问题, 目前 MySQL和MariaDB 之类方案可能因为版本导致没办法采用有序的 UUIDv7
目前不推荐直接采用 MySQL/MariaDB 内置的 UUID 类型, 需要为了考虑到兼容性采用 BINARY(16) 用二进制保存节约空间.
那么设计的表结构可能如下处理:
1234567891011121314151617181920# 登录日志# MySQL 版本之后才有 UUID_TO_B ...
这里需要说明, 国内企业出海最好具备以下条件
可以申办下发香港银行卡: 资金都是直接入户到香港银行户头
有时间往返香港处理银行事务: 国内资金审查很严格, 资金异常会冻结账户等待企业代表申诉
可以在香港设立企业证明: 这部分并不是硬性, 不过可以的话一般都是找海外做法人企业代表
能够英语处理海外业务: 海外大部分都是采用信用卡体系, 很多时候需要以英语做工单提交退款事务和账户异常问题等
注: 这部分不含 ODI 备案, 如果要走 ODI 流程对小微企业非常麻烦, 大部分都是采用灰色 ‘个体户’
如果以上条件都没有任一无法满足则后续不需要关注, 可以说上面都是比较硬性的条件
首先需要注册香港本地公司来财务做帐为银行提供开户方式, 主要处理业务为 “跨境电商零售” 方便香港银行开户
注: 小微企业要谨慎处理大额资金流入, 避免被识别为非法洗钱从而冻结资金(冻结之后须本人赴港申诉)
最后初步处理完成之后会获得以下内容
香港企业证书
香港银行账户
企业邮件地址
这些都是国内企业做海外跨境的基础, 必须确保这部分已经申办下来
邓白氏编码
目前申请的香港公司仅仅是作为香 ...
对接过发行系统的开发会频繁看到 数据归因 这个名词, 简单来说就是投放数据需要溯源分析从而知道获客来源多
以现实例子在抖音推广来说:
(广告曝光)需要投入资金购买抖音广告位
(广告展示)需要分析展示效果和频率(这部分可有可无, 有的主要只计算点击率)
(广告点击)用户看到广告之后点击推广触发下载跳转落地页等行为, 这种就是获得点击量
(安装激活)用户下载到设备安装完成, 首次启动代表整体链路激活, 这种就是设备激活量
(用户转化)用户启动之后注册/登录账号的时候, 就代表正式转化为我们的用户, 这就是用户转化量
(付费用户)如果用户正式在应用触发付费行为, 那么这就代表该用户为核心付费用户, 也就是购买广告位获得的正向收益
数据归因 所要做的就是跟踪整体链条保证让投入产出比持续健康, 保证收益 就是归因的最终目的
广告位这部分是真金白银投入的, 如果投放的渠道收益差(投入资金但收益低)就要赶快停止或者切换渠道
数据核心指标
CAC = 获取客户的成本 = Customer Acquisition Cost
计算公式: CAC = 总投放费用 ÷ 有效新增 ...
常规开发游戏初期都不需要网络处理, 部分测试开发的时候需要用授权体系来解锁功能, 针对这部分就需要前置网络授权模块
其实这种授权方式很容易被跳过, 只是作为测试的时候上报游玩数据统计而已
这种授权机制好处就是能够构建自己的游戏社区, 能够营造类似于 Steam/WeGame 这类社区来单个账号体系多个游戏共享
而且 GitHub/Bitbucket 等平台都提供规范的 OAuth 体系用于构建应用授权体系, 方便在平台发布并且授权登陆测试游玩游戏
目前 Godot 并没有类似 WebView 之类的内部浏览器渲染功能, 所以没办法直接在游戏弹出浏览器渲染, 需要比较取巧的方法
Godot 是支持 GDNative 集成 ChromiumEmbedded 内置浏览器功能; 但还是那句话, 官方直接集成否则稳定性都不好说
OAuth 授权机制的流程如下, 这里主要对象有三个, 就是 客户端/我们自己服务端/第三方平台 :
在平台创建应用, 主流基本上需要配置并且设置好以下地址:
client_id: 对外公开的应用ID
client_secret: 自己服务器使用的验证标识, ...
对于一些要求比较高的数据采集流程, 会采用模拟正常浏览器处理方式来避免被风控, 这种技术就是 浏览器模拟/浏览器渲染型爬虫
核心是用真实浏览器内核执行 JS、渲染页面, 完全模拟真人访问行为来绕过风控
比较老牌的就是 Python 的 Selenium 处理, 但如果采用 PHP 做底层采集框架(接口服务)就感觉没必要引入额外的开发语言
而 PHP 之中第三方也是具有这方面组件库, 也就是这篇文章的主角 php-webdriver
利用 php-webdriver 可以实现模拟玩家浏览器行为来采集数据, 并且一步到位来暴露自身 API 服务接口功能
注: 这里采用 PHP 的 Composer 来做包管理功能
环境安装
首先需要知道模拟玩家浏览器行为是需要用到底层浏览器驱动的, 目前底层浏览器驱动有以下方案:
ChromeDriver: https://sites.google.com/chromium.org/driver
EdgeDriver: https://developer.microsoft.com/en-us/microsoft-edge/tools/we ...
简单处理 显示设置(Display Settings) 之后就是另外 音频设置(Audio Settings) 相关
音频部分就相对来说比较简单, 游戏内部对音乐管理需求不高的话, 直接采用如下配置:
主音量(Master Volume): 全局整体游戏总音量
背景音乐(BGM Volume): 游戏当中涉及到场景/剧情等背景音乐
游戏音效(SFX Volume): 游戏当中释放技能/触发交互的弹出音乐
如果是偏剧情向(GalGame)之类, 那么需要追加人物音量(Voice Volume), 甚至要单独另开配置页面来为每个角色添加音量
音量部分都是采用 0.0~1.0 的浮点数代表百分比处理(0代表静音), 所以不会专门单独定义枚举处理, 处理也就相对显示设置简单
而 Godot 内部会用到的 API 如下所示
API 全路径
方法/属性用途
参数/返回值
核心说明
AudioServer.GetBusIndex(string busName)
通过总线名获取音频总线索引
参数：string（音频总线名，如Master/BGM/SFX）返回值：int ...
