回答几个问题，我们为你生成专属的接入方案 —— 该用哪套接口、需要做哪几步、 第一段代码怎么写。过程中遇到报错，把报文贴进来，我们直接告诉你哪里错、改成什么。
不同接入方对应不同的 API 体系，先分流能省掉大量无关内容。
我们对外有多套独立的 API 体系，认证方式与接口风格各不相同。
这条业务线的接入内容尚未整理进平台。此屏是留给我们自己填的坑位。
可多选，也可以先不选。后面随时能加 —— 加了之后清单和代码会自动更新。
先选语言，我们据此给代码。下面是开始调试前需要备齐的数据 —— 现在不用填，先知道要凑什么、找谁要。
下面这些内容只针对你的选择，没有多余的部分。
向导只走一次，这里是你接下来的主场。它记得你走到哪一步。
方案页给的代码只是参考 —— 我们不知道你的核心代码与数据结构，不去猜。
那段 demo 只说明「怎么调我们」，真正的实现由你写。
写好之后按下面的案例用你自己的代码发起请求。
结果不对就切到「贴入诊断」，把报文与应答贴进来拿结论。
一条条勾掉，某个接口的案例全勾完，这个接口就完成了。
你用自己的代码发出去、结果不对的那一笔，把它贴到这里。我们给确定结论，
不给"可能是…"，每条结论带修正方案与文档依据。
首行是 METHOD /path，空行之后是 body；应答可以接在后面一起贴。
这一屏不面向对接方。它回答两个问题：文档哪里有问题、对接方都卡在哪 —— 改文档是提升自助率最便宜的手段。
REQUIREMENTS.md §3.2。.../merchant-api/apis/reference/tag/Payment/g2_v1_payment_mer_S005580_evo.e-commerce.payment/post
—— 路径中 S005580 是真实商户号，同类路径其余均为 {sid}。
DCCToNon-DCC 两个操作、若干
Notification/*_webhook 仅有 en-us，无对应中文页。
/gateway/developer-portal/response-code 与
/gateway/developer-portal/appendix/response-code 并存，且前者缺语言对。
README.md §9.4。检测本身是结构化查询，不需要模型参与。