Japan card security and authentication controls
ConfidenceLikelyUpdated2026-07-30Review by2026-11-22Sources11Machine-translatedOriginal (JA)
On this page
Overview
Japan EC card security is not only “3-D Secure.” The useful control stack is: card-data protection -> merchant vulnerability control -> EMV 3-D Secure authentication -> fraud monitoring -> acquirer / PSP / merchant information sharing -> chargeback and remediation.
Use this page with card issuer / acquirer / processor split, card acquiring stack, PSP settlement risk, credit / card operator registry, and Installment Sales Act 2020 amendment.
Guideline Snapshot
The following table is scoped to public primary sources (meti.go.jp, j-credit.or.jp, jcb.co.jp). It restates licence / structure / product boundaries from those materials and does not invent market share, ranking, or unstated numerical claims. ↗
| Version / route | Public-source role | Wiki reading |
|---|---|---|
| METI 2025-03-05 release | Announces the credit-card security guideline revision. | Public policy anchor for EC merchant security strengthening. |
| Japan Credit Association guideline 6.1 | Main current public guideline source for card-security controls. | Use for non-retention, EC security, EMV 3-D Secure, and fraud-control vocabulary. |
| PCI DSS | International card-data security standard. | Use for cardholder-data environment and merchant / PSP security controls. |
| EMV 3-D Secure | Authentication protocol / messaging standard. | Use for risk-based authentication and challenge-flow analysis. |
| JCB merchant / brand pages | Plain-language model of issuer, acquirer, brand, merchant, and authentication roles. | Use to separate flattening all parties into “card company.” |
Actor And Responsibility Map
The following table is scoped to public primary sources (meti.go.jp, j-credit.or.jp, jcb.co.jp). It restates licence / structure / product boundaries from those materials and does not invent market share, ranking, or unstated numerical claims. ↗
| Actor | Japanese / market term | Core responsibility | Security artifact |
|---|---|---|---|
| Issuer | Issuer | Cardholder screening, authorization, ACS / authentication decision, billing, fraud monitoring. | Authorization logs, ACS result, cardholder dispute / fraud monitoring. |
| Card brand / network | International brand / brand | Network rules, directory routing, brand security rules, interoperability. | Scheme rules, directory-server routing, brand compliance. |
| Acquirer | Merchant underwriting, merchant contract, settlement, chargeback routing. | Merchant due diligence, security status, chargeback monitoring. | |
| PSP / gateway | Payment agency / PSP | Payment page, tokenization, 3DS Server integration, transaction data, reconciliation. | Tokenization design, 3DS transaction logs, fraud filters. |
| Merchant | EC Merchant | Site security, customer authentication UX, shipping / refund controls, evidence retention. | Vulnerability controls, order logs, delivery / refund evidence. |
| 3DS Server / DS / ACS | 3-D Secure components | Data transfer, directory routing, issuer authentication, challenge / frictionless flow. | AReq / ARes / challenge result, ECI / CAVV style authentication data. |
Control Stack
The following table is scoped to public primary sources (meti.go.jp, j-credit.or.jp, jcb.co.jp). It restates licence / structure / product boundaries from those materials and does not invent market share, ranking, or unstated numerical claims. ↗
| Layer | Threat | Control objective | Primary owner | Secondary owner |
|---|---|---|---|---|
| Card-data protection | Cardholder data leak. | Avoid storing card data where possible; keep PCI scope controlled. | Merchant / PSP | Acquirer |
| Tokenization / non-retention | Raw card data exposure. | Replace card data handling with token / redirect / JavaScript-token models. | PSP | Merchant |
| Merchant vulnerability control | EC-site compromise, formjacking, account takeover. | Keep EC site, plugins, admin accounts, and payment pages hardened. | Merchant | PSP / EC system provider |
| EMV 3-D Secure | Unauthorized card-not-present use. | Add risk-based issuer authentication and challenge flow. | Issuer / ACS | Merchant / PSP / brand |
| Fraud monitoring | Credit master / BIN attack, abnormal order pattern, reshipping fraud. | Detect and stop suspicious transactions and delivery. | Issuer / acquirer / PSP | Merchant |
| Chargeback / dispute | Loss allocation and evidence failure. | Preserve order, authentication, delivery, refund, and communication evidence. | Acquirer / merchant | Issuer / PSP |
EMV 3-D Secure Route
The following table is scoped to public primary sources (meti.go.jp, j-credit.or.jp, jcb.co.jp). It restates licence / structure / product boundaries from those materials and does not invent market share, ranking, or unstated numerical claims. ↗
| Step | Component | Research question |
|---|---|---|
| Checkout | Merchant / PSP | Is transaction data complete enough for risk-based authentication? |
| 3DS request | 3DS Server | Is the PSP or merchant integrating the 3DS Server correctly? |
| Directory routing | Directory Server | Which brand / card route receives the authentication request? |
| Issuer decision | ACS / issuer | Is the flow frictionless, challenged, declined, or unavailable? |
| Authorization | Issuer / acquirer | How are authentication result and authorization result combined? |
| Dispute / liability | Issuer / acquirer / merchant | Does the authentication result actually change liability or only add evidence? |
3-D Secure reduces card-not-present fraud risk, but it does not replace merchant screening, card-data protection, account-takeover controls, delivery controls, or chargeback evidence. That is why this page is linked with PSP settlement risk rather than as a protocol-only note.
Non-retention, Tokenization, And PCI DSS
The following table is scoped to public primary sources (meti.go.jp, j-credit.or.jp, jcb.co.jp). It restates licence / structure / product boundaries from those materials and does not invent market share, ranking, or unstated numerical claims. ↗
| Integration pattern | Card-data exposure | Wiki reading |
|---|---|---|
| Redirect payment page | Merchant redirects to PSP / acquirer hosted page. | Lower merchant card-data exposure if implemented correctly. |
| JavaScript token model | Card data is sent from browser to PSP / tokenization endpoint. | Merchant still needs site-security controls because page compromise can alter scripts. |
| Server-side card handling | Merchant server receives card data. | Highest PCI and operational burden; needs strong evidence before describing as compliant. |
| Stored credential / recurring billing | Token or credential-on-file used for later payments. | Needs consent, lifecycle, cancellation, and fraud monitoring controls. |
EC Merchant Fraud Controls
The following table is scoped to public primary sources (meti.go.jp, j-credit.or.jp, jcb.co.jp). It restates licence / structure / product boundaries from those materials and does not invent market share, ranking, or unstated numerical claims. ↗
| Pattern | Control |
|---|---|
| Credit master / BIN attack | Rate limits, authorization pattern monitoring, issuer / acquirer alerts, payment-page controls. |
| Account takeover | Login protection, device / behavior monitoring, step-up authentication, password-reset monitoring. |
| High-risk delivery | Address / shipping change monitoring, delivery hold, manual review, cancellation / refund control. |
| Refund abuse | Refund approval workflow, settlement reconciliation, merchant dashboard permission control. |
| Site compromise | Vulnerability scanning, patching, script integrity checks, admin MFA, incident response. |
JapanFG Relevance
Card-security analysis is routed through issuer / acquirer / PSP roles rather than through a single “credit card company” label:
- Issuers / acquirers: JCB, SMBC Card, MUFG NICOS, Rakuten Card, PayPay Card, AEON Financial Service, Orico, JACCS, Credit Saison.
- PSP / gateway: GMO Payment Gateway, GMO Epsilon, SB Payment Service, DGFT, Netstars.
- Legal / registry layer: credit / card operator registry and JapanFG legal / financial licenses.
Red Flags For Wiki Research
- A source says “card company” but does not say whether it means issuer, acquirer, brand, processor, or PSP.
- A merchant claims 3-D Secure support but has no evidence for vulnerability controls, tokenization, or fraud operations.
- A PSP claims tokenization but the merchant page can still expose card data through compromised scripts.
- A fraud metric is quoted without denominator: transaction value, order count, approval rate, challenge rate, chargeback rate, or fraud amount.
- A liability-shift statement is treated as a complete loss guarantee.
Related
- INDEX
- japan-card-issuer-acquirer-processor-split
- card-acquiring-japan-stack
- psp-merchant-settlement-risk
- credit-purchase-card-operators-japan-index
- japan-bnpl-credit-purchase-boundary
- japan-bank-api-incident-and-fraud-control
- installment-sales-act-2020-amendment
- jcb
- FinWiki index
Sources
- METI: credit-card security guideline revision release and credit-transaction policy page.
- Japan Credit Association: Credit Card Security Guidelines 6.1 and document index.
- JCB: merchant EMV 3-D Secure notice and brand / card-payment actor explanation.
- PCI Security Standards Council: PCI DSS overview and Japanese document library.
- EMVCo: EMV 3-D Secure public standard overview.
- Payments Japan and FSA / PPC / METI public security-advisory materials.
Discovery
Keep reading
Read next
- Japan code-payment competitive mapJapan's code-payment market is recorded as a battle among wallet ecosystems, merchant acceptance networks, loyalty budgets, and settlement / funds-transfer capabilities. METI's 2025 cashless...
- Japan code-payment operator 2025 market share matrixJapan's code-payment market in 2025 is a clear oligopoly with PayPay holding majority transaction share, Rakuten Pay and d-Barai (NTT docomo) competing for the strong second tier, and au PAY...
- Japan JCB issuer ecosystem positioning matrix"JCB" is not a single card company — it is (a) a domestic Japanese card brand and international payment network (株式会社ジェーシービー / JCB Co., Ltd.) plus (b) a population of Japanese issuers that p...
Links here
- Missing Japan financial institutions expansion backlogThe current wiki already has a strong core: megabanks, major FG, regional-bank groups, policy finance, insurers, securities groups, leasing, payment, fintech, foreign Japan subsidiaries, and...
- Japan BNPL / pay-later operator registry matrixJapan's BNPL / 後払い checkout label does not map to one license. METI explains that a credit-purchase intermediary generally pays the merchant and receives the consumer's payment over a period...
- Japan card issuer, acquirer, and processor splitJapan card payments is split into at least five roles: issuer, international / domestic brand, acquirer, card-number contract / merchant-contracting operator, and processor / PSP. A single g...
- Japan consumer-credit operator comparison matrix"Consumer credit" in Japan is not one industry — it is at least nine operator categories that look similar at checkout but sit on different licenses, different regulators, different lending...
- Japan interchange and merchant fee stackThis page records the public structure of Japan card merchant-fee and interchange-related disclosures. The scope is card merchant fee composition, issuer-fee / interchange disclosure, acquir...