在旅宿官方网站导入线上付款时，常会犹豫：「Stripe最适合吗？」「能处理现场付款的Square比较好吗？」「是否应使用预订系统附带的付款功能？」
先说结论，并非所有旅宿都最适合Stripe。
- 若希望可靠地与预订系统整合，先确认内置付款功能
- 若要建立自定义预订画面或弹性整合，Stripe是有力候选
- 若希望统一柜台面对面付款与线上付款，Square是有力候选
比起手续费的小幅差异，更重要的是付款后能确认预订，取消时能正确处理预订与退款两件事。
先整理三种付款
住宿费主要有以下三种收取方式。
- 线上预付款：在预订时或住宿前付款
- 现场付款：在入住或退房时付款
- 订金：预订时收取部分金额，之后收取余款
若官方网站、OTA与电话各使用不同付款方式，预订台账与入账记录可能不一致。各系统的角色可阅读预订引擎、渠道管理系统与PMS的差异。
比较3种选择
| 选择 | 优势 | 注意事项 | 适合的旅宿 |
|---|---|---|---|
| Stripe | Checkout、Payment Links、API等整合方式丰富 | 需确认与预订系统的连接及状态同步 | 希望通过自定义网站或支持的插件弹性构建 |
| Square | 较容易整合线上、付款账单与面对面付款装置 | 住宿预订的房量与预订状态需由其他系统管理 | 希望统一柜台付款与预付款 |
| 预订系统内置付款 | 可能较容易与预订确认、取消整合 | 使用公司、手续费及迁移方法依产品而异 | IT人员少，希望简化运营 |
「内置付款一定会自动整合」并非必然。请在示范环境测试预订、付款、取消到退款的完整流程。
Stripe：线上整合选择广泛
Stripe官方费用截至2026年8月16日的标准费用为日本国内卡片每1笔成功线上交易收取3.6%。标准费用没有初期费用或月费，使用Payments时，Checkout不另收手续费。
主要导入方法
- Checkout：前往Stripe提供的付款画面
- Payment Links：以电子邮件等提供付款URL
- API与支持的插件：与预订系统或自定义画面整合
请避免由旅宿保存卡号的方式，使用Stripe付款画面，或持续更新的正式整合功能。
Stripe可能适合预订系统正式支持、希望以线上预付款为主的旅宿。不过，若只使用Payment Links收款，可能仍需由人员比对是哪一笔预订的付款。请决定如何与预订编号链接。
Square：较容易统一线上与现场付款
Square官方费用列示线上付款3.6%、付款账单3.25%、手动输入卡片信息等非面对面付款3.75%。面对面付款依条件与付款方式，自2.5%起；付款装置费用等需另外确认。
以下旅宿可将Square列为比较候选。
- 希望在柜台收取卡片、电子货币与QR付款
- 希望统一线上付款与面对面付款的营收
- 希望向电话预订者寄送付款账单或付款链接
- 除住宿外，也收取商品、餐饮与体验费用
Square可以管理付款，但本身并不是管理客房房量的住宿预订系统。请决定付款完成后，由谁、如何更新预订台账。
预订系统内置付款：先确认这个选择
IT人员少的旅宿，预订系统正式支持的付款方式可能最简单。请向供应商确认以下事项。
- 是否只有付款成功才确认预订
- 付款失败或中途离开时，是否会持续占用房量
- 能否选择全额付款与订金
- 变更预订时，能否追加收取或退还价差
- 在管理画面取消预订时，付款是否也会退款
- 付款画面与电子邮件是否支持日语、智能手机
- 咨询窗口是预订公司还是付款公司
除系统使用费外，还可能产生付款手续费、付款整合费、退款、汇款与拒付的费用。
以一笔住宿的总费用比较手续费
住宿费30,000日元，以3.6%手续费付款，付款手续费为1,080日元。但实际比较还需包含以下项目。
付款总费用 ＝ 付款手续费 ＋ 预订系统整合费 ＋ 月费 ＋ 装置费 ＋ 汇款、货币换算与退款相关费用 ＋ 比对与退款的作业时间
费用与条件会改变，请不要只依本文数字决定签约，应以官方报价确认。
先设计取消与退款流程
导入付款时，退款最容易发生错误。
- 在住宿规章写明取消费开始日期与费率
- 决定谁有权批准取消
- 将预订台账改为取消状态
- 在付款管理画面进行全额或部分退款
- 记录退款金额、操作日期时间与负责人
- 向住客说明预计退款
- 日后比对入账明细与预订台账
Stripe标准费用说明，卡片退款不另收手续费，但原付款处理手续费等不会退还。部分付款方式会有退款手续费。
Square退款说明指出，可以全额、部分或按商品退款，并列示原交易日起1年内的条件。也需确认退款所需余额。
具体处理顺序与记录方法，可阅读取消、退款与未通知而未入住的应对方法。
安全上应遵守的事项
- 不要将卡号保存于电子邮件、笔记、预订台账或WordPress
- 不要将电话中取得的卡号输入一般管理画面
- 为付款与预订系统管理员设置2步验证
- 将退款权限限定于必要负责人
- 避免共用账号，保留操作记录
- 不要将API密钥贴入文章、聊天或公开代码仓库
- 更新整合插件，测试后再反映至正式环境
管理画面保护也可阅读WordPress登录的BASIC验证与2步验证。
上线前的测试
以小额或付款公司的测试环境，确认完整流程。
- 从智能手机预订一晚
- 付款成功后，预订确认电子邮件只收到一次
- 付款失败时，不确认预订
- 点击两次也不会重复收款
- 测试变更预订的追加收款与部分退款
- 全额取消，房量恢复可销售状态
- 旅宿端与住客端显示金额一致
- 可比对付款明细、预订编号与会计记录
即使请AI协助，也不要提供真实卡片信息，或只让AI执行正式退款。
选择的参考原则
优先比较Stripe
- 预订系统正式支持Stripe
- 以官方网站线上预付款为主
- 网站制作者能负责整合与维护
优先比较Square
- 现场无现金付款多
- 希望向电话预订者寄送付款链接或付款账单
- 希望统一商店、餐饮与体验付款
优先选择预订系统内置付款
- IT人员少
- 不希望在不同画面比对预订与付款
- 希望统一咨询窗口
预订系统候选可阅读小型旅宿预订系统比较与住宿预订可使用的OSS比较。
请AI协助比较的提示词
将为客房数［客房数］的旅宿导入线上付款。
预订系统是［产品名称］，现场付款是［目前方法］。
请只以官方信息比较Stripe、Square与预订系统内置付款。
比较项目：
- 是否支持线上、面对面、付款账单与订金
- 与预订确认、变更、取消、退款的整合
- 付款、月费、整合、装置、退款与汇款费用
- 2步验证、员工权限与操作记录
- 咨询窗口与故障时的替代运营
不要推测不明事项，请标记「官方信息尚未确认」。
最后，请列出向供应商提出的问题与上线前测试。
总结
Stripe的优势在于线上整合弹性，Square在于统一管理线上与现场付款，预订系统内置付款则在于与预订状态整合。
请先确认目前预订系统正式支持的付款，对同一笔预订测试「成功、失败、变更、取消、部分退款」。对小型旅宿而言，安全的付款方式不只取决于手续费，也取决于能否避免与预订台账不一致。
参考资料
※费用、功能、支持的付款方式与退款条件会改变。本文以2026年8月16日的官方信息为基础。签约前请向官方网站及个别报价再次确认。
