每条只问一句话。已答复、已拍板、我方能在沙盒自测的都已剔除；其余非阻塞项另有完整清单。One question each. Anything you have already answered, we have already decided, or we can verify ourselves in the sandbox has been removed. Non-blocking items are tracked separately.
我方的生产环境商户账户预计多久可以提供并开通？How soon can our production merchant account be provisioned and made available to us?
目前我方只有沙盒环境，生产 base URL、生产门户地址与生产凭证都还没有拿到。三端已按 GMA 接口开发完成，拿不到生产环境就无法安排联调与上线排期。We currently have sandbox access only; the production base URL, the production portal address and the production credentials have all yet to be issued. Our three clients are already built against the GMA interfaces, so without a production environment we cannot schedule integration testing or go-live.
如可一并说明：开通需要我方提交什么材料，贵行侧是否有验收或审核环节。If you can also cover: what we need to submit for provisioning, and whether there is a review or acceptance step on your side.
期望答复Answer时间（周期或日期）+ 开通所需材料Timeline (lead time or date) + provisioning requirements
卡状态变化（含 suspend / Block 之后）与卡消费授权是否有任何 webhook 事件推送？Are there any webhook events pushed for card status changes (including after suspend or Block) and for card spend authorizations?follow-up
贵行 8 月 31 日已答卡状态枚举与「下单成功后立即可在 GET /cards/{userId} 看到」，但我方同函所问的 webhook 与建议轮询频率两项未答，且 Webhooks 指南 16 个事件与开户族 10 个事件中无任何 Card 事件。C 端消费通知与 admin 卡同步只能靠轮询，频率定不下来就无法确定同步架构与对客时效文案。You answered on 2026-08-31 with the card status enums and confirmed that a card is visible on GET /cards/{userId} immediately after a successful order, but the webhook and recommended polling frequency questions in the same message were left unanswered, and neither the 16 events in the Webhooks guide nor the 10 onboarding events include any Card event. Customer-facing spend notifications and admin card sync can only run on polling, and without a fixed frequency we cannot settle the sync architecture or the timeliness wording shown to customers.
如可一并说明：若无 webhook，GET /cards/{userId} 与 GET /cards/{cardId}/transactions 官方建议的轮询频率与上限。If you can also cover: if there are no webhooks, your officially recommended polling frequency and its upper limit for GET /cards/{userId} and GET /cards/{cardId}/transactions.
期望答复Answer是否 + 事件名或轮询频率上限Yes/No + event names or polling frequency limit
卡寄出后的承运商与运单号，我方能否通过接口或门户 / 后台人工查询取得？After a card ships, can we obtain the carrier and the tracking number through an API, or through a manual lookup in the portal or your back office?follow-up
贵行 8 月 31 日已答 "Delivery tracking: Currently we are in development of this API and will share the updates"，未给排期与字段清单；现有 GET /cards/{userId} 仅返回 DeliveryStatus 的 Delivered | Pending | null，无承运商与运单号。C 端站内信 CARD_SHIPPED 的承运商 / 运单号变量目前无数据源，只能对客显示「寄送中」。You confirmed on 2026-08-31 that "Delivery tracking: Currently we are in development of this API and will share the updates", with no timeline and no field list; today GET /cards/{userId} returns only DeliveryStatus as Delivered | Pending | null, with no carrier and no tracking number. The carrier and tracking-number variables in our CARD_SHIPPED customer message have no data source, so we can only show the customer "in transit".
如可一并说明：物流追踪 API 的预计发布时间与字段清单（承运商 / 运单号 / 追踪 URL / 寄出与送达时间）。If you can also cover: the expected release date of the delivery tracking API and its field list (carrier, tracking number, tracking URL, shipped and delivered timestamps).
期望答复Answer是否 + 人工查询入口或 API 排期Yes/No + manual lookup path or API timeline
能否先在沙盒环境为我方配置一个测试用的 webhook 回调地址，让我们把接收端跑通？Can you configure a test webhook callback URL for us in the sandbox so that we can verify our receiver end to end?
我方沙盒回调接收器已经就绪，但 GMA 没有自助登记回调地址的接口，门户也没有对应入口，所以至今一次推送都没收到过，接收端无法验证。Our sandbox callback receiver is ready, but GMA has no self-service endpoint for registering a callback URL and the portal has no corresponding page, so we have never received a single push and cannot verify the receiver.
期望答复Answer是否 + 登记方式Yes/No + how to register it
贵行一共会向我方推送哪些事件，能否给一份完整清单、每种事件附一个真实的推送样例？What is the complete list of events you push to us, and can you provide a real sample payload for each one?
文档里只列了交易、入金、收款人三类共 16 个事件，开户相关的事件我们只能从沙盒的模拟接口反推，不确定生产环境到底推不推。我们要照着这份清单决定哪些状态可以靠推送、哪些还得自己轮询。The documentation lists only 16 events across transactions, deposits and counterparties; the onboarding events we can only infer from the sandbox simulation endpoints, so we do not know whether they fire in production. We need the full list to decide which statuses we can rely on push for and which we still have to poll.
如可一并说明：开户相关的事件（申请提交、补件、KYC、批准）在生产环境是否真的会推。If you can also cover: whether the onboarding events (application submitted, documents requested, KYC, approval) actually fire in production.
期望答复Answer事件清单 + 每种事件的推送样例Event list + a sample payload for each
客户开户申请的状态流转（提交受理 / 需补件 / KYC 完成 / 批准 / 账户开立完成并生成账号）能否新增 webhook 推送？Can you add webhook events for the state transitions of a customer's account opening application — submission accepted / documents required / KYC complete / approved / account opened with the account number generated?
开户状态目前只能靠 GET /application/detail/{id} 轮询 ApplicationState / Documents / Asks / Kyc、approved 后再用 POST /users/search 按邮箱反查 userId，Webhooks 指南只列 TRANSACTION_* / DEPOSIT_* / COUNTERPARTY_* 三族，form.* / document.* / kyc.* 仅见于 5 个 /simulate 端点；我方 2026-09-03 沙盒实测账号在 POST /cards/order 之后才生成，这一步同样无事件。Pad 端理财师需在客户在场时实时看到进度并当场引导补件，现按 3–5 秒轮询兜底，体验差且浪费调用量。Today onboarding state can only be discovered by polling GET /application/detail/{id} for ApplicationState / Documents / Asks / Kyc and then, after approval, reverse-looking up the userId by email via POST /users/search; the Webhooks guide lists only the TRANSACTION_* / DEPOSIT_* / COUNTERPARTY_* families, while form.* / document.* / kyc.* appear only on the five /simulate endpoints, and our sandbox test on 2026-09-03 showed the account number is generated only after POST /cards/order, a step that likewise emits no event. Our advisors need live progress on the Pad while the customer is present so they can request missing documents on the spot; the current fallback of 3-5 second polling plus manual page refresh is a poor experience and wastes call volume.
如可一并说明：若开户族 form.* / document.* / kyc.* 事件在生产已真实推送，请给出事件清单与负载样例。If you can also cover: whether the form.* / document.* / kyc.* events are already delivered in production and, if so, the full event list and sample payloads.
期望答复Answer是否 + 事件清单与负载样例（或排期）Yes/No + event list and payload samples (or timeline)
文档所列交易与入金事件我方至今未收到任何推送，是因为尚未登记回调 URL，还是需要贵行为我方合作方账户单独开通？We have never received a single push for the transaction and deposit events documented in the Webhooks guide — is that because we have not registered a callback URL, or because webhooks must be enabled separately for our partner account on your side?
Webhooks 指南列有 TRANSACTION_CREATED / AUTHORIZED / STATUS_UPDATED / DENIED / CANCELLED / EXPIRED / RETURNED 与 DEPOSIT_* 共 16 个事件，但我方一次推送也未收到，且 GMA 73 个端点无 webhook 注册端点、2026-09-02 沙盒门户 11 个导航页也无回调配置入口。admin 入金对账与 C 端汇款状态机均按「事件驱动 + 轮询兜底」设计，现在只有轮询一条腿，入账与状态更新存在分钟级延迟。The Webhooks guide lists 16 events — TRANSACTION_CREATED / AUTHORIZED / STATUS_UPDATED / DENIED / CANCELLED / EXPIRED / RETURNED plus the DEPOSIT_* family — yet we have received no push at all, none of the 73 GMA endpoints registers a webhook, and none of the 11 navigation pages in the 2026-09-02 sandbox portal exposes a callback configuration entry. Our admin deposit reconciliation and our customer-facing remittance state machine were both designed as event-driven with polling as a fallback; running on scheduled window pulls of POST /transactions plus per-transaction re-fetch alone leaves crediting and status updates minutes behind.
如可一并说明：开通所需的步骤、材料与对接渠道。If you can also cover: the steps, materials and contact channel required to get this enabled.
期望答复Answer开通步骤 + 是否需贵行侧开关Enablement steps + whether a switch on your side is required
请提供 ACH / 美国境内电汇（Fedwire）/ 国际电汇（SWIFT）/ 跨境本地币各轨道的生产费率表，含单笔固定费、百分比及计费基数、单笔与单日限额、到账时效、每日截止时点与时区？Can you provide the production fee schedule for ACH, US domestic wire (Fedwire), international wire (SWIFT) and the cross-border local-currency corridors, covering the fixed per-transaction fee, any percentage component and the base it is calculated on, per-transaction and daily limits, settlement time, and the daily cut-off time with its time zone?
C 端 REMIT 每屏需展示手续费，目前 feeMode = null 按 0 计并标「（待确认）」，admin 四轨费率（ACH 5.00 / DOMESTIC_WIRE 25.00 / INTERNATIONAL_WIRE 15.00+0.1% / CROSS_BORDER 0.5%）与 FV_RAIL_ETAS 均为演示值；2026-08-12 P0 澄清函 Table 1/2 至今未获书面费率，缺此数值我方无法对客展示手续费与到账预期。Every REMIT screen in our app has to display the fee; today feeMode = null so we compute 0 and label it "(TBC)", and our four admin rail fees (ACH 5.00 / DOMESTIC_WIRE 25.00 / INTERNATIONAL_WIRE 15.00+0.1% / CROSS_BORDER 0.5%) together with FV_RAIL_ETAS are demo values. Table 1 and Table 2 of our P0 clarification letter of 2026-08-12 have never been answered in writing, and without these numbers we cannot show customers a fee or a delivery expectation.
如可一并说明：preview 端点返回的 Fees（沙盒样例为 0）是否为生产真实应收，以及跨境轨道是否存在代理行 / 中间行下游再扣、导致收款人实收少于汇出额。If you can also cover: whether the Fees returned by the preview endpoint (0 in the sandbox sample) is the amount actually charged in production, and whether correspondent or intermediary banks deduct further fees downstream on the cross-border rails so the counterparty receives less than the amount sent.
期望答复Answer数值表（费率 / 限额 / 时效 / 截止时点）Rate card (fees / limits / settlement times / cut-off times)
贵行是否会开放按 CardOrderId 或 userId 查询卡订单及其 Applied / Approved / Denied 状态的端点或订单状态 webhook，若有请给排期？Will you expose an endpoint that queries card orders and their Applied / Approved / Denied status by CardOrderId or by userId, or a card-order status webhook, and if so what is the timeline?follow-up
贵行 2026-08-31 已答「下单成功后立即可在 GET /cards/{userId} 看到卡数据」，但沙盒门户 Debit Cards List 的「Card Orders」页签显示订单在贵行侧存在 Applied → Approved / Denied 的审批过程（14 单对 9 张卡、同一客户并存 3 条订单），而 POST /cards/order 只同步返回 Message + CardOrderId、73 个端点无订单查询、两族 webhook 均无卡事件。在开放查询手段前，我方只能靠新卡出现推断 Approved，Denied 完全无感知、流程会永远停在「已申请」。You confirmed on 2026-08-31 that card data is visible in GET /cards/{userId} immediately after a successful order, but the "Card Orders" tab in the sandbox portal's Debit Cards List shows an approval lifecycle on your side — Applied → Approved / Denied, 14 orders against 9 cards, with 3 orders open concurrently for one customer — while POST /cards/order returns only Message + CardOrderId in its synchronous response, none of the 73 endpoints query orders, and neither webhook family carries card events. Until a query mechanism exists we can only infer Approved from a new card appearing; a Denied order is invisible to us and the flow stays at "applied" forever.
如可一并说明：订单被 Denied 时合作方如何获知并拿到原因（请给原因枚举），以及同一客户是否允许并存多张 Active 卡或多条未完结订单。If you can also cover: how a partner learns that an order was Denied and obtains the reason (please provide the reason enum), and whether one customer may hold multiple Active cards or multiple open orders at the same time.
期望答复Answer是否 + 排期Yes/No + timeline
请给出 ReservedAmount 的完整构成清单（待授权付款 / 卡已授权未清算 / 入金合规 hold / 风控 hold）及各自对应的释放事件？Can you give the complete list of what makes up ReservedAmount (payments pending authorization, authorized but unsettled card transactions, compliance holds on inbound deposits, risk holds) and the release event for each of them?
沙盒门户客户详情显示余额三段 Actual balance $160,260 / Reserved amount $150,511 / Available balance $9,749，对应 POST /users/{userId}/accounts/USD/balance 的 Balance / ReservedAmount / AvailableBalance，但 API 文档只给字段无规则、帮助中心 #137 仅称 reserved 为 pending 交易占用，GET /users 与 assigned-user-balances 又只返回单值 Balance。三端「可用余额」的校验口径与 C 端「冻结金额」的展示都取决于这套规则。The customer detail page in the sandbox portal shows three balances — Actual balance $160,260 / Reserved amount $150,511 / Available balance $9,749 — matching Balance / ReservedAmount / AvailableBalance from POST /users/{userId}/accounts/USD/balance, but the documentation gives the fields without any rules, help center #137 only states that reserved is held by pending transactions, and GET /users and assigned-user-balances return a single Balance. The balance check across our three clients and the "held amount" we show customers both depend on these rules.
如可一并说明：持卡人刷卡授权是否直接从其 FV USD 账户扣款并计入 ReservedAmount，以及 GET /users 的单值 Balance 与 webhook Data.Balance 对应三段中的哪一段。If you can also cover: whether a cardholder's card authorization debits their FV USD account directly and counts toward ReservedAmount, and which of the three balances the single Balance field in GET /users and the webhook Data.Balance correspond to.
期望答复Answer枚举全集（构成 + 释放事件）Full enum (components + release events)
生产环境付款（FVNet / ACH / 电汇 / 跨境）创建后由 pending 推向 authorized，是规则自动授权还是贵行合规 / 运营人工授权？For production payments (FVNet / ACH / wire / cross-border), once created, is the move from pending to authorized performed automatically by rule, or does it require manual authorization by your compliance or operations team?follow-up
贵行 2026-08-31 已答 FVNET 内转 24×7、命中监控的交易进人工队列并发 RFI，但未说明常规 pending 如何推进；沙盒门户 Dashboard 显示「PENDING AUTHORIZATION awaiting approval 17 · 52% of processed volume still needs authorization」却无任何 Approve / Authorize 按钮，API 侧 /sandbox/transaction/accept|deny|cancel 也仅沙盒可用、生产无授权端点。C 端汇款成功页的对客预期与 admin 的 pending 超时告警阈值都取决于谁在多久内推进。You confirmed on 2026-08-31 that FVNet runs 24x7 and that transactions hitting monitoring enter a manual queue with an RFI, but not how an ordinary pending payment advances; the sandbox portal Dashboard shows "PENDING AUTHORIZATION awaiting approval 17 · 52% of processed volume still needs authorization" while we found no Approve / Authorize control in the portal, and /sandbox/transaction/accept|deny|cancel is sandbox-only with no production authorization endpoint. Both the customer-facing expectation on our remittance success screen and our admin pending-timeout alert threshold depend on who advances these payments and how quickly.
如可一并说明：未命中监控时从 API 返回到 authorized 的典型时延与自动放行的条件及单笔 / 日累计额度、pending 多久会变 TRANSACTION_EXPIRED，以及合作方能否取消一笔 pending 付款。If you can also cover: the typical latency from the API response to authorized when a payment does not hit monitoring, the conditions and per-transaction / daily cumulative limits for automatic release, how long a pending payment takes to reach TRANSACTION_EXPIRED, and whether a partner can cancel a pending payment.
期望答复Answer授权主体 + 是否自动放行Authorizing party + auto-release Yes/No