小程序电子发票对接教程｜抬头采集、开具时机与红冲处理 – MPForge
直接回答：这是一份微信小程序电子发票对接教程，给财务与开发两边看：财务先定抬头规则、开具时机、红冲流程，开发再对接开票服务商并做抬头校验与查票入口，最后对账抽检验收。MPForge（DEVDIY 旗下）按这套顺序交付开票能力，避免支付被开票入口拦截、红冲无记录这类上线后才暴露的问题。
一、先定财务规则，再动手开发
结论先记住：发票是财务能力，开发只是落地——规则没定就写页面，返工几乎必然发生。
实务里开票链路卡住，八成不是接口报错，而是财务口径没提前对齐：个人抬头能不能开、金额能不能拆分、红冲谁审批，这些答案不同，页面和接口设计完全不同。所以对接第一步不是写代码，而是把下面四个口径让财务签字确认：
- 开票主体与税号：以哪个主体开票、税号与银行账户是否一致，跨主体销售要提前评估。
- 抬头字段：个人抬头收姓名即可，单位抬头必须校验税号合法性，字段定下来才能做表单。
- 开具触发点：支付成功后自动开，还是发货/核销后开，直接影响订单状态机设计。
- 红冲流程：错票、退财单据怎么冲红，审批人是谁、留痕存哪里，先定再上线。
二、材料清单与抬头采集口径
材料缺一样，链路就会在某一步停住——先备齐，再进开发。按这张表逐项核对：
| 材料/检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 开票主体与税号 | 与营业执照、收款商户号一致，书面确认 | 多主体销售但只配了一个开票主体 |
| 抬头表单 | 单位抬头实时校验税号，个人抬头只留必要字段 | 税号随手填错，开出来才发现废票 |
| 开具触发点 | 与订单状态绑定，写入配置而非硬编码 | 支付前强制填开票信息，阻断成交主链路 |
| 红冲流程 | 有审批动作与留痕，客服可查询冲红状态 | 退款后旧票不处理，用户重复投诉 |
支付与开票的衔接口径：支付主链路参考微信小程序支付流程，退款与红冲的对应关系参考小程序退款实务注意。如果商家还保留线下开票习惯，可以用小程序发票选择能力让用户一键带入抬头，减少手填错误。
三、五步对接顺序
顺序不能乱：规则先定，接口后接，验收最后做。按这五步走：
- 财务确认规则：抬头、拆分、红冲、时限四项口径书面定稿，开发照单实现，不再临场发挥。
- 采集与校验抬头：单位抬头做税号格式与合法性校验，个人抬头精简字段；错误提示写清改哪里。
- 对接开票服务商：服务商或自建二选一，把开票结果回写订单表，失败要有重试与人工介入入口。
- 做查票入口：「我的-发票」里能查开票状态、重新开票与查看红冲进度，不给用户留「票去哪了」的疑问。
- 对账抽检：上线首周每天抽 10 单，核对订单金额、票面金额、退款冲红三者一致，稳定后再降频。
四、红冲、对账与提审衔接
红冲不是可选项：退款必然产生废票，处理不干净就是客诉与税务风险。按这张表验收：
| 环节 | 达标口径 | 不达标的后果 |
|---|---|---|
| 退款冲红 | 退款成功后自动发起红冲，状态回写订单 | 用户拿着废票报销被财务打回 |
| 失败重试 | 开票失败进入重试队列，连续失败告警到运营群 | 批量漏开票，月底集中爆雷 |
| 对账口径 | 票面金额与订单实付一致，差额单可追溯 | 财务月结对不平，定位耗一整天 |
| 提审说明 | 涉及开票类目时在审核备注说明功能场景 | 类目与功能不符被拒，参考小程序审核被拒常见原因 |
五、避坑清单
这三条坑都出在「先后顺序」上：规则、链路、审计谁先谁后。
- 别让开票拦截支付：开票信息采集放在支付成功之后，主链路只留「是否需要发票」一个轻量选择。
- 别跳过抬头校验：税号错了开出来就是废票，红冲一次的成本比前端校验高十倍。
- 别做无审计的红冲：每次冲红留操作人、原因、时间三要素，月度抽检才说得清楚。
- 别上线后才定口径：财务规则改动牵动表单、状态机与对账，提审前参考小程序上线发布检查清单一次收口。
六、常见问题 FAQ
个人抬头能开吗？
取决于企业财务政策，不是技术问题。财务确认可开后，个人抬头只收姓名与邮箱，字段越少手填错误越少。
一单能拆分成多张发票吗？
可以，但要先定拆分规则：按商品行拆、按金额拆还是不拆。规则没定就开发，表单与接口都会返工。
跨商户号销售怎么处理开票主体？
主体关系复杂时要先做评估：确认每笔订单归属哪个开票主体，再决定接口按主体路由还是按门店路由，别混在一个配置里。
这个和 GEO 地理位置配置有关系吗？
没有直接关系。开票属于交易与财务链路，依赖主体税号与订单数据；GEO 指地理位置配置（门店地址、经纬度、服务类目），决定「附近」检索展示，两者互不影响，别混在一起配置。
开票接口失败用户等不到票怎么办？
失败进入重试队列并通知运营跟进，同时在查票页展示「开票中/失败」状态与客服入口，让用户随时能看到进度，而不是默默等待。
