U卡雷達

支付問題

為什麼加密支付卡無法在某些商家付款?MCC 商家類別限制與交易遭拒原因解析

分享文章

分享到

X微博FacebookLinkedInWhatsAppTelegram

一張加密支付卡在超市、餐廳和一般電商網站都能正常付款,卻無法用於某些金融服務、數位平台或特殊商家。即使餘額充足、3D Secure 驗證通過,交易仍可能遭到拒絕。

原因之一是商家類別限制(Merchant Category Restrictions)。銀行卡交易通常帶有商家類別碼(Merchant Category Code,MCC),發卡機構可以據此限制特定業務類型。購買加密資產、資金轉移及博弈等交易,可能受到部分卡片計畫禁止。

不過,付款失敗也可能發生在商家受理、身分驗證或其他授權環節。要判斷是否與 MCC 有關,必須先了解它在支付流程中的作用。

1. 為什麼加密支付卡會拒絕某些商家的交易?

MCC 是銀行卡體系中用來識別商家經營業務或特定交易類別的四位數代碼。例如,超市通常使用 5411,餐廳通常使用 5812,證券經紀服務商則可能使用 6211。MCC 通常反映商家的業務類型,而非消費者購買的每項商品:即使超市販售禮品卡,也不代表相關交易都會自動改用其他 MCC。

商家類別由收單機構(Acquirer)或相關收單服務業者依照卡組織規則分配與管理,並非由持卡人選擇。對於同一營業場所的不同業務,或需要個別識別的交易,相關規則也可能要求使用不同的 MCC。Visa 的《Merchant Data Standards Manual》對商家資料與類別分配訂有相關規範。

付款時,商家透過支付閘道或處理服務商、收單機構及卡組織網路提交授權請求,再由發卡機構(Issuer)或其授權處理系統決定是否核准交易。授權請求所包含的商家類別、交易金額、地區、幣別及交易方式等資訊,都可能成為判斷依據。

假設某項卡片計畫禁止透過銀行卡購買加密資產。如果授權請求中的 MCC 觸發該計畫的限制,發卡機構就可能拒絕交易。支付基礎設施已有相應的控制機制:Visa 的 Commercial Payment Controls 支援依商家類別管理交易;Adyen 的發卡授權規則範例則展示如何依國家及 MCC 設定規則。

MCC 只是授權判斷條件之一,並不直接等同於最終交易結果。卡片狀態、餘額、限額及其他風險控管規則,仍可能決定付款能否完成。

IMAGE_PLACEHOLDER_01
UCard Radar 圖示:加密支付卡交易授權流程與 MCC 限制機制

2. 哪些 MCC 容易受到加密支付卡限制?

資金轉移、金融帳戶儲值、購買加密資產、博弈及證券交易,都是需要特別確認的類別。下表列出六個具有代表性的 MCC,並非所有加密支付卡共同適用的禁止清單。

MCC

商家類別

可能涉及的業務

4829

Money Transfer

匯款、電子資金轉移等服務

6012

Financial Institutions – Merchandise, Services and Debt Repayment

金融機構提供的金融商品、帳戶儲值、外匯或加密資產購買、債務償還等

6051

Non-Financial Institutions – Foreign Currency, Cryptocurrency and Related Services

非金融機構提供的外匯或加密資產購買、部分帳戶儲值及相關服務

6211

Security Brokers/Dealers

證券經紀及相關交易服務

6540

Non-Financial Institutions – Stored Value Card Purchase/Load

非金融機構提供的儲值卡或儲值帳戶購買、儲值服務

7995

Betting and Gambling

博弈、賭場及相關投注活動

表中名稱為方便閱讀而採用的簡化描述,實際分類仍以適用的卡組織規則為準。

購買加密資產與卡片帳戶儲值並非同一筆交易

使用者將 USDT 存入加密支付卡帳戶時,可能採用鏈上轉帳,不經過銀行卡收單網路,因此該筆儲值也不會產生銀行卡 MCC。之後使用卡片購買一般商品,才會進入銀行卡授權流程。

如果使用者改在交易平台以這張卡購買 BTC 或 USDT,交易性質就已不同。依照 Visa 的商家分類規則,購買加密資產可能因經營主體及交易安排不同而適用 MCC 6012 或 6051;在適用規則列明的其他非傳統法定貨幣取得情境中,也可能涉及 4829、6540 等代碼。因此,不能將所有加密資產購買交易一律歸類為 MCC 6051。

發卡機構限制此類交易,可能是為了控管現金等價物、資金循環,或不符合卡片計畫用途的付款行為。允許使用加密資產形成可消費餘額,不代表也允許透過銀行卡網路再次購買加密資產。

匯款、帳戶儲值與特殊金融服務

MCC 4829 主要涉及資金轉移;MCC 6012、6051 與 6540 則可能用於金融機構或非金融機構提供的帳戶儲值、儲值商品及其他相關服務。不能只因交易涉及「儲值」,就將這些代碼視為可以互相替代。實際分類仍須考量商家性質、交易內容及處理規則。

部分提供現金回饋的消費卡對資金轉移交易尤其敏感,因為反覆轉帳可能被用來取得不符合獎勵政策的回饋。博弈與證券交易則可能同時受到發卡政策、收單要求及當地法律約束。使用者應查閱卡片計畫對 Prohibited Transactions、Account Funding、Money Transfer 等業務的具體規定。

3. Crypto.com 與 Coinbase 的實際產品案例

Crypto.com USD Card:官方明確列出 MCC 限制。

Crypto.com 在《Why was my transaction with the Crypto.com USD Card declined?》中,將商家 MCC 不符合卡片使用政策列為交易遭拒的原因之一。該頁面也列出卡片遭鎖定、美元餘額不足、PIN 或線上卡片資料錯誤、使用不支援的付款方式,以及不支援分期付款等情況。

上述拒絕原因適用於該官方說明所涵蓋的 USD Card 產品。

Coinbase Card:公開列出禁止的商家業務類別。

Coinbase 的 Card 使用說明列有證券經紀、博弈、資金轉移、匯款服務及加密貨幣業務等禁止類別,並說明在美國不支援向 Venmo、PayPal、Cash App 等平台轉帳或提款。

該頁面列出的是特定產品的業務限制,並非逐項公布的 MCC 攔截代碼。因此,不能僅憑業務名稱自行整理出一份完整的 Coinbase Card MCC 黑名單。

4. 為什麼同一張卡在不同商家或不同交易中會有不同結果?

兩個網站即使銷售類似商品,銀行卡網路收到的商家資料也可能不同。一家軟體公司可能直接收款,另一家則可能透過 Merchant of Record(名義銷售商,由其承擔相應的銷售及收款責任)提供訂閱服務。不同的經營主體、收單安排及業務類型,都可能影響交易所顯示的商家名稱、所在地與 MCC。

即使消費者看到的是同一品牌,大型平台的雲端服務、軟體訂閱及數位內容,也可能分別由不同商家帳戶處理。不過,採用 Merchant of Record 並不必然改變 MCC,分類仍須依實際業務及收單機構的判定。

使用同一家支付閘道,也不代表使用相同的 MCC。 Stripe、Adyen 等支付服務業者為各種不同業務類型的商家提供服務。如果某張卡在一家使用 Stripe 的網站付款成功,卻在另一家失敗,不能直接認定是 Stripe 全面拒收該卡。

即使是同一商家,不同交易也可能產生不同結果。首次綁卡驗證有時只會進行小額授權,正式扣款則涉及不同金額;單次消費與商家發起的自動續訂,在身分驗證及授權條件上也可能不同。帳戶儲值還可能使用專門的交易處理方式或商家設定。

即使 MCC 沒有改變,交易仍可能因金額、地區、交易方式、卡片餘額或風險控管規則而遭拒。因此,「綁卡成功、扣款失敗」不能直接視為商家類別遭禁止的證據。

5. MCC 交易限制與現金回饋排除有什麼不同?

MCC 既可用於授權控管,也可用於獎勵計算,但兩套規則處理的是不同問題:前者決定交易能否獲得核准,後者判斷已完成的交易是否符合獎勵資格。

規則

直接影響

可能結果

商家類別授權限制

交易是否獲得核准

付款遭拒

獎勵排除(Rewards Exclusions)

現金回饋或點數資格

付款成功但未獲得獎勵

特定商家收費規則

交易費用

付款成功但產生額外費用

Crypto.com 的預付卡 CRO 獎勵排除規則列出多種不符合獎勵資格的 MCC,包括部分資金轉移、金融服務及公用事業類別。該文件討論的是 CRO 獎勵資格,不能將其中的排除項目直接解讀為銀行卡付款禁令。

比較卡片時,應分別查核 Card Usage Restrictions、Prohibited Transactions、Rewards Exclusions 及費用條款,避免將「沒有現金回饋」誤判為「無法付款」。

6. 付款遭拒後,如何判斷是否受到 MCC 限制?

一般付款頁面通常只會顯示 Declined 或 Payment Failed。商家與收單服務業者收到的詳細回應資訊,不一定會完整提供給持卡人。可依下列順序排查:

  1. 確認失敗發生在哪個階段。 輸入卡號後立即出現 Card Not Supported,可能是商家或支付服務業者在提交發卡授權之前就已拒收;如果出現 3D Secure(3DS)驗證失敗,則應先處理身分驗證問題。3DS 用於線上持卡人身分驗證,通過驗證不等於發卡授權成功。

  2. 查看卡片 App。 確認是否有對應的失敗交易或授權紀錄。即使沒有紀錄,也不能單憑這一點認定發卡機構未收到請求,仍應請服務業者協助核查。

  3. 排查常見條件。 確認餘額、幣別、卡片凍結或鎖定狀態、線上付款設定,以及單筆與累計交易限額。部分商家的預授權金額可能高於最終消費金額。

  4. 核對官方限制。 在持卡條款中查找 Merchant Category Restrictions、Prohibited Transactions、Restricted Merchants 等規定,特別留意資金轉帳、金融帳戶儲值及購買加密資產的相關限制。

  5. 聯絡卡片服務業者。 提供交易時間、時區、商家名稱、金額、幣別、卡號末四碼及已遮蔽敏感資訊的錯誤畫面截圖,請服務業者查找授權紀錄,確認交易是否因 MCC 或其他規則遭拒。

常見拒絕訊息代表什麼?

提示

初步含義

判斷界限

Transaction Not Permitted

目前交易不符合某項允許條件

不專指 MCC

Restricted Card

卡片受到使用限制

無法確定是哪項限制

Do Not Honor

發卡機構未核准交易

未明確指出具體原因

Insufficient Funds

可能沒有足夠的可用資金

應先核對餘額及預授權金額

Authentication Failed

身分驗證未成功

不等於 MCC 授權拒絕

Adyen 的收單回應說明展示了不同授權拒絕回應及其對應方式。例如,回應碼 57 常用於表示「Transaction Not Permitted to Cardholder」,但不能據此唯一判定為 MCC 限制。

向服務業者查詢時,可以直接使用以下文字:

請協助核對這筆交易的授權紀錄:是否因商家類別碼(MCC)觸發卡片計畫限制?如果不是,請確認實際拒絕原因;如可提供,也請告知該筆交易使用的 MCC。

銀行卡 BIN(Bank Identification Number,發卡機構識別碼)用於識別發卡來源及相關卡片資源,與 MCC 用來分類商家的用途不同。商家也可能依據 BIN、卡片發行地區或預付卡類型提前拒收,因此不應直接歸因於發卡機構的 MCC 規則。

7. 能否提前查詢商家的 MCC?

部分卡片 App 會在交易明細中顯示商家類別,但對於尚未發生的交易,通常無法僅憑網站名稱準確查出實際 MCC。同一家商家可能有多個收單主體、業務帳戶或地區設定。

核查特定交易時,應優先採用發卡機構或收單機構確認的授權紀錄。第三方 MCC 資料庫可以作為參考,但仍須確認資料來源、更新日期及對應的商家主體。僅憑商家品牌或其他使用者的付款經驗,無法可靠確認某筆交易實際採用的 MCC。

即使其他持卡人在同一網站付款成功,也不代表另一地區、另一商家帳戶或另一卡片計畫下的交易會採用相同分類。

對 UCard Radar 這類資訊平台而言,公開的商家分類、卡片計畫禁止交易規則,以及實際支付相容性的證據,應分別記錄。如果沒有可核實的交易資料,就不宜將某個 MCC 標示為已確認的事實。

8. MCC 限制可以解除嗎?換卡有用嗎?

如果發卡機構明確禁止某類交易,客服通常無法任意為單筆付款變更卡片計畫政策。不同發卡機構的規則可能有所差異;合法且符合另一張卡使用條件的交易,仍有機會透過其他卡片完成。

不過,換卡並不能解決所有問題。商家拒收預付卡或虛擬卡、所在地區不受支援、身分驗證失敗,以及法律或合規限制,都需要分別處理。如果商家的 MCC 確實分配錯誤,應由商家聯絡收單機構依規則核查,而不是透過不實的交易描述變更分類。

對於長期需要支付雲端服務、軟體訂閱或其他特定費用的使用者,選卡時除了比較費用、卡組織及消費限額,更應查核禁止交易類別、實際使用紀錄,以及服務業者能否查詢授權拒絕原因。如果持續發生付款遭拒的情況,應先取得明確的授權拒絕原因,再決定要處理帳戶問題、聯絡商家,還是改用更適合該用途的支付工具。