Swipelux API 變更日誌與版本說明

​

新增

• 收款人目的地接受 pix 與 pix_safe 類型，用於巴西的 BRL 出金。Pix 目的地會付款至 Pix 金鑰。Pix Safe 目的地會付款至以持有人的 CPF 或 CNPJ、銀行的 ISPB 代碼、分行及帳號識別的銀行帳戶。兩者都需要客戶已就緒的 Pix 功能（pix_pooled），其出金以 USDC 提供資金，且不收取開發者費用。請參閱收款人與發送資金。
• GET /v3/customers/{customerId}/tasks/{taskId} 接受帶有文件要求 ID 的 documentCandidatesFor，以及用於具備替代方案之要求的 documentAlternativeKey。回應隨後會在 data.documentCandidates 中列出客戶已上傳且可滿足該要求的檔案，並附上任何 missingMetadata 或 conflictingMetadata。請提交候選檔案的 documentId 並補上缺少的 documentMetadata，而不必重新上傳檔案。此查詢需要 accounts:read 與 customers:read，無效的選擇會傳回 400 validation_error。

​

變更

• GET /v3/webhooks/portal 傳回的入口網站 URL 會在一小時後到期，並附上 Cache-Control: no-store。使用具有 webhooks:write 的 API 金鑰時，入口網站會顯示端點簽章密鑰，並可管理端點、重試派送及重播派送。僅具有 webhooks:read 時，入口網站只會顯示派送記錄。請參閱Webhook。
• Citi（citibank）僅提供給企業客戶。所有企業都保有共用（pooled）Citi，而具名（named）Citi 僅提供給在美國境外註冊的企業。當客戶未獲提供 Citi 時，支援清單會省略它，指定它會傳回 422 capability_institutions_unsupported，且僅由 Citi 提供的方法會列為 disabled。未包含 institutions 的要求會從其餘銀行中選擇。既有的申請與帳戶不變。
• 具名 CFSB（cfsb）功能僅提供給美國客戶：在美國註冊的企業，以及居住在美國的個人。對於其他客戶，支援清單會省略具名 CFSB，指定它會傳回 422 capability_institutions_unsupported。未包含 institutions 的要求會從其餘銀行中選擇。共用 CFSB、國家不明的客戶以及既有的申請均不變。
• Lead Bank（lead_bank）的具名 ACH、Wire 與 SWIFT 功能，僅提供給 Lead Bank 依其法律形式與國家能夠完成開戶的客戶。對於其他客戶，支援清單會省略 lead_bank，指定它會傳回 422 capability_institutions_unsupported。Lead Bank 已完成開戶的客戶，以及其未結要求已指定 lead_bank 的功能，會保留它。既有的申請與帳戶不變。
• RTP 僅提供共用（pooled）方式。沒有任何銀行向新要求提供 rtp_named，因此支援清單會將其顯示為 disabled。對於未持有 rtp_named 的客戶，針對它且指定銀行的功能要求或任務預覽會傳回 422 capability_institutions_unsupported，未包含 institutions 的則會傳回 422 capability_variant_unavailable。共用 RTP（rtp_pooled）由 Citi 提供，因此僅企業客戶可以申請。
• 針對個人與最終受益人的新身分文件要求可設定 constraints.identityMetadataRequired: true，因此每個檔案都需要在 documentMetadata 中提供證件號碼與簽發國家。新的企業地址證明與擁有者居住證明要求可設定 constraints.maxIssueAgeDays: 90，因此每個檔案都需要其簽發日期。既有任務會保留其要求，因此請讀取每個任務要求上的限制條件。
• 針對企業註冊要求（其 profilePointer 為 /business/registration）的任務答案，需要同時提供管轄國家、註冊號碼，以及早於提交日期的成立日期。該要求的 valueSchema 會公布此規則，部分答案會傳回 400 validation_error。
• 完成託管驗證後，對於結構化值（例如地址或稅務識別碼）的個人資料要求，Swipelux 僅在託管答案通過與直接答案相同的結構描述與限制檢查時才會接受。否則該要求會保持開啟，您需使用 POST /v3/customers/{customerId}/tasks/{taskId}/submissions 提交該值。因這一原因被 Swipelux 退回 action_required 的要求會帶有 reviewFeedback.code: hosted_profile_direct_submission_required。已為 satisfied 的任務會維持其狀態。請參閱功能與要求。
• 遭託管驗證拒絕的任務，若該驗證決定日後被撤銷，可能會離開 rejected。此時任務會變為 satisfied，或在新的 revision 下變為 action_required，並重新開啟新決定未回答的要求。這些要求先前的提交仍為 rejected，因此請重新提交這些答案。請參閱遷移至 v3。
• 收款人目的地的 type 現在是開放式列舉。本參考資料的先前版本將其描述為封閉式，因此請更新任何會拒絕或捨棄未知類型的用戶端。目的地回應與 destination.status_changed 事件現在可能帶有 pix 與 pix_safe，日後也可能新增更多類型。
• 收款人建立與更新要求（包括巢狀的 address）會忽略未定義的欄位，而不會傳回 400 validation_error。在建立要求中，屬於另一種收款人類型的名稱或產業欄位仍會傳回 400，PATCH /v3/customers/{customerId}/recipients/{recipientId} 中的 type 與 externalId 亦同。不含任何可識別欄位的 PATCH 會傳回 400 validation_error，而非 200。
• 對於僅要求文件的合格工作階段，驗證連結現在會開啟由 Swipelux 託管的文件上傳頁面。連結本身不變，其他工作階段仍會開啟託管的驗證流程。
• 個人客戶與關聯方人員的 employment.occupation 最多接受 255 個字元。
• 當資料值或任務答案包含 Swipelux 表單連結（例如 RFI、客戶請求或轉帳追蹤連結）時，POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} 與 POST /v3/customers/{customerId}/tasks/{taskId}/submissions 會回傳 400 validation_error。這不適用於 externalId 或 metadata。每個被拒絕的值都會出現在 errors[] 中，並附上 code: public_form_link 及其 JSON Pointer，且回應絕不會重複該連結。請改為直接傳送資訊本身。請參閱錯誤與重試。

​

修正

• 出金報價與轉帳回應會將 USDC 或 USDT 來源金額保留至小數點後六位，例如 4009.711365 而非 4009.71。法幣金額保留兩位小數。建立或讀取穩定幣來源金額超過兩位小數的出金時，不再傳回 500。
• POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel 參考資料現在會依實際運作方式說明取消。您可以取消狀態為 ready 的功能，stablecoin_transfers 功能無法取消，且取消只會終止該功能，其申請仍會保留各自的狀態、任務與核准。
• 在 institutions 中列出銀行代碼而非公開機構 ID（例如以 citi 代替 citibank）的功能要求或任務預覽，會傳回列出可用 ID 的 422 capability_institutions_unsupported，而非 503 kyc_configuration_unavailable。
• 針對沒有任何銀行向該客戶提供的方法（支援清單將其顯示為 disabled）的功能要求或任務預覽，會傳回附帶 retryable: false 的 422 capability_variant_unavailable，而非 503 kyc_configuration_unavailable，除非客戶已持有該功能。
• documentCandidates 不再列出 Swipelux 從已完成的託管驗證中保留的檔案，這些檔案您無法讀取或下載。引用此類檔案的任務答案會傳回 400 invalid_document_reference，與未知文件相同。

​

新增

• GET /v3/customers 接受 include=documentRequirements。每筆客戶摘要隨後會回報仍待提交的必要文件數量，與功能就緒狀態無關。可合併使用 include=capabilities,documentRequirements。請參閱客戶。
• 商家面板的 Webhooks 頁面在端點選單中新增 Replay missed events。它會重新傳送過去 13 天內端點從未收到的事件，且絕不會重複傳送同一事件。請參閱Webhook。
• 商家面板的 Settings 頁面新增 Compliance 區段。擁有者與管理員可以設定合規電子郵件地址，並選擇在 Swipelux 要求提供客戶的更多資訊時是否接收電子郵件。
• 商家可以直接在商家面板的 KYB 頁面回覆自己的 KYB 合規要求。

​

變更

• 銀行受理完成後，客戶與關聯方更新不再傳回 409 field_conflicts_with_completed_intake。更新會被儲存，每個新的銀行申請都會依其自身要求檢查最新的客戶檔案。
• 當功能現有的銀行路由無法安全更新時，功能要求會傳回 409 capability_route_header_conflict。重試前請聯絡 Swipelux 支援團隊。
• 當 institutions 指定了該功能不提供的銀行時，GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview 會傳回 422 capability_institutions_unsupported，與功能要求的行為一致。
• 在沙盒中，ACH、Wire 與 SWIFT 功能僅由 JPMorgan Chase 提供。省略 institutions 的要求會選擇 jpmorgan，指定其他銀行則會傳回 422 capability_institutions_unsupported。正式環境的路由不變。請參閱在沙盒中測試。
• 當模擬案例無法達到所要求的狀態時，強制設定沙盒功能狀態會傳回 409 capability_status_blocked 並附上 statusReason。重複已套用的強制設定會傳回 200，且不做任何變更。請參閱在沙盒中測試。
• 對於由營運團隊或其他工作流程擁有的任務,POST /v3/sandbox/tasks/{taskId}/review 會回傳 409 task_not_sandbox_reviewable。來自 POST /v3/sandbox/tasks 的任務以及 Swipelux 收集的能力受理任務仍可審核。請參閱在沙盒中測試。
• 若在帳戶仍於銀行端佈建時變更結算設定，PATCH /v3/customers/{customerId}/accounts/{accountId} 會傳回 409 account_provisioning_unresolved。請在佈建完成後重試。請參閱錯誤與重試。
• POST /v3/transfers 可能會傳回 409 quote_execution_evidence_conflict。請建立新的報價並執行。請參閱錯誤與重試。
• 商家面板的 Pay out 抽屜會顯示完整的目的地資料、以切換開關遮蔽帳號與錢包地址，並顯示每種付款方式的預估到帳時間。
• 商家面板將銀行帳戶併入客戶的 Payment access 分頁，並提供列出每家銀行名稱的任務卡片。Documents 分頁已移至 Profile。
• 在商家面板中開立具名銀行帳戶現在只需一個步驟，並會列出每家銀行的幣別、方式與入駐時間。請參閱帳戶。
• 因審查而被暫停的銀行帳戶會在商家面板中顯示為 On hold，並附上帳戶 ID 與 Contact support 操作。
• 當 Swipelux 正在準備提交申請且尚未開始審查時，處於 pending 的能力現在會回報 statusReason.code: preparing_submission，而非 review_in_progress。兩個代碼都使用 resolution: wait。在兩者之間切換時狀態仍為 pending，因此不會傳送 capability.status_changed 事件。現有能力會在下一次重新評估時採用新代碼。請參閱功能與要求。
• 商家面板中客戶 Payment access 分頁上的 Shared methods 表格，對於能力回報 preparing_submission 的共用方式，會顯示 In preparation 而非 In review。
• 能力的 applications 列表現在僅顯示其目前的申請，適用於能力讀取（包括 GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications）、能力申請回應以及 capability.status_changed 事件。被較新申請取代的申請仍會出現在 GET /v3/customers/{customerId}/applications 中，其中 supersededByApplicationId 指明其後繼申請。被取代申請的未完成任務仍計入能力的 openTaskIds。能力的狀態與 openTaskIds 不會改變，因此此變更本身不會傳送任何 webhook 事件。請參閱功能與要求。

​

修正

• 在銀行核准前，針對同一已發行帳戶送出的第二個 allowPending 要求，現在會傳回 409 並在 holder.accountId 中指出等待中的帳戶，而不是傳回 500。請參閱發行銀行帳戶。
• 取消功能時，現在會關閉仍在等待銀行核准的已發行帳戶要求，讓之後在同一家銀行的要求重新開始。
• 重新要求所有銀行案件皆遭拒絕的已取消功能時，會從 canceled 發布單一 capability.status_changed 事件。
• 在銀行先前的申請已封存後重新要求該銀行，現在會提交新的申請。
• 只要對應的功能顯示為 ready，即可新增收款人目的地，而不會傳回 409 rail_not_ready。請參閱收款人。
• 在您首次開啟商家面板的 Webhooks 頁面之前傳送的 Webhook 事件現在會被保留，因此您可以將其重新傳送至新的端點。
• 商家面板中的任務到期日會以您自己的時區顯示，且當沒有任何待處理項目時，銀行審查抽屜會顯示 All requirements submitted。

​

新增

• POST /v3/quotes 接受選用的 institutionId，用於為加密貨幣轉法幣的出金報價選擇已核准的銀行通道。省略此欄位即維持自動路由。若選擇無法用於該出金的銀行，會傳回 422 bank_not_supported_for_customer；若在任何其他報價類型上傳送 institutionId，則會傳回 400 validation_error。請參閱發送資金。
• POST /v3/customers/{customerId}/accounts 上的已發行銀行帳戶要求現在接受 institution，可將帳戶固定於單一銀行且不進行備援切換；並接受 allowPending: true，可在該銀行的申請仍待核准時先儲存要求。allowPending 需要搭配 institution。已儲存的要求會回報所依據的 applicationId。請參閱發行銀行帳戶。
• 商家面板新增原生 Webhooks 頁面，用於管理端點。請參閱Webhook。
• 商家面板新增 Pay in 抽屜，提供具名銀行帳戶、加密貨幣存款與審核步驟。
• 商家面板的 Pay out 流程會在來源選擇器中顯示錢包餘額、新增 Max 金額選項，並包含審核步驟。
• 商家面板中的客戶檔案新增 Recipients & destinations 分頁。
• 任務要求可以包含簡短的 title 標題。要求的 prompt 仍承載指引說明。請參閱功能與要求。

​

變更

• 共用（pooled）Wire 通道上的 Wire 入金報價現在至少需要 $20。低於通道最低金額，或金額過小而不足以支付轉帳費用的報價，會傳回 422 amount_not_deliverable，而不是一般的報價失敗。請參閱接收資金。
• Webhook 入口網站現在會依資源將 v3 事件類型分組，並顯示每個事件的 payload schema 與範例。舊版事件類型會顯示在獨立的 Legacy 群組中，並標示為已淘汰。已訂閱這些事件類型的端點會繼續收到它們；新訂閱請使用 v3 事件類型。請參閱Webhook。
• 沙盒儲值現在會發出 transfer.created 與 transfer.state_changed webhook 事件。請參閱在沙盒中測試。
• 當客戶已有使用中的已核發帳戶時，accountProvisioning 現在會回報 issued。請參閱功能與要求。
• 商家面板中的銀行帳戶詳細資料會在抽屜中開啟，並顯示銀行標誌。請參閱帳戶。
• 商家面板將資金移動標示為 Pay in 與 Pay out，讓您保持登入六小時，並以電子郵件將協助要求傳送給 Swipelux 支援團隊。
• 在接受直接提交的受理任務中，已有客戶檔案或已上傳文件佐證的合格要求會自動進入 in_review。請參閱功能與要求。

​

修正

• 重新要求已取消的功能時，不再因已被取代的申請紀錄或過時的要求而失敗。
• 儲存在已停用 Fedwire ID 下的功能現在會讀取為 wire，而不是傳回 500。

​

新增

• GET /v3/customers/{customerId}/applications 會列出客戶的申請案件，並附上每個案件所要求的功能，以及其核准所涵蓋的功能。一家銀行的一次核准可涵蓋多項功能。保留的歷史案件會透過 supersededByApplicationId 指向其後繼案件。此清單支援游標分頁與 updatedAfter。請參閱功能與要求。
• 對於以案件為基礎的功能，POST /v3/customers/{customerId}/capabilities/{capabilityId} 的回應會包含 selectedApplicationId。它會識別該要求重複使用的既有申請案件，或其所開啟的案件。請參閱功能與要求。
• 由 GET /v3/institutions 與支援功能清單傳回的機構包含可為 null 的 logoUrl。可用時請用它顯示銀行品牌，當其為 null 時則改為顯示機構名稱。請參閱功能與要求。
• 現已提供 USD SWIFT 出金。SWIFT 出金至少需要 100 USD。商家面板會為收款人收集 SWIFT 銀行指令。請參閱發送資金。
• 已發行銀行帳戶可透過具名收款資料經由 SWIFT 收款。請參閱發行銀行帳戶。
• USDT 現在可作為 ACH 與 Wire 出金的來源。請參閱發送資金。
• 已發行銀行帳戶現在接受值為 USDC 或 USDT 的 settlement.currency，用於選擇交付至結算錢包的穩定幣，且與錢包帳戶的幣別無關。省略此欄位則繼續以錢包的幣別結算。請參閱發行銀行帳戶。
• SWIFT 銀行帳戶與收款人目的地接受 bankCity、bankState、bankPostalCode 與 bankAddressLine2，以及選用的 beneficiaryTaxId、beneficiaryPhoneNumber、ifscBranchCode、paymentCode 與中介銀行資料。請參閱發送資金。
• 當銀行提供分開的 ACH 與 Wire 路由號碼時，已發行銀行帳戶的詳細資料會包含 achRoutingNumber 與 wireRoutingNumber，並包含收款銀行的 bankLogoUrl。請參閱發行銀行帳戶。
• capability.created webhook 事件包含 applicationId，以及值為 requested 或 approval 的 origin，讓您能區分自己要求的功能與由核准所涵蓋的功能。請參閱Webhook。
• 要求可以宣告用於驗證的 constraints.format，例如 http_url、us_ssn、us_ein 或 bank_industry_classification。請參閱功能與要求。

​

變更

• 商家面板的銀行帳戶建立流程現在從選擇銀行開始，且銀行帳戶會顯示分開的 ACH 與 Wire 路由號碼。請參閱帳戶。
• network 列舉現在包含 solana。這是開放式列舉，因此請容許您無法辨識的網路值。請參閱帳戶。
• 若任務的剩餘要求需要直接提交，為該任務開啟託管驗證連結會傳回 409 verification_session_not_allowed。請改以任務提交的方式提交這些要求。請參閱錯誤與重試。
• 封存佈建尚未完成的已發行帳戶會傳回 409 account_provisioning_unresolved。請在佈建完成後重試。請參閱錯誤與重試。
• 新的具名銀行帳戶要求會在帳戶建立後立即排入佈建佇列，而不是等待下一次客戶重新整理。請參閱發行銀行帳戶。

​

移除

• 新帳戶不再提供共用（pooled）的 SWIFT 收款資料。請改用具名 SWIFT 收款資料。請參閱發行銀行帳戶。

​

修正

• 讀取出金轉帳現在會傳回報價中的收款人。
• 封存既有 ACH 帳戶後再建立 ACH 帳戶不再傳回 409，且已封存的待處理帳戶要求不再占用帳戶名額。
• 本地幣別入金報價上的銀行費用現在會以正確的法幣幣別回報。

​

新增

• GET /v3/webhooks/{webhookId} 可讀取單一 webhook 端點及其 events 選擇。請參閱Webhook。
• 任務要求現在會為檔案欄位（包括必填的地址欄位）發布 allowedValues 與 JSON Schema valueSchema。國家欄位會回報值為 country 的 valueType 或 itemValueType，代表 ISO 3166-1 alpha-2 代碼。您無須寫死即可呈現輸入欄位與選項。請參閱功能與要求。
• 現有的 Tron 錢包現在可以將 USDT 發送至客戶的外部錢包帳戶，且轉帳讀取會包含 Tron 交易的區塊瀏覽器連結。無法在 Tron 上發行新錢包。請參閱發送資金。
• 任務要求可以宣告 requiredWhen（僅在指定的是/否回答相符時才需作答）、profileAssertion（us_person）與 ownershipPolicy，文件要求可以設定 identityMetadataRequired 與 maxIssueAgeDays。任務回答接受針對所參照文件的 documentMetadata（idNumber、issuingCountry、issuedOn），且任務讀取會在 conditionValues 中傳回已審查的控制性回答。請參閱功能與要求。
• 文件要求可以列出 acceptedDocumentSets，且關聯方要求除了 beneficial_owner 之外，也可以要求 associated_person 或 control_person 資格。請參閱功能與要求。
• 轉帳 correction 物件現在也涵蓋已注資但失敗的出金：kind: funding_failure，並附帶 recover_source_funding 補償動作、值為 unknown 或 reported 的 recoveryStatus，以及 USDT 入帳輸出。請參閱報價與轉帳。

​

變更

• PATCH /v3/webhooks/{webhookId} 現在接受端點已訂閱的舊版事件類型，讓您在新增 v3 事件類型時仍可保留它們。events 會取代整個選擇，因此請包含所有您想保留的事件類型。新增端點原本未訂閱的舊版事件類型會傳回 400 validation_error。請參閱Webhook。
• 收款人與帳戶上的銀行識別碼會在儲存前進行驗證。請參閱收款人。
• 當功能是在較早的入駐模型下建立時，功能要求、任務提交與沙盒狀態變更現在會傳回 409 capability_application_stale，而不是 500。請參閱錯誤與重試。
• 公開 RFI 頁面現在是單一連續表單。它支援關聯人員，並為每位人員收集一個稅務 ID。請參閱文件要求。
• 當付款超過客戶在銀行的剩餘每日或每月額度時，報價與轉帳會傳回 409 customer_bank_limit_exceeded；無法檢查該額度時則傳回 503 customer_bank_limits_unavailable。當出金無法從其報價開始時，轉帳會傳回 409 payout_execution_unavailable。請參閱錯誤與重試。
• 與已完成的銀行受理衝突的客戶與關聯方更新會傳回 409 field_conflicts_with_completed_intake，並附上 taskId 與 fields。

​

修正

• 已取消的功能歷程仍可讀取。
• Wire 出金在商家面板的交易清單中能正確顯示與篩選。

​

變更

• POST /v3/transfers 與轉帳讀取現在使用 checkoutMethod 而非 paymentMethod 來預先選擇卡片結帳方式，並接受 card、apple_pay、google_pay、cash_app、sepa 與 blik。此清單是開放的且可能增加。paymentMethod 不再被識別；仍傳送該欄位的請求會被視為省略了它。sepa 與 blik 是卡片結帳內部的付款選項，而不是 Swipelux 的能力。請參閱接收資金。

​

新增

• POST /v3/transfers 現在接受選用的 paymentMethod（card、apple_pay 或 google_pay），用於卡片報價。當請求的方式對客戶及其裝置可用時，託管結帳會以該方式開啟；轉帳讀取會回傳該請求，報價的金額與費用保持不變。請參閱接收資金。
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview 接受 institutions，可預覽支援功能清單所傳回之特定銀行的任務。請參閱功能與要求。

​

變更

• 信用卡報價現在會反映結帳費用與實際交付的淨 USDC。請參閱接收資金。
• 遭拒的出金報價現在會傳回具體的問題代碼，而非一般失敗：quote_amount_out_of_range、quote_volume_limit_exceeded、quote_source_network_unsupported 或 quote_failed；當報價可稍後重試時則傳回 503 quote_temporarily_unavailable。請參閱錯誤與重試。

​

修正

• 信用卡報價不再因費用四捨五入而失敗。
• 當問卷答案包含多餘空格時，重新開啟託管 KYC 連結不再傳回 409 kyc_process_conflict。
• 商家面板中停滯的通行金鑰提款確認現在會恢復。

​

新增

• POST /v3/customers/{customerId}/documents 現在也接受含 storageKey、fileName 與 type 的 application/json 要求本文。storageKey 必須是先前透過 direct-upload 流程暫存、仍在時效內的客戶範圍參照，且上傳會通過與 multipart 上傳相同的大小與檔案簽章驗證。請參閱遷移至 v3。
• GET /v3/customers/{customerId}/documents/{documentId}/download 會為使用中的客戶文件傳回下載 url。該 URL 於一小時後到期，並以附件形式提供檔案。已封存、未知或屬於其他客戶的文件會傳回 404。請參閱功能與要求。
• 為沒有受益所有人的企業要求功能時，現在會建立用於新增受益所有人的受理任務，而不是以 503 失敗。無法繼續的要求會傳回 422 beneficial_owner_required，並附上說明，要求新增一位已申報或至少持有 25% 所有權的個人關聯方。請參閱股東、UBO 與控制人員。
• 商家面板的任務表現在會顯示每個要求的主體與功能範圍，讓您了解合規要求涵蓋的對象與內容。請參閱功能與要求。
• 商家面板中的行業分類欄位現在在客戶檔案與要求任務上提供可搜尋的 NAICS 代碼。請參閱KYB 工作流程。
• 銀行入金指令可包含 bankName、bankAddress、accountHolderName 與 accountHolderAddress。請將其與其他銀行資訊一併顯示。請參閱接收資金。
• POST /v3/transfers 接受選用的 redirectUrl，可在信用卡或 Apple Pay 託管結帳後將客戶導回您的應用程式。抵達該 URL 並不能確認已完成；請使用轉帳讀取或 webhook 確認。請參閱接收資金。
• 由 v3 Rule 建立的轉帳會以 origin: rule 出現在轉帳讀取與清單中，並像其他轉帳一樣發出 transfer.state_changed 事件。可使用 GET /v3/transfers?origin=rule 篩選這些轉帳。請參閱報價與轉帳。
• 客戶與關聯方的身分證件接受 sideApplicability（front_only、front_and_back 或 unknown），且任務可以將 type、number、issuingCountry、issuingRegion、issuedOn、expiresOn 與 doesNotExpire 等身分證件資料作為回答收集。請參閱功能與要求。

​

變更

• 與進行中的銀行設定衝突的銀行詳細資料提交現在會傳回 409 ops_rail_handoff_conflict。請保留已上傳的文件 ID，並在衝突解決後重試同一提交，而不是重新上傳文件。請參閱錯誤與重試。
• 未預告的穩定幣存入客戶錢包的最低金額現在為 1 個單位，而不是 10 個。更小的存款仍會被視為粉塵。請參閱接收資金。
• Webhook 設定現在按環境隔離。Webhook 入口網站會以您發起要求的環境為範圍開啟，因此沙盒與正式環境端點不再共用設定。請參閱Webhook。
• 商家面板現在會根據客戶的 v3 功能推導可用的入金方式，因此帳戶設定只會提供客戶有權使用的方式。請參閱帳戶。
• RFI 表單現在會以更簡短、清楚的提示收集符合資格的受益所有人，RFI 歷程則以生命週期里程碑的形式顯示。請參閱文件要求。
• 未明確設定到期日的未完成任務，其 dueAt 現在預設為建立後 31 天。請參閱功能與要求。

​

移除

• 新增入金方式時，商家面板不再提供 Fedwire。現有 Fedwire 帳戶仍可讀取。請參閱帳戶。

​

修正

• 未預告的 USDT 存入客戶錢包現在會被辨識並結算，而不是被忽略。
• 您已提交的佐證現在會沿用到需要同一項目的其他任務，因此不會向客戶重複索取同一份文件。
• 重新要求功能不再捨棄已就緒的銀行通道，因此已核發的帳戶詳細資料保持穩定。
• 商家面板中的銀行指令檢視現在會顯示完整詳細資料，包括 SWIFT 地址與目標錢包地址。
• RFI 表單現在會顯示提交驗證錯誤、在提交前驗證法律形式描述，並接受多個企業網站。
• 您現在可以在提交前編輯 RFI 表單中的關聯方草稿。
• 已取消的合規要求不再出現在商家面板任務清單中。
• 文件審查狀態在商家面板中再次正確顯示。

​

新增

• 客戶範圍內託管的驗證與服務條款工作階段現在包含具權威性的 action 物件。請依照其 available 或 unavailable 類型處理；對於可用動作，頂層的 url 與 expiresAt 欄位仍保留為相容性鏡像。請參閱功能與要求。
• 沙盒錢包加值現在會傳回可透過 GET /v3/transfers/{transferId} 讀取或透過 GET /v3/transfers 列出的轉帳 ID。它們會顯示為已完成的傳入穩定幣存款。請參閱在沙盒中測試。
• 當轉帳完成後其資金遭退回或沖銷時，轉帳讀取會包含 correction 物件。它會回報更正的 kind、正規化的 providerStatus、任何 providerShortfall，以及 Swipelux 採取的 compensatingIntent。請參閱報價與轉帳。

​

變更

• 商家面板中用於卡片與 Apple Pay 的 First pay-in 引導現在要求客戶擁有 Polygon 錢包。請先建立該錢包，再開始引導。請參閱帳戶。
• 新要求與公開回應使用 sepa 作為方法與功能的標準名稱。sepa_instant 輸入別名及先前儲存的資源仍相容，但公開回應會使用 sepa。請參閱帳戶。
• 新的 Faster Payments 功能、已發行帳戶與報價要求已不可用。現有帳戶、報價與轉帳仍可讀取。請參閱帳戶。
• KYB 第一頁不再收集代表人的出生日期。股東出生日期仍是獨立要求。請參閱KYB 工作流程。
• RFI 文件參照現在除了 image/jpeg 外，也接受 MIME 別名 image/jpg。請參閱文件要求。
• 商家面板中的任務歷程現在會顯示不含修訂計數器、易於閱讀的稽核軌跡。請參閱功能與要求。
• 報價與轉帳現在會在任何資金移動之前檢查功能所支援的方向。在功能不支援的方向上使用該功能會傳回 422 capability_direction_unsupported，而錢包之間的資金移動需要 stablecoin_transfers 功能。請參閱錯誤與重試。

​

移除

• 商家面板不再提供新的 UAEFTS 帳戶設定。現有 UAEFTS 帳戶仍可讀取。請參閱帳戶。

​

修正

• 審查人員新增文件提交欄位時，RFI 表單會保留現有輸入，因此重新提交時不會遺失先前的回答。
• 商家面板可從可用動作繼續託管的合規工作階段，而不會捨棄有效連結。
• 託管的服務條款連結現在適用於 API 傳回的所有任務範圍。
• 在商家面板中要求 Payment Access 後，面板會開啟該要求傳回的受理任務，而不是較早要求中的任務。
• 商家面板的 KYB 示範現在會要求目前的必填欄位。
• 報價若將來源錢包重複用作 destinationId，現在會在開始任何供應商工作前傳回可採取行動的 422 quote_direction_invalid 詳細資料。請參閱報價與轉帳。
• API 現在會以 400 錯誤拒絕格式錯誤的查詢字串編碼，而不是在未提示的情況下正規化要求。請參閱錯誤與重試。
• POST /v3/customers/{customerId}/documents 現在會以 400 錯誤拒絕空白、非 multipart 或格式錯誤的要求本文。

​

新增

• 在 OpenAPI 規範中發布 v3 Problem Details 目錄，讓整合方可以直接從 schema 對應錯誤回應。請參閱錯誤。
• 為 v3 帳戶 webhook 事件新增 customerId，讓您無需後續讀取即可將帳戶活動關聯至擁有的客戶。請參閱 Webhook。
• 商家後台完整支援 V3 個人檔案欄位，讓入駐操作人員可以審核並編輯透過 v3 API 收集的每個 KYC 欄位。請參閱客戶入駐。
• 發布 v3 開發者遷移指南。請參閱遷移至 v3。

​

變更

• 客戶與帳戶的國家代碼在寫入時現在會驗證為已指派的 ISO 3166-1 alpha-2 值。讀取時容許舊有儲存值，讓現有紀錄仍可繼續解析。請參閱帳戶與錢包。
• USDC 的可用性現在依目的地網路限定，因此報價與轉帳只會在目的地實際支援的網路上提供 USDC。
• 所有入駐流程現在都需要 Swipelux 服務條款。既有的工作階段仍可恢復。請參閱客戶入駐。
• Capability.ready 仍持續回報權限已獲核准。請使用 accountProvisioning 追蹤帳戶核發狀態：not_applicable、not_started、in_progress、issued 或 failed。請參閱能力與任務。
• 現在接受來自 iPhone 的 HEIC 上傳作為身分與地址文件。
• 清除未完成任務仍需要的客戶或關聯方欄位，現在會傳回 409 field_required_by_open_task，並附上造成阻擋的 taskId 與 fields，而不是可重試的衝突。請先完成或取消該任務，再變更這些欄位。請參閱錯誤與重試。

​

修正

• 重新執行已消耗的報價現在會回傳 409 quote_execution_consumed，而非通用錯誤。請參閱報價與轉帳。
• 轉帳清單讀取與報價金額讀取在大量歷史結果上不再回傳 500。
• 並行的 KYC 重新導向現在會回傳衝突而非 404，因此重試能順利解決。託管的重新導向不再中途回滾，且 KYC 連結仍可恢復。
• 個人客戶的關聯方讀取不再回傳 404。
• 含無效錢包欄位的 KYB 提交會在送出前被拒絕，且同步失敗不再於商家後台中回報為成功。
• 商家後台中的需求任務現在會將已提交的答覆顯示為完成、獨立追蹤服務條款動作、移除重複的文件文字、讓已開始的 KYC 工作階段在完成前保持待處理，並在不破壞需求視圖的情況下處理過期任務。
• 商家後台中的驗證連結列現在每一列都會顯示 Open 動作，且每個任務連結都會在需求視圖中呈現。